[Dachs-support] How to register specific short_name for an epn-tap service in dachs ?

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Nov 17 10:13:06 CET 2022


Hi Cyril,

I hope you don't mind that I cc: dachs-support, but since your
question is a very good one and of general interest, I thought that's
ethically marginally ok to widen the recipient list without asking
first.

On Wed, Nov 16, 2022 at 04:17:24PM +0100, Cyril Chauvin wrote:
> I'm trying to correct the short name of the epn-tap services in the
> registry. (short_name column in rr.resource). Currently, most of them are
> the table_name (like planets.epn_core) possibly truncated if longer than 16
> chars.
> 
> When using dachs pub, it seems short_name is automatically filled by dachs
> (with the table_name) which is totally ok. My problem is I don't know how to
> overwrite that default short_name. I have tried to edit the *.rd file of a
> service and add in resource element:
> 
> > <meta name="shortName">Planets</meta>
> 
> But it seems to have no effect (when checking the oai.xml). I put
> you an
> example of rd file in attachment. Result can be checked at
> http://voparis-tap-sandbox.obspm.fr/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://padc.obspm.heliophysic/planets/q/epn_core
> 
> Could you please tell me what I'm doing wrong here ?

Setting the shortName meta is exactly right, but you are colliding here
with the rules of DaCHS' metadata inheritance.

Usually, if you ask for, say, the subject of a table, DaCHS will look
this up in the metadata of the table definition itself, then in its
meta parent (generally the RD), and then in the RD's meta parent
(which is what's in defaultmeta.txt).  This stops as soon as the
first meta container has, in this case, a subject, which then wins.

But tables always define a shortName meta[1].  This, however, blocks
metadata inheritance.  This means that in this case, setting a short
name on the resource level has no effect (well, it would have an
effect if there were, say, services, which would inherit it; but
that's rarely a good plan, as multiple services would end up with the
same shortName, which is legal but ugly).

After all this:  Move the meta element into the table element and
the thing should do what you want, as manually set meta items
override the computed ones.

Thanks,

          Markus


[1] For DaCHS nerds: it's a computed meta, defined in rscdef.tabledef
via a meta override like this:

	def _meta_shortName(self):
		return self.getQName()[:16]



More information about the Dachs-support mailing list