UtypesTigerTeam telecon 2012-11-13Action items from last timeMD explicit UC for R#9: Done, see http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam#STC_serialization_in_a_VOTable | ||||||||
Changed: | ||||||||
< < | GL PhotDM in VO-URP is essentially done | |||||||
> > | 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!) | ||||||||
Changed: | ||||||||
< < | JS: PhotDM discussion: Delayed since after Sao Paulo some changes to the DM were deemed necessary | |||||||
> > | JS: PhotDMv1-1 discussion: Delayed since after Sao Paulo some changes to the DM were deemed necessary | |||||||
Changed: | ||||||||
< < | OL: If we pass something that changes the way utypes are defined, what happens to the utypes that are already in PhotDM? | |||||||
> > | 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. | ||||||||
Changed: | ||||||||
< < | PF: Can we have a marked-up VOTable with, say 2MASS from VizieR and PhotDM so it's easier to see what we're talking about, also in terms of implementation effort? | |||||||
> > | 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.
Deferred to next time:
Open Action Items:JS: get VOSpec utypes usage MG (fallback MD): Solicit more Apps feedback JS+GL+MD: Provide some example serializations (with references and collections if possible?)<--
|
UtypesTigerTeam telecon 2012-11-13Action items from last timeMD explicit UC for R#9: Done, see http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam#STC_serialization_in_a_VOTable GL PhotDM 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: PhotDM 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 PhotDM? 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 PhotDM 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.Deferred to next time:
Open Action Items:JS: get VOSpec utypes usage MG (fallback MD): Solicit more Apps feedback JS+GL+MD: Provide some example serializations (with references and collections if possible?)<--
|