UtypesTigerTeam telecon 2012-11-27

Participants

OL Omar Laurino

MG Matthew Graham

MD Markus Demleitner

PF Pierre Fernique

PD Pat Dowler

GL Gerard Lemson

Action items from last time

JS: get VOSpec utypes usage: Usage of utypes in VOSpec distributed to tiger team members. JS to put the info in Volute before to formally close the action

MG (fallback MD): Solicit more Apps feedback: Only VO-IRAF pending. See new action item on OL

JS+GL+MD: Provide some example serializations (with references and collections if possible?): Action not finished yet. Discussions held between GL and MD on how to use groups to represent the serialization. If template is created JS will insert consistent metadata to create a "real" example.

Today's agenda:

GL distributed URL with a VO-DML example https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/models/sample

OL VO-DML XML process contains a XMI magicdraw representation (not standard)

GL VO-DML XML could be written by hand. Not necessary to write magic draw to derive it. It is simpler to create a small UML as starting point

OL enumerates deferred items from previous teleconf:

Implementation effort

MD Pierre asked about the impact on the VOTable generator. It should be deferred again until having the PhotDMv1-1 example (at least)

Validation

At very least, validation will include the utypes checking (string comparison with existing VO DM) but as soon as there is a new DM or a DAL service, a new validation is needed.

With the new schema, at least a general validator could be created. This is in the use cases.

MD In practice, the "syntactic" validation of documents that is provided by such tools is only part of a full validator; we should be careful not to promise turn-key full validation.

GL Different levels of validation. Some of them are easier. Utypes check and warnings (like schema validation).

Grouping in TAP schema

MD Can we represent GROUPs in TAP schema? We run with similar problems with Europlanet (link distributed) http://dc.zah.uni-heidelberg.de/__system__/dc_tables/show/tableinfo/tap_schema.groups

This could be not enough

GL If we need to do it in groups in VOtable we should probably do it at DB level

JS Ask for clarification on the target of this effort

GL This could be used to infere that two fields are together and also could be used for the response

OL it this related with utypes? Is this related with DM serialization?

GL Yes, it is related with DM serializationin some way

OL TAP schema is now defining a DM

GL This could be used also to express in a DB an existing DM

OL Why not to use VO-DML

GL it is a different thing. It is not a 1-1 mapping. Some part of DB could represent a part of a certain DM

MG This could be out of the scope of the utypes Tiger Team

GL Although not the main tiger team target, this is a concern on utypes

MD If we target TAP_SCHEMA, we probably should also deal with VOSI tables.

MG Use of utypes in VOSI is marginal

MG request for a clear schedule on tiger team deliverables

GL working draft for next interop? VO-DML and mapping in VOTable

GL+MD+Pierre+Jesus on preparation of serializations

PF complains on some details inside VO-DML example: e.g. units are outside the field, so the use is different than in standard VOTable

OL asked if there is an agreement within the Tiger Team about VO-DML (or a closer concept) as a good approach to handle utypes?

GL Two different aspects has to be discussed: how to express UML and how to map to VOTable. First point looks clearer

OL Is it a good approach for first point?

PF SED example distributed... is there a way to express this example with this approach

GL if there is not a standard DM behind, there are not utypes and utypes cannot therefore used. That implies that a UML should be created

PF if the DM is too complex to describe the approach is difficult

MD Probably this is going to be clarified with the examples

GL Other point, the prefix stuff. Is this going to be used to reference a IVOA schema. This could connect with PF question on representation of a DM not standarized yet into IVOA. However the prefix could be not enough

MD To follow the string comparison approach, the utypes should be constant (this could be a problem for extensions) That implies the prefixes should be constant

If we can, we should even try to keep the strings constant over data model changes (at least extensions). To still allow figuring out the URI "of the data model" (say, the VO-DML definition for it), we have DataModel.URI in the STC serialization.

OL Where the prefix is useful is avoided clashes, so same utypes can be understood in a different way (not in string comparison). This is related with the namespaces.

GL I think it has certain use to identify the DM

Goals for next teleconf:

GL continue with the work I have started on examples. Do you have time for this Markus?

MD Examples will be circulated in two weeks

MG use cases document will be also closed in two weeks. Not clear if this is going to be published as a note

Next telecon: Two weeks, same time, same place.

Open Action Items:

OL to distribute use of utypes in IRIS

JS to put VOSpec utypes use in Volute

JS+GL+MD+PF: Provide some example serializations

<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup
-->