UtypeTigerTeamMinTel10 < IVOA

IVOA Web>WebPreferences>UtypesTigerTeam>UtypeTigerTeamMinTel10 (2013-02-19, MarkusDemleitner) (raw view)

Utypes tiger team, telecon of 2013-02-19


Gerard, Omar, Matthew, Markus


GL: Evaluated use cases wrt satisfiablity with VO-DML.  Most can be
handled, some look more like "we need proper data models" (like all of
7).  Will send around a document.  Work in progress: create code for
simple, in-memory Java objects from VO-DML; this would cover use cases 1
and 2.

OL: Do we agree that DM standardization is useless without a formal
definition what a DM is?

GL: Well, right now, we have an XSD for each data model, which says
how instances look like

OL: ...but not in VOTable.

GL: The VOTable issue is that DM serialization in there is not
standardized:  We're now talking about how to stuff DMs and parts of them
into VOTable.

OL: ...or you drop some foreign format into VOTable elements...

GL: Part of the problem is that we don't have terribly useful data
models

OL: ...but SED and Spectrum are useful, but we're held up by the fact
that basically all our data is FITS.

[Discussion about Spectrum DM serializations, VOTable, FITS, native XML,
where native XML basically isn't used, but it could work without utypes]

GL: XML serialized Spectra are very large.  Going this way would at
least take much further exploration.

OL: The trouble isn't really with spectral but with SEDs.  It was the
photometry points that gave us trouble.

GL: Haven't yet created any examples that use path-like expresions
(attr.attr.attr).  Does anyone still want to see those?

OL: Since fields don't have utypes any more, can't we use the utype
attributes on FIELDS for these attr.attr.attr utypes?

GL: That would make it extra-complicated.

MD: Also, a single utype is not enough in general; e.g., STC annotation
for SSA responses.

GL: What about the concatenated utypes ("role+type")?  In principle, we
don't need it because you can look up the type.

OL: I don't think you'll match the GROUP utype, so it's not terribly
useful.

GL: Well, I might start looking for, say, instances of sky positions,
and I need group utypes for that.  Just based on the utype, a generic
library can deserialize such a thing.

OL: In order to do that, you'd want to represent the entire inheritance
hierarchy, otherwise you'd miss some instances you might be able to
handle.

GL: If you want to use your Geometry code to parse a sky position,
you'll have to understand the data model.

OL: Then the plus doesn't buy you much, because all information I get
from the additional type markup I already get from other sources.

MG: What's the status of the existing utypes when we adopt this?

GL: I think they'd be fine.  We could also say in the utypes spec: The
following DMs have predefined utypes, which remain valid until someone
does new-style ones at some point.

GL: Pierre suggested going publick at this point.  I think that would be
premature.

MG: So do I.

GL: Do people think it's useful to keep the formalistic part 5 in the
current discussion document?

OL: I do.

GL: Should I have examples with path expressions ("compromise utypes")?

OL: I do think that's useful.  We'll need something like this in sale
anyway.

Next telecon: 2 weeks from now (TCG next week)
<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Topic revision: r1 - 2013-02-19 - MarkusDemleitner

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema