UtypeTigerTeamMinTel12 < IVOA

IVOA Web>WebPreferences>UtypesTigerTeam>UtypeTigerTeamMinTel12 (2013-03-19, MarkusDemleitner) (raw view)

WYSIWYG content - do not remove this comment, and never use this identical text in your topics
---+ Utypes Tiger Team, Minutes of 2013-03-19

Present: Jesus, Gerard, Omar, Matthew, Markus, Pierre

GL: Markus and I discussed how much we can do with path-like utypes pointing at "concepts". I created some machinery to generate the path expressions using reasonable rules; look at the sample https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/models/sample/Sample.html Basically, embedding is in utype, referencing and collection in container format (see under section 4). The double slashes in there are typographical (black slashes are separators).

The path expressions have issues and are inferior to the pointers into the data model in that, e.g., with polymorphism, it's much harder to figure out the actual type of objects. An example are the positionErrors. Still, usages of the path utypes appear to be mappable to and from usages of pure utypes.

OL: Can't we then have the path utypes in utype attributes of FIELDs an in similar places, the pure utypes in groups?

MG: We can't sell this.

MD: ...and we don't want that, if only it would confuse everyone. Again: We need to figure out what utypes point to: DM elements or DM instance elements?

GL: Well, utypes don't necessarily "point". They're an annotation tool. If you have a group, the utype would naturally denote a type. The PARAMs inside of it, on the other hand, have utypes that relate to attributes and not types. So, we need to see what description works better for what.

There's also now some code that extracts DMs from VOTables to some internal represenation of instances of objects; see https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/examples/2mass_concat.votable.DM.xml for an example (annotated with pure utypes). The hard part is referencing.

MD: I like this vodmli since it lets us talk about DM instances easily, which is good if we want path utypes.

OL: Suppose I'm a stupid client; with pure utypes I can immediately say there's sky coordinates in there just by looking at the utypes. With path utypes, I couldn't, and I'd have to read the VO-DML.

MD: Right -- we have to decide if we want to make this possible by just looking at the utypes or whether we want to be able to tell apart, say, target RA of center of observation RA in utypes.

OL: If you want that, you have to parse utypes.

JS: Well, TOPCAT doesn't parse GROUPs so far at all...

GL: Statements on what's "easier" or "harder" are hard to validate, so that's probably a bad guideline. The pure utype approach covers all use cases that have to do with DMs in VOTables. Plus, we can probably give up anyway if we can't use GROUPs.

JS: Raises some issues with pure utypes and TAP, will write them up on-list.

GL: Also, utypes don't need to solve every problem they were at some point suggested for.

MG: Until the interop we have to provide some document that says how to come up with utypes from VO-DML.

OL: Action on all of us: If there are objection to the pure utypes, send them around before the next telecon. Also, could everyone say what they think our deliverable to the interop should be?

Next Telecon: 2013-03-26

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Topic revision: r1 - 2013-03-19 - MarkusDemleitner

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema