Utypes Tiger Team, Minutes of 2013-03-26Present: Jesus, Gerard, Omar, Markus, Mirielle, Pat | ||||||||
Changed: | ||||||||
< < | 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 PhotDM, 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! | |||||||
> > | 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
<--
|
Utypes Tiger Team, Minutes of 2013-03-26Present: Jesus, Gerard, Omar, Markus, Mirielle, Pat | ||||||||
Changed: | ||||||||
< < | 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 (pure!) 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 PhotDM, 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! | |||||||
> > | 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 PhotDM, 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
<--
|
Utypes Tiger Team, Minutes of 2013-03-26Present: Jesus, Gerard, Omar, Markus, Mirielle, Pat | ||||||||
Changed: | ||||||||
< < | Working on this now... | |||||||
> > | 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 (pure!) 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 PhotDM, 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! | |||||||
Changed: | ||||||||
< < | -- PatrickDowler - 2013-03-27 | |||||||
> > | -- PatrickDowler - 2013-03-28 | |||||||
<--
|
Utypes Tiger Team, Minutes of 2013-03-26Present: Jesus, Gerard, Omar, Markus, Mirielle, Pat Working on this now... -- PatrickDowler - 2013-03-27<--
|