updates to dm mapping document

[Laurino, Omar]

Hi All,

Just a reminder that this issue is up in the air. Any comment will be
appreciated.

Thanks,

Omar.

On Tue, Jul 1, 2014 at 2:16 AM, Gerard Lemson <lemson at mpa-garching.mpg.de>
wrote:

>
> Dear all
> I promised in Madrid to compose an email with alternatives for the use of
> 'utype' in the current utypes mapping document (*). I think the following
> options have all been discussed and should be on the table, in increasing
> amount of complexity and/or required changes:
>
> 1. do not change anything.
> I.e. leave mapping document as it is. Keep using the utype attribute for
> pointing into VO-DML models.
> This option MUST be on the table for discussion. It reduces amount of work
> required and, importantly, does not require any changes to VOTable standard.
> The latter was something the utypes tiger team tried hard to avoid during
> its work.
>
> 2. add 1 new attribute to some VOTable elements, which will be used
> instead of the 'utype' attribute wherever that is currently used in the
> mapping document. This attribute is only necessary for GROUP, PARAMref,
> PARAM and FIELDref elements.
> This attribute was referred to as 'dmtype' in Madrid discussions. Might
> better be called something like 'vodml-role' if the ONLY change to the
> mapping document will be to use this attribute wherever it currently uses
> 'utype'. After all, the current mapping document suggests that utype-s
> should always identify VO-DML Roles, not Types. Types are used for casting
> purposes only in the existing utypes document, and are identified as 'value'
> in a special <PARAM> (or possibly as a <FIELDref>!) inside a GROUP.
>
> 3. add 2 attributes to VOTable, for sake of argument named 'dmrole' and
> 'dmtype' (or vodml-role, vodml-type) . The former would replace the current
> use of utype (as in proposal 2). For the 'dmtype' attribute there would be
> two usages:
> i) it would replace the <PARAM> used for type casting purposes.
> Disadvantage is that a 'dmtype'  attribute would only represent a single
> type (assuming we don't want parsing of these attributes to discover
> multiple, ;-separated values). But in the current proposal we give
> publishers the option to explicitly add multiple types from a type
> inheritance hierarchy in the annotation, especially when types are
> inherited across model boundaries (ask for details if this is unclear).
> ii) it is used for "root" GROUPs, i.e. GROUP-s representing instances that
> do not play a role in another GROUP in the VOTable. The dmrole attribute
> would not be used. The current design introduces a somewhat ad-hoc
> "vo-dml:Instance.root" role that must be used for GROUP-s that are not
> contained in a parent GROUP. This would not be necessary.
>
> 4. add  a complexType, say 'VODMLAnnotation' to VOTable, with components
> <vodml-type> (maxOccurs=unbounded) and <vodml-role>; their usage should be
> obvious. This type is used for a new <vodml> (minOccurs=0) element on
> GROUP, FIELDref, PARAM and PARAMref.
>
>
> My comments on these options:
> Option 1 has the lowest impact, namely none at all. It requires no
> changes, either in VOTable or in utypes mapping document.
>
> Option 2 has lowest impact of the possible alternatives I suppose, only
> adds one attribute to a select number of VOTable elements. In MY opinion it
> is a weird compromise though. Why is it ok to have dmrole do exactly what
> the utype would do in the proposal, but is it not acceptable to use the
> utype attribute itself for that purpose? The utypes proposal mandates a
> prefix that MUST be declared explicitly as an identifier of a VO-DML model.
> I.e.
> these utypes and their interpretation are clearly identifiable. Why is
> that not sufficient? But if this is what it takes to move forward it is
> acceptable.
>
> Option 3 removes a slight ugliness in the existing design once we accept
> option 2. Sometimes a casting is required, or at least desirable. In the
> current proposal we use a special <PARAM> for that purpose. This means that
> the type and role annotation are now at different levels, where one might
> expect them to be close. This slightly complicates the parsing. However
> this proposal has the disadvantage that if we want to allow multiple type
> annotations, the dmtype would have to be composite. I don't think this is a
> useful compromise.
>
> Option 4 is in my opinion the most elegant solution. Imho it is how utype
> should have been defined from the beginning, not as an attribute, but as an
> element. Many of the design issues would have been trivial to solve. We
> might even have used a special VODMLType or so that would extend a more
> generic UTYPE type, and an xsi:type would have been sufficient to indicate
> the special kind of annotation used. Hence from design considerations this
> option has my preference. But introducing a new element, rather than one or
> two attributes apparently has the biggest impact on existing VOTable
> parsers and so may be objected to.
>
>
> Note, if we accept one of options 2-4, I think we MUST change the
> definition of the utype attribute in existing specs. It should not be
> thought of as a "pointer into a data model". For example we might change it
> to something like the following, which I think represents the current usage
> of those who have problems with the proposal as it is:
> "The 'utype' attribute can be used as custom annotation to identify an
> element in  a particular context, for example a custom application or an
> IVOA standard access protocol. There are no constraints on its format,
> simple string comparison to some list defined by the context should be
> sufficient. The precise context SHOULD be declared elsewhere in the VOTable
> in a manner specified by the application. Outside of this context, there is
> no requirement for clients to be able to interpret the meaning. In
> particular, for generically identifying elements in terms of a standard
> data model the 'vodml-role' attribute [or whatever we come up with] MUST be
> used as specified in [ref to mapping document]."
>
> Cheers
> Gerard
>
>
> (*) Latest version of document can be found at volute:
> http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-WD-v1.0.pdf
> .
> See also http://wiki.ivoa.net/twiki/bin/view/IVOA/UTYPES for related
> links, especially to VO-DML doc.
>
>


-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20140925/904dd2da/attachment.html>