<--
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 |