Participants: Gerard, Jesus, Omar, Pat

Status of the documents:

documents slowed down a lot by the events of the past weeks (including the resignation of one of the editors). Aiming for circulating documents on Monday, May 6th.

GL ivoa_profile renamed ivoa, it provides Primitive Types one might want to use directly in serializations. Should also include the Quantity Data Model.

JS Replace the current Quantity class in PhotDMv1-1 with the proposed Quantity Data Model.

PD What's the use case for Quantity?

GL It addresses a point made by Pierre that unit an ucd attributes should be normated because of the explicit VOTable support of these attributes

OL We should extend this to any types that have unit and ucd attributes.

GL True, this is another issue of the casting problem and of the simplistic nature of the utype attribute, which produces hacky solutions:

- The best way to solve this kind of issues would be to have a utype element, not an attribute. However, we don't want to change the VOTable schema.

- The 2nd best way would be utypes concatenation, in a similar way to what is widely done with UCDs. But for utypes this doesn't seem to be possible, and this was voted down by the Team anyway.

- The 3rd best way is what we have adopted: distinguish role utypes and type utypes, and distribute the information across different elements.

OL By the way, we shouldn't mix type and role utypes, since there is no way for a naive client to tell them apart, so I suggest that GROUPs can only have role utypes, and in order to mark them we need preset roles for GROUPs that serialize root elements, items in a collection, and children of a GROUP that doesn't fall under the spec (see SCS example in UTYPEs WD). So, I suggest that we use vo-dml:Instance.root, vo-dml:Instance.item, and vo-dml:Instance.role for these three cases.

GL There was a question by Pat about utypes being URIs. Pat, could you explain the motivation of your suggestion?

PD UTypes have been always used as identifiers, so they would naturally be represented by URIs. The syntax prefix:string can be interpreted as such, with the prefix (scheme) providing the means to resolve the reference. The idea is to have completely self-contained identifiers that can allow people to easily have their DMs in the IVOA.

GL Ok, but the prefix is an arbitrary, everchanging scheme. Shouldn't we have a more stable scheme? e.g. vo-dml. One might have a URI like this: vo-dml:/authority/DM#utype

On the other hand you don't want such long utypes in votables, but the stable scheme would directly provide a resolving mechanism.

PD The utype attribute provides the context for interpreting and resolving the string.

GL But what if I wanted to email it, for instance?

OL+PD One can have both: in a VOTable/VO-DML annotated file there is enough context, and our specs, that provide resolving mechanisms and references, so that the utype string can be very short (but still a URI). Outside of this context one might have a more self-contained URI unambiguously identifying a utype.

GL This URI might also be used to annotate HTML pages.

PD For URIs there are limitations on the characters, we should take that into account.

GL Question: in VO-DML I have utypes and utype-refs, then there is the utype attribute in VOTable. Should I rename the VO-DML concepts to avoid confusion?

PD Worth making it more clear. VO-DML utypes, are actually IDs, while the refs are more similar, if not equivalent, to utypes, which are references (the problem is that everyone has so far used utypes as references, but it was unclear what they were referencing). So, you might rename utypes as VODML-ID, and the utype-refs to utypes.

GL Ok, I'll make these changes. What about the VODML-ID syntax? can I use slashes, for example?

PD This would be the fragment in a URI, I believe there is more freedom there, I'll provide something offline.

GL I would like to have some freedom in making some choices in the VO-DML schema, in order to simplify it. Can I proceed?

ALL Yes.

OL The mapping document is still lacking a proper mapping pattern for extensibility. Discussed this a lot with Gerard, I will circulate a proposal asap to the list.

JS We need to decide who presents what during the Interop, especially at the TCG.

Matthew might introduce the work of the Tiger Team and provide an overview, while Omar might illustrate the technical part of the document. Need to ask Matthew.

GL What about the plenary session?

JS That's up to the TCG chair and vice-chair.

PD I would also like to point out the good impact of this specs on the DAL WG, stressing that we can use this spec without being forced to make changes.

GL DM WG chair and vice chair, please provide me with a list of DMs to translate in VO-DML as examples. I will also present the very positive impact that this spec will have on SimDM at the Theory Session.

JS will email Matthew for the TCG and Plenary session agenda.

We will have a new meeting next week, same day, same time.