<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi Gerard,
<div><br>
</div>
<div>Since we are virtually colocated, let's get together in person to chat about this. Any such discussions could be opened to a wider audience as needed, but let's meet first and decide the next step from there. I'm available Friday and most afternoons
next week.</div>
<div><br>
</div>
<div>Here are some items I think would be helpful to go over:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Interactively review the proposals, making sure that I fully understand the content along with any nuances you may think of.</li></ul>
</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Implications on data providers:
<ul>
<li>Is it practical to create unambiguous representations of your data?</li></ul>
</li></ul>
<div><br>
</div>
<ul class="MailOutline">
<li>Implications on data consumers (apps):
<ul>
<li>Is it practical to parse the VO Table?</li><li>Is it practical to determine the semantics of the VO Table?</li><li>To what extent is it necessary for simpler clients to determine the semantics of the new annotations?</li></ul>
</li></ul>
<div><br>
</div>
<ul class="MailOutline">
<li>From both the data provider and consumer sides:
<ul>
<li>Are there use cases that have been implemented to help demonstrate this? </li><li>What use cases would be good candidates for demonstration/prototype implementations?</li></ul>
</li></ul>
</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Identify the next step(s) to move this forward and make a rough timeline.</li></ul>
<div><br>
</div>
</div>
<div>
<ul class="MailOutline">
<li>Any other topics you're interested in.</li></ul>
<div><br>
</div>
</div>
<div>As may be obvious from some of those bullets, I think it will be very important to have as many sample implementation attempts as possible from the both the provider side and the consumer side. Such vetting is the only way to isolate the practical problems
that exist within solid theoretical approach.</div>
<div><br>
</div>
<div>I'm not suggesting that we need implementations for all the proposals, just that before any new approach is fully approved, it should have been vetted by implementing some real world use cases. I will be enthusiastic about helping with some sample implementations,
but will be time-limited.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Tom</div>
<div><br>
</div>
<div><br>
<div>
<div>On Feb 12, 2015, at 4:49 AM, Francoise Genova <<a href="mailto:francoise.genova@astro.unistra.fr">francoise.genova@astro.unistra.fr</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Hi Markus,<br>
<br>
In view of the potential consequences on Apps I strongly suggest that the debate is kept on the two lists, dm AND apps. VOTable is Apps and this is a VOTable topic.<br>
<br>
Cheers<br>
<br>
Francoise<br>
<br>
Le 12/02/2015 10:38, Markus Demleitner a écrit :<br>
<blockquote type="cite">Hi,<br>
<br>
To avoid excessive crossposting, I'd suggest to move this discussion to<br>
<a href="mailto:dm@ivoa.net">dm@ivoa.net</a> exclusively.<br>
<br>
Then:<br>
On Wed, Feb 11, 2015 at 11:02:29AM -0500, Gerard Lemson wrote:<br>
<blockquote type="cite">It would be nice if we could quickly agree how to annotate VOTable elements<br>
with metadata pointing to VO-DMl data models.<br>
</blockquote>
Yes! Please!<br>
<br>
<blockquote type="cite">In the votable/vo-dml session in Banff we came to a decision to add a new<br>
element to VOTable that would represent this mapping and would take the<br>
place of the utype attributes we had assumed to use for that in the current<br>
mapping document in<br>
<a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx</a><br>
</blockquote>
If any of the opponents of using utypes have reconsidered in the<br>
meantime, this would be an excellent opportunity to speak up and save<br>
us the trouble of having to change VOTable -- I still maintain<br>
utypes-only would be perfectly workable, and it definitely has a much<br>
cleaner migration path.<br>
<br>
Assuming utype's not going to happen, here's my takes on Gerard's<br>
proposals (note: I've not even tried implementation with any of<br>
these, contrary to a utypes-only approach; hence, this may miss<br>
extremely important points or be plain wrong).<br>
<br>
<br>
<br>
(1) <a href="http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml">
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml</a><br>
<br>
<PARAM name="name" datatype="char" arraysize="*" value="ivoa"><br>
<VODML type="ivoa:string" role="vo-dml:Model.name"/><br>
</PARAM><br>
<br>
I like this for its relative simplicity. I cannot quite see the<br>
consequences of allowing mutiple such annotations (see also below),<br>
but allowing the declaration of both type and role actually helps<br>
compared to a utypes-only situation (but IMHO only with atomic types;<br>
if this attribute were a complex type, I believe the type annotation<br>
should be there and *not* in the reference). I could definitely live<br>
with this.<br>
<br>
(2) <a href="http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4b.xml">
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4b.xml</a><br>
<br>
<VODML><br>
<TYPE>src:source.AlignedEllipse</TYPE><br>
<ROLE>src:source.Source.positionError</ROLE><br>
<ALTTYPE>src:source.SkyError</ALTTYPE><br>
</VODML><br>
<br>
I'm not so sure I'm too hot about enabling multiple types, let alone<br>
in a single annotation -- of course, this sounds nifty as it seems to<br>
facilitate best-effort parsing (which I'm always a fan of); this would<br>
let a generic client work out that a FancyPhotPoint (which it doesn't<br>
know) actually is-a PhotPoint with some additional information, so<br>
the generic client can still make a PhotPoint out of what it found<br>
and ignore the rest in a safe fashion.<br>
<br>
Of course, by inspecting VO-DML documents it could work that out by<br>
itself, but it'd need to look at all these external documents, and<br>
enabling best-effort without having to manage external resources<br>
(which keep breaking) would clearly be preferable.<br>
<br>
But then having TYPE *and* ALTTYPE at the same time intutively seems<br>
wrong to me; I'd have to read up on type theory to figure out if<br>
there's a useful type concept that would allow sensible statements<br>
like these. I'd be less worried about BASECLASS.<br>
<br>
FWIW, my strong preference would be for something like duck typing<br>
anyway, where best-effort parsing would be enabled through fixed,<br>
well-known role names (that, in contrast to current utypes, would<br>
still have a formal definition and meaning; that's the all-or-nothing<br>
thing). For instance, a program could rely on phot:zeroPost to be a<br>
photometric zero point, and whatever object that's in could serve as<br>
a means to figure that out, even if the client didn't know the actual<br>
type that thing has (e.g., because it was extended to contain<br>
provenance information and thus has a new type).<br>
<br>
In the example cited above, incidentally, I'd have to say an error to<br>
me is a role and not a type; with that, the problem doesn't even turn<br>
up, as you'd have somethign like<br>
<br>
<GROUP id="890"><br>
<VODML><br>
<TYPE>src:source.AlignedEllipse</TYPE><br>
<!-- no role, no additional type --><br>
</VODML><br>
...<br>
</GROUP><br>
<br>
<GROUP id="position"><br>
<GROUPref ref="somethingelse"><br>
<ROLE>src:value</ROLE><br>
</GROUPref><br>
<GROUPref ref="890"><br>
<ROLE>src:error</ROLE><br>
</GROUPref><br>
</GROUP><br>
<br>
In addition, if we agree that within a given structure, role is<br>
unique, an attribute on GROUPref would do would make this a lot more<br>
compact.<br>
<br>
And yes, if we muck around with VOTable anyway, then let's add<br>
GROUPref. It makes whatever annotation we decide upon a whole to<br>
more straightforward.<br>
<br>
(3) <a href="http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4c.xml">
http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4c.xml</a><br>
<br>
<VODML><br>
<TYPE>src:source.AlignedEllipse</TYPE><br>
<TYPE>src:source.SkyError</TYPE><br>
<ROLE>src:source.Source.positionError</ROLE><br>
</VODML><br>
<br>
In contrast to (2), the difference is that there's no "preferred"<br>
type any more. Again, I'd have to read up on type calculus before I<br>
stop being skeptical about two types, regardless of whether or not<br>
there's an explicit preference.<br>
<br>
<br>
<br>
Summing up: Without having implemented anything at this point<br>
(meaning: it wouldn't take much to convince me of something else), I<br>
believe 4a can do everything we need to do. It's also the most<br>
straightforward and compact option (probably even more compact than<br>
just using utype). Assuming utype's really out, it gets my vote.<br>
<br>
But if we touch VOTable, I want a GROUPref element in addition to<br>
VODML (and it'd not be so easy to convince me otherwise).<br>
<br>
Cheers,<br>
<br>
Markus<br>
</blockquote>
</blockquote>
</div>
<br>
</div>
</body>
</html>