[Dachs-support] [Support EPNTAP #80066] Re: How to register specific short_name for an epn-tap service in dachs ?

Cyril Chauvin support.epntap at obspm.fr
Thu Nov 17 11:25:50 CET 2022


Page web de ce ticket : <URL: https://support.obspm.fr/Ticket/Display.html?id=80066 >
Demandeur de ce ticket : msdemlei at ari.uni-heidelberg.de
En copie pour ce ticket : Cyril.Chauvin at obspm.fr, dachs-support at g-vo.org

Ok it makes sense, thank you for your detailed explanations.

Cyril

Le 17/11/2022 à 10:13, markus demleitner a écrit :
> Ticket : <URL: https://support.obspm.fr/Ticket/Display.html?id=80066 >
> Demandeur : msdemlei at ari.uni-heidelberg.de
> En copie : Cyril.Chauvin at obspm.fr, dachs-support at g-vo.org
> Propriétaire : Nobody
>
>
> 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