MIVOT: fully qualified attribute names

[Laurent Michel]

Dear DM,


This issue has been answered on the RFC page (https://wiki.ivoa.net/twiki/bin/view/IVOA/DataAnnotation)

Let's quickly summarize the answer (editor hat):

MIVOT acts as a bridge between data and model.
     - Data element are identified by ATTRIBUTE at ref
     - Model elements are identified by their roles as defined by VODML.
     - Roles are defined in the scope of the father objects.
     - A role must be unique among the enclosing object children

Let's take an Example:
=====================

The following statement:

     <ATTRIBUTE dmrole="ivoa:Quantity.val" dmtype="ivoa:real" ref="_column_xyz" \>

tells the client that the model leaf playing the "ivoa:Quantity.val" role must be set with
the value of the table column "_column_xyz".

If we allow MIVOT to split the roles given by the model as suggested
by Markus, we get this statement:

     <ATTRIBUTE dmrole="val" dmtype="ivoa:real" ref="_column_xyz" \>

It is simpler for sure, but with 2 major drawbacks:

     1) There is no way for a split role to retrieve the model element it refers to.
        This is a major issue for a validator which could no longer validate the MIVOT
        statement against the mapped models.
     2) if the enclosing object has 2 attributes with a role ending with e.g. ".val"
        there is no way to distinguish them.

Working with shorten role could make sense for a client knowing the classes it has to parse but doing this at the mapping level 
would break the consistency of the annotations.

Laurent


Le 26/01/2023 à 11:48, Markus Demleitner a écrit :
> Dear DM,
> 
> I have just added a few points to the MIVOT RFC
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/DataAnnotation> both as
> WG chair (mostly relating to the proof of implementation) and as
> myself.  From these comments as myself, there is one that I think
> should be discussed more widely, which is why I'm taking it here:
> 
> I admit I have never been particularly fond of fully qualified role
> names ('dmrole="ivoa:Quantity.val"') -- I've always considered them a
> lot of letters for very little gain.
> 
> But now that I have tried to implement MIVOT annotation in DaCHS, I
> have found that with these qualified names, I have to parse (and
> understand) VO-DML files and then follow inheritance hierarchies --
> just to infer these fully qualified attribute names. That's about an
> order of magnitude more work than if I can just write 'dmrole="val"'.
> 
> Note that the type an attribute sits on is already given by the
> dmtype of the embedding element, except that that's the actual type,
> not the type that defines the attribute, so we would not be losing a
> lot.
> 
> Given that: is there a really strong reason to have these qualified
> role names?
> 
> While I was trying to research how these role names are supposed to
> work in the first place, I noticed that the spec apparently does not
> say anything about how these role names are to be derived.  So, if
> this discussion actually results in a strong reason to keep them
> fully qualified, I'd say MIVOT needs some normative language on how
> to form these names.
> 
>            -- Markus

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/vcard
Size: 406 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230203/3dd12e11/attachment.vcf>