WYSIWYG content - do not remove this comment, and never use this identical text in your topics
Utypes Tiger Team, Minutes of 2013-03-26
Present: Jesus, Gerard, Omar, Markus, Mirielle, Pat
OL described pure vs path utypes: pure is an identifier in a vo-dml document and path is (a path?) in an instance document (derived from pure, but not unique)
ML: What is the difference betwen a DM instance and a VOTable serialisation?
MD,GL: yes, the things in the VOTable are instances
OL: brought up SED/phot example w/ columns
GL: ML proposed a comprimise utype solution
ML: utype per field (path utype), then annotate the structure with the vo-dml (pure) utypes - can reconstruct the class structure
ML/GL/MD: path utypes for fields and and pure utypes for refs (eg VOTable GROUPs)
MD: we should just pick one type -- if everyone else agrees it has to be pure, so be it (but that would exclude some applications that may be in scope)
OL: need either (parseable) path or groups (pure?), not both
GL: groups with field refs
OL: didn't really see them as two alternatives, utypes are still strings (opaque labels)
GL: can only be opaque if you can look them up somewhere so pure is opaque with a prefix to tell you where to look them up
GL: can generate all possible path (utypes) for a model
JS: for
PhotDMv1-1, have to add vo-dml utypes (aliases?)
GL: list of utypes, but also need rules on how to use them (e.g. inside VOTable)
??: use path utypes but still require groups and pure utypes?
JS: "should do it" (groups)
ML: cannot force people to use groups (burden on providers to organise content according to models)
OL: but this should all be easier with pure utypes!
JS: (comment I didn't catch)
GL: (clients) should be capable of parsing and hndling groups if they are parsing a VOTable
JS: if ou have the path utypesm you can (do simple stuff esily)
GL: path "seems" simpler than navigating groups, but is it actually that much better (simpler)?
MD: for VOTable, pure and path are ~equivalent
GL:
not true paths lose some information which I describe in the text about "casting"
MD: actually want path utypes for non-VOTable applications (key-value?)
GL: possible to add GROUPs to TAP? TAP_SCHEMA? VOSI-Tables? Is empty (metadata) VOTable an option?
PD: in TAP_SCHEMA you would have potential for recursive joins in a tap_schema.groups table to mirror the recursive groups
PD/MD: VOSI-Tables would touch
VODataService which is widely used so thats messy
PD: metadata VOTable is already available with a MAXREC=0, but requires a QUERY; some metadata is only vailable that way already
GL: casting (type vs role?)
GL: are changes to VOTable on the table? :-)
all: no one seemed too enthusiastic
OL: summary -- pure utypes for fieldrefs and path utypes for fields
OL: if they are not mandatory it may be useless (too few people will include them)
JS: consider path utypes as aliases you can look up
OL: what should be required? optional? -- can't answer this question yet
ACTION on GL: write up a side-by-side comparison of 3 kinds of uses (1-2 pages?)
Next telecon: 2013-04-12T16:00:00 -- that's IVOA standard timestamp string, so 1600 UTC!
--
PatrickDowler - 2013-03-28