MIVOT: fully qualified attribute names

[CresitelloDittmar, Mark]

All,

I'm just coming off of leave, and catching up on this thread.
A couple quick thoughts:

> PH: "I can follow all of  Std&Doc rules and all of the VO-DML std rules
and produce PhotDM 1.2 with entirely different VODML-IDs - It is not
sensible, but it is legal,"
A version 1.2 of the model with completely different VODML-IDs would not be
considered backward compatible, so not qualify as a 1.2.
I suppose it would be true that a V2.0 of the model could have completely
different VODML-IDs defined.

> MD:  "And that's where it is a MIVOT issue after all -- this entire
thread wouldn't have happened if we decided to sunset the VODML-ids now.
It's still easy at this point, and it'll be nigh impossible once MIVOT uses
them."
I agree with the statement in principle.. if there is a serious issue
with using VODML-IDs to identify the role of an object that should be
resolved before MIVOT uses it.
However, I don't really understand the issue here (need to spend some more
time on it).

> PH: "Once it is agreed that the VODML-IDs are UTypes then they can be
dropped entirely as they are mechanically created from the model structure"
VODML-IDs are not the same as UTypes, they do not change due to context as
UTypes do.  A "coords:TimeFrame.timescale" does not change when used within
a Cube, TimeSeries, Mango, etc. instance.

Do I have this correct?  The convention of generating VODML-IDs as
"<ClassName>.<attribute name>" has created the perception that they are
redundant with the actual attribute name when used to identify the role of
the item in MIVOT annotation.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230307/46a7e79d/attachment.htm>