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)