Difference: UtypeTigerTeamMinTel8 ( vs. 1)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Minutes telecon 8, 2013-01-29

Minutes by Gerard
Attendants: MD, ML, OL, MG, GL, JS, PF, PD

Agenda:
GL Have produced a draft of adoc aiming to describe how VO-DML can be serialized in VOTable and annotated with
utypes to show how VO-DML instances are stoeed. MD has read and thinks too scary to send around in current form.
MD and GL will meet this Friday and discuss. Also with goal to evaluate with the more traditional
path-like approach. This could be derived form the more explicit one (using GROUP hierarchies etc).
MG exec wants progress report, so time pressure.
MD we'll have something pretty after this friday.
GL want to be as explicit is possible, but can (and must) be simplified.
MD we need something like this.
MD we may want to discuss issue "what are utypes"
"pointer into data model"?
utypes point into data model instances
GL more as a path
MD indeed to be need more precise, a "pointer to a role"
for what MD needs ot do with utypes, needs role identifiers
if only points to type, would need also role.
OL have issues here (3)
1. need description of data models, need meta model (= VO-DML)
need a working draft VO-DML meta-model.
2. how to serialise instances (GL+MD work on)
3. need verify current data models, so that we have a consistent way of describing them.
GL Do you mean we need refactoring of existing data models?
JD it is not the task of this effort to refactor
MG no, should not do that
OL what are we going to describe then?
MG (missed this) should NOT force code rewriting due to refactoring.
GL Not intended. Can we try to interpret existing DMs + utypes so that the concepts remain preserved?
MD can do this eventually, migrate dm-s
But can we save the existing utype-s ?
GL may only need to attributes-of-attributes
OL Yes. (I think)
MD Prefer "role identifier" interpretation.
A single thing in VO-DML, but multiple roles: target.position.ra, image.position.ra
GL This is what "my" approach also alows, but requires GROUPing. May be flattened.
Should have agreement by Friday
MD who thinks they know what we are talking about?
OL agree with MD
ML need utype-s to talk to tiniest parts of data model.
need to talk to attributes-to-attributes
GL May need to work out explicit mapping to see what simplification we might make and what restrictions
we might put on them.

ML how about photometry data model.
any one have a serialisation?
GL was only an interpretation
JS will try to put real data in VO-DML version of photometry and evaluate it.

MD existing usages doc is ok!?
MG should be out by end of the week.
MD what does tht mea, Note?
MG yes! is a deliverable. exec wants it.
MD MD should be in (for technical help with Paul Harrrison thing), ask for feedback of group.
MG next week is still ok.
OL how to build HTML from usages doc
MD can be made simpler. ant? upload some jar into volute?

JS who will be in ESAC this week to discuss photdm maybe?
MD yes.
ML no.

ML when can we deliver tiger team expertise to whole IVOA?
MG need to have more definite results. Say WD of doc
ML don't wait too long.
MG cannot wait too long, must deliver May 12.
JS schedule for draft?
MG set it up in Dec.
MD we would come up with first draft with utypes doc and VO-DML, after that go to DM WG.
Should have time enough.
OL am working at prototypes. would like to show at interop.
seem to be working on details now. need to write them down.
succesful solution should be almost trivial.
utypes are opaque strings, description in VO-DML.
value in prototypes.
JS need a plan for draft. need to divide work. make skeleton of doc.

OL meet next week?
ML ok, like to see on photdm validation in VO-DML with JS.
JS can work on it.
OL can we hope to have a skeleton + agreement.
MD sure, but may need 2 weeks for next telecon.
OL next week, then 2 with different actions.
GL next week on VO-DML,
OL 2 weeks from now discuss writeup on votable+utypes (MD+GL).
JS next week on VO-DML in photdm