IVOA Web>WebPreferences>UtypesTigerTeam>UtypeTigerTeamMinTel6 (2021-04-13, GiuliaIafrate)

UtypesTigerTeam telecon 2012-11-13

Action items from last time

MD explicit UC for R#9: Done, see http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam#STC_serialization_in_a_VOTable

GL PhotDMv1-1 in VO-URP is essentially done

GL VO-URP coverage of UCs -- not been in focus; it seems most tigers are satisfied that VO-URP plus work on container formats will satisfy them.

MG collecting usage from VOEvent an VOUnits: status not quite clear. In Apps, feedback on Aladin was worked into the usage document, we didn't get more feedback (TODO: solicit more!)

JS: PhotDMv1-1 discussion: Delayed since after Sao Paulo some changes to the DM were deemed necessary

OL: If we pass something that changes the way utypes are defined, what happens to the utypes that are already in PhotDMv1-1?

GL: You can tag any element with a utype, so in VO-URP we can just retain what's defined.

Today's agenda:

OL: Do we actually need the slash to separate packages?

GL: Apart from simdm, nothing uses packages right now anyway, so it doesn't hurt.

OL: Still, if you changed the grammar to just use dots everywhere, we'd have more "normal" utypes

GL: It would break SimDM utypes. Anyway, the slash is just for readability, not for, e.g., uniqueness, so it can easily be adapted, even to single DMs; you could use random strings.

GL: Note the difference between "Data Type" and "Object Type": For a data type, the existence of an instance is self-evident (the integer 1); for an object, it's not (the person Fred Flintstone). In existing IVOA DMs there are mainly data types; these are much easier to reuse. For object type, it's usually necessary to take everything dependent on it, since that's how it receives its identity.

A new feature in VO-URP now allows you to import pieces from other data models.

What, in addition to VO-URP, is needed to say in sufficient depth how to serialize DMs in VOTables?

Some discussion about GROUP-based solutions.

OL: Can we have examples of instances of VO-URP-modelled things, i.e., serializations in VOTables?

GL: That's a good idea.

OL: What about phot:photometry/PhotometricSystem.photometryFilter vs. phot:photometry/PhotometryFilter? Two utypes for the same concept?

GL No, phot:photometry/PhotometricSystem.photometryFilter is the utype on the collection, not on an individual filter. In VO-URP, you can refer to reference-like things, and that's why they have a utype. Whether that's useful in VOTables is not clear. It could be useful, e.g., to label a (list of) pointer(s) a PhotometrySystem object to PhotometryFilter objects in objects that support this kind of thing (inverse to the container utype; that would correspond to a foreign key in DB tables).

OL: How would I, in a VOTable serialized PhotCal instance, mark up the photometryFilter?

In a relation model, photometryFilter would be a foreign key. In a VOTable, you'd have to do some referencing; GROUPref would be nice, but doesn't exist. We can use a PARAM anyway, and have a reference in its value. The trick is that this reference could point out of the document it's in...

MD: Could someone briefly explain "navigability" of utypes?

SJ: It allows to go from a parent to the child element by adding things with dots.

GL: Much of the problem with having to define this kind of thing is the result of confusing instances and data models.

PF: Can we have a marked-up VOTable with, say 2MASS from VizieR and PhotDMv1-1 so it's easier to see what we're talking about, also in terms of implementation effort?

-> (action item on JS, MD, GL)

OL: There's an objection that we're adopting a software -- but really, we're adopting the VO-URP input format; another is: What happens if GL jumps ship?

GL: Well, all this is a fairly standard approach, so it's not like we're doing higher magic here.

Next telecon: Two weeks, same time, same place.