MIVOT: fully qualified attribute names

[Laurino, Omar]

I really hope I didn't miss some connections in this long thread, but...


> The real point is that the VODML-ID "coords:TimeFrame.timescale” could be
> "coords:a.b" according to the VO-DML standard - there is no connection
> between the vodml-id and the name of the model element as defined in the
> standard - I want to make the connection, and once the connection is made,
> the VODML-ID is redundant as it can be generated from the model structure.
>

If I understand Paul's point correctly, I'd like to point out that the
reason for having the entire vodml-id was to make sure that a model's
element could always be identified unambiguously in any context, in
particular when extending models. VODML allows data providers to extend a
type (section 4.6.1). When they do, parsers need a way to identify fields
in an unambiguous way, which includes mapping them to the model document
where they are defined.

In that sense, the vodml-id becomes redundant not only if one makes the
connection with the name, but also if a mapping scheme defines a way to
represent extensions that provides that unambiguous mechanism. If an
instance is of type <custom:MyType> (which extends standard:Type), one
would have attributes identified by <custom:MyType.myAttribute> and
<standard:Type.attribute> within that instance, which the parser could map
to the respective definitions without having to rely on any heuristics or
complex logic.

If one has a <custom:MyType> instance with attributes <myAttribute> and
<attribute> the parser wouldn't really know where to look them up unless
the connection between <custom:MyType> and <standard:Type> is made explicit
in the serialization markup. And even in that case, since the parser
doesn't know whether myAttribute is defined in custom: or in standard:
it'll have to try both.

People have argued in the past that inheritance requires parsers to have
complex type algebra, which may be true depending on the use case and of
the mapping strategy. However, extensibility was one of the main
requirements for VODML. A mapping strategy can minimize that effort by
identifying an instance as both custom:MyType and standard:Type. And since
we recommend vodml-ids to be generated algorithmically, a parser could
decide to ignore model definitions completely, and parse the vodml-ids to
display the attribute names, which would be human-readable. Other parsers
would be interested in the unambiguous identification of attributes to
provide richer context-dependent features to client software.

A change could be made to the VODML spec to make the vodml-id generation a
requirement rather than a preference, by promoting Appendix C to normative
state. And while I remember believing that both approaches (full vodml-id
or just name) would work, as long as the mapping provides enough markup to
make the references unambiguous, I did have a preference for the full
vodml-id for two reasons: 1. because explicit is better than implicit and
2. because it is more future-proof.

A reference to a full vodml-id is always going to unambiguously identify a
single element, like a URI. I can go from custom:MyType.myAttribute to
myAttribute and from standard:Type.attribute to attribute, but I can't go
from myAttribute to custom:MyType.myAttribute without some effort parsing
definition documents.

-- 

Omar Laurino (he/him)

Smithsonian Astrophysical Observatory

Center for Astrophysics | Harvard & Smithsonian

Office: (617) 495-7227

100 Acorn Park Dr. R-377 | MS 81 | Cambridge, MA 02140


cfa.harvard.edu | Facebook
<https://www.facebook.com/CenterForAstrophysicsHarvardSmithsonian/> |
Twitter <https://twitter.com/CenterForAstro> | YouTube
<https://www.youtube.com/channel/UC-UUo6Y7fP0N41Qw7KcKtcQ> | Newsletter
<https://harvard.us14.list-manage.com/subscribe/post?u=13f357b8637e4a05e4a5d2845&id=c6100e9a6c>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230307/108ffebb/attachment.htm>