Utypes Tiger Team, Telecon of 2013-04-23

Present: Jesus, Gerard, Matthew, Omar, Markus (with some connection problems...)

Matthew: The documents are approaching TCG-readiness, although there are still minefields to be navigated. We need to demonstrate that our process has been open and fair, then disagreement is not a problem.

Markus isn't a big fan of Chapter 6 or the serialization document -- he feels it's too complex to mollify people while being too simple to be convincing (in particular, the bSTC stuff has irritated even people within the Tiger Team) -- so people will start to talk about the toy models being wrong rather than our method being (basically) right.

Gerard: we could maybe use the TAP_SCHEMA? That's basically done. Or do we want to sell the current chapter 6 as a core of a source data model? TAP_SCHEMA doesn't have good collections, so having photometry in there would be useful. And we really need a source data model anyway. We could cut out everything that looks like STC.

Omar: Real-life examples are good, in particular because we've been attacked for being too abstract. But coming up with a new source DM would be a distraction, too, so let's keep this within where there already are IVOA DMs.

Markus: I'd like to keep some of the more funky headings out of the ToC. Also, most data models talk about "Quantity", i.e., things with units (and maybe UCDs and other metadata that VOTable FIELDs and PARAMs have). We should have a small model for that and special rules for serializing them to VOTables.

Gerard: There's been an effort for this about 10 years ago. That eventually fizzled out after becoming too large. But true, we should have that.

Omar: We should talk about Axes as in Characterization, which might lessen resistance.

Markus+Gerard: These have errors, and bin sizes and lots of other metadata. To define an Axis, you already need Quantities, and these are a special case anyway, because VOTable has native ways to represent those.

Jesus: We need to keep these distinct from Measurements (which would have errors and such).

Omar: So basically, we don't want xy.unit utypes in VOTable PARAM?

Gerard: Well, it could be that you store the unit in a FIELD -- then it would be necessary to have such utypes in FIELDrefs, so they shouldn't be outlawed as such, they just shouldn't be used in VOTable serialed values.

Markus: Let's first see what the actual spec will look like.

Gerard: There are now three parts in the VO-DML document -- should these be merged? In how much detail should the Schema be document? Or can we say the Schema is an integral part of the spec?

Matthew: We can probably do the latter, but whatever is less work is fine.