<div dir="ltr"><div><span style="font-size:13px;font-family:Arial">Hi All,</span></div><span style="font-size:13px;font-family:Arial"><div><span style="font-size:13px;font-family:Arial"><br></span></div>During the Banff Interop discussion on the VOTable changes there was a question regarding the use case behind the "alternative type" representation. Here is a detailed description of such use case and the requirements related to it.</span><div><font face="Arial"><br></font></div><div><font face="Arial">Please let me know if you have any further questions.</font></div><div><font face="Arial"><br></font></div><div><font face="Arial">Cheers,</font></div><div><font face="Arial"><br></font></div><div><font face="Arial">Omar.<br></font>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">It is rather common for data providers to have specific data models for their datasets, and such models can usually be represented as extensions of a standard one (two examples are the NED SED service w.r.t. SpectrumDM and the SVO Filter Profile Service w.r.t PhotometryDM).</span><br>
<span style="font-size:13px;font-family:Arial">On the other hand, a strong requirement we had for the UTYPEs, and that still applies with any alternative to UTYPEs (I am referring to these strings as "vodml references" in the following), was that "naive" clients had to be able to find the metadata they are looking for by just assuming knowledge of the data model they are interested in (*).</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">Referring to the examples we have made so far, assume you have a Source DM, where a Source has a position of type SkyCoordinate, defined in the STC2 model, one has these vodml references defined:</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">src:Source (type)</span><br>
<span style="font-size:13px;font-family:Arial">src:Source.position</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">stc2:SkyCoordinate (type)</span><br>
<span style="font-size:13px;font-family:Arial">stc2:SkyCoordinate.longitude</span><br>
<span style="font-size:13px;font-family:Arial">stc2:SkyCoordinate.latitude</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">A naive client must be able to find these vodml references in the serialization, so they cannot be obfuscated by extensions.</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">Let's say a specific provider extends the Source class by adding a mission-specific or datacenter-specific attribute. We will have a MySource DM that introduces two new vodml-ids:</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">my:Source</span><br>
<span style="font-size:13px;font-family:Arial">my:Source.custom_attribute</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">A naive client must still be able to identify a my:Source instance as a src:Source without having to parse the vo-dml/xml document.</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">Thus, here is how the serialization would look like in VOTable according to the current UTYPEs mapping document (omitting the unnecessary VOTable attributes):</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial"><GROUP utype="vo-dml:Instance.root"></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="vo-dml:Instance.type" value="my:Source" /></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="vo-dml:Instance.type" value="src:Source" /></span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial"> <GROUP utype="src:Source.position"></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="vo-dml:Instance.type" value="stc2:SkyCoordinate" /></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="stc2:SkyPosition.longitude" value="..." /></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="stc2:SkyPosition.latitude" value="..." /></span><br>
<span style="font-size:13px;font-family:Arial"> </GROUP></span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="my:Source.custom_attribute" value="..." /></span><br>
<span style="font-size:13px;font-family:Arial"></GROUP></span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">Despite the fact that a naive src:Source client does not know anything about my:Source (and doesn't care, in this use case), it can still find all the vodml references it needs without having to parse the VO-DML/XML document. This is true because the root instance is declared as both my:Source and src:Source:</span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="vo-dml:Instance.type" value="my:Source" /></span><br>
<span style="font-size:13px;font-family:Arial"> <PARAM utype="vo-dml:Instance.type" value="src:Source" /> </span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">So, the naive src:Source client can query for a GROUP[PARAM[@utype="vo-dml:Instance.type" and @value="src:Source"]] and then get all the attributes it needs in order to build an instance of a src:Source.</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">In other terms, one can safely upcast representations of VO-DML instances without having to parse the VO-DML/XML description, so the original use case (and attached requirements) is fulfilled.</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">Notice that this extensibility problem was one of the main drivers of the whole UTYPEs effort, as we had big issues in implementations of the SED Builder case, and we were foreseeing the same issue for the Cubes effort. As we didn't want to employ unsustainable ad-hoc solutions for each data provider we designed a generic framework that works in many different scenarios.</span><br>
<span style="font-size:13px;font-family:Arial"></span><br>
<span style="font-size:13px;font-family:Arial">(*) The definition of "naive" client is provided in the Mapping document. In a nutshell, a naive client assumes knowledge of a Data Model in the form of a bunch of utypes (vodml references) and does not need, or want, to parse the data model standard description files, i.e. VO-DML/XML.</span><div><span style="font-size:13px;font-family:Arial">A "naive" client is only "naive" when it comes to DMs, not VOTable parsing, obviously.</span></div><div><span style="font-size:13px;font-family:Arial">VO-DML and the Mapping documents are designed to make simple things consistent and not ad-hoc while enabling many advanced use cases.</span><br>
<span style="font-size:13px;font-family:Arial">In this sense, it is not like "naive" clients are "stupid", but they are distinguished from clients that harvest the full potential of the VO-DML framework and can just ignore it, focusing on the few utypes they are really interested in.</span><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 5:47 PM, Gerard Lemson <span dir="ltr"><<a href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all<br>
<br>
During the VO-DML-in-VOTable discussion at the last interop we decided to go<br>
with (something like) proposal 4 on the wiki at<br>
<a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab
le/VOTable_Prop4.xml" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab<br>
le/VOTable_Prop4.xml</a> Other options can be found in the same folder.<br>
What we now need is to finalize the design for the XML tag(s) to add to<br>
VOTable.<br>
I have created a mockup of an XML schema with a complexType definition<br>
reflecting the new element.<br>
The design used in proposal 4 above is represented by proposal 4a in the<br>
schema. It has attributes for role and actual type, and elements for<br>
alternative types. Proposals 4b and 4c vary on this theme. All use a<br>
simpleType definition reflecting the model-prefix+':'+vodml-id pattern used<br>
to refer to VO-DML elements. See the mapping document for more detailed<br>
descriptions (taking into account the fact that that document will have to<br>
be updated with the choice to be made here).<br>
<br>
Note, I am not making statements on whether these two types must be in the<br>
VOTable targetnamespace. Andreas had some thoughts on this that I hope he<br>
will send to the list in reply.<br>
<br>
And obviously the final design may differ from these proposals if necessary,<br>
but let's please converge on an acceptable design soon so Omar and I can<br>
update the mapping document.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Gerard<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><span style="color:rgb(136,136,136)">Omar Laurino</span><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">Smithsonian Astrophysical Observatory</span><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">Harvard-Smithsonian Center for Astrophysics</span><div style="color:rgb(136,136,136)"><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div style="color:rgb(136,136,136)"><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div>
</div>