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

Topic revision: r4 - 2021-04-13 - GiuliaIafrate
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback