ivoa-std / MeasurementDM

Astronomical Measurements Model
1 stars 2 forks source link

ucd is constrained to a fixed value. #5

Open lmichel opened 2 years ago

lmichel commented 2 years ago

in PR3, body.tex L52, it is said

.... For these specialized classes, the ucd is constrained to a fixed value.

This is too much restrictive.

I propose to limit the UCD fixed value to the primary word:

.... For these specialized classes, the promary word of the ucd is constrained to a fixed value

mcdittmar commented 2 years ago
  • You loose information in comparison with what FIELDs can provide e.g. the model does not accept pos;meta.main
  • These specialized classes could not be used by MANGO as such since MANGO uses UCDs to specify the measure roles.

I'm not sure that is the proper solution. Vodml modeling has a mechanism for assigning different roles to instances of the same type. The ucd in Measure is only to allow it to convey the 'type', nothing more.

I think we should review the use case which requires this information, and boil it down to the new requirements for Mango vs Measurement models. From the statement above, it looks like the requirement for Measurement would be: "Measure instances MAY convey the role they play in their parent instance." which is contrary to the vodml philosophy.

From a logistics point of view. The ucd syntax allows one to convey type, role, frame, etc information in 1 string.. It'd be very tricky to specify that "pos;meta.main" (conveys additional role info ) is OK but "phot.mag;em.opt.V" (conveys additional Frame info) is not. Also.. the FIELD ucd is typically more specific than what Measure should get. For example, the position FIELD ucds will usually be something like "pos.eq.ra;meta.main" & "pos.eq.dec;meta.main". Neither is directly re-usable in the Measure ucd, which is why the Position.ucd is fixed at "pos".

If this does boil down to an update to Measure as you describe, this is a very minor (errata level?) change. So I don't think it is a lien on V1.0 of the model.