<div dir="ltr">HI Matthew etal<br><div class="gmail_quote">On Tue, May 10, 2016 at 10:18 AM, Matthew Graham <span dir="ltr">&lt;<a href="mailto:mjg@cd3.caltech.edu" target="_blank">mjg@cd3.caltech.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">So once we have a mapping standard with reference implementations any DM model specified in VO-DML could automatically have a reference implementation (according to these criteria) which would make life easier. Time to get that mapping spec out :)<div><br></div></div></blockquote><div>Hear hear!</div><div><br></div><div>Though I think that there is something more to be said about your first email in this trail.</div><div>In particular I was responding more to the requirements on VO-DML becoming a standard.</div><div>Turning an actual data model into a standard would require the standard itself (which should from now on be valid VO-DML/XML+document explaining it) and possibly two interoperable implementations of the data model itself. </div><div>I think that an implementation of a data model is an instance of the data model. I.e. a set of instances of types in the model. This requires a serialization of these instances (i.e. your item 2). This could be in  a standard/custom format, for example a  or in an annotated VOTable.</div><div>Interoperability of a data model could be a set of instances that can be used by a common tool. </div><div>As to OMar&#39;s soft requirement, I think that would apply to the data-model-standard issue. I think for standardizing VO-DML we must show interoperability between different models. And in VO-DML that requires having examples of model imports I think. I don&#39;t think that is a problem though.</div><div><br></div><div><br></div><div>Gerard</div></div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><br></div><div><br><div><div>On May 10, 2016, at 4:00 PM, Laurino, Omar wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div>Hi,<br><br></div>I agree with Gerard that items 1) and 2) look like the same, unless one brings in a standard for instance serializations. Since we can have standardized mapping strategies (as different recommendations) that map instances of valid VODML/XML models and their standard serializations, I don&#39;t think a valid serialization of an instance should be required for data models: this should be guaranteed by the mapping standard(s) and their reference implementations.<br><br></div>As for the ModelImport requirement, it makes sense for &quot;low level&quot; models but not for &quot;high level&quot; ones, plus there is no way to guarantee that all types defined by a model are extendable/usable by other models. It gets too complicated.<br><br>I would suggest we include the &quot;model import&quot; evidence as a &quot;soft requirement&quot;, to be evaluated on a case-by-case basis depending on the use cases of the model. For STC, it makes a lot of sense to require this additional proof of interoperability, because the model is intended to be a building block for other models.<br><br></div>Or, we might be to *require* that at least one reference implementation is a mission/archive/service-specific model that extends the standard one. So, if we had a model for Sources/Catalogs, at least one reference implementation should be a mission/archive/system-specific model that proofs the model can be meaningfully extended by actual specializations. Other than properly validating as VODML/XML, this model should be evaluated for its domain-specific content, and that&#39;s probably not something you can automate. This should also be a good way to involve implementors from the community, so it&#39;s probably my preferred one.<br><div><div><br></div><div>Omar.<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 9:38 AM, Gerard Lemson <span dir="ltr">&lt;<a href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi<div>What is meant by item 2, &quot;<span style="font-size:12.8px">An XML serialization of the DM&quot;.</span></div><div><span style="font-size:12.8px">The standard representation (serialization?) of a VO-DML data model is VO-DML/XML, i.e. XML. And that is the representation that can be validated (step 1?) using automated means, for example using XSLT scripts in the vo-dml/xslt folder on volute@gavo.</span><br></div><div><div><span style="font-size:12.8px">If 2) is meant to imply an XML serialization of an *instance* of the model, that we can only do once we have a standard XML representation of instances of models. That does not yet exist. The original VO-URP framework does contain an automated XML Schema generator for its version of VO-DML, that has not yet been ported to VO-DML.</span></div></div><div><span style="font-size:12.8px">And of course t</span><span style="font-size:12.8px">he mapping document describes how one can describe instances serialized in VOTable, but that is a different standard.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">For what it&#39;s worthy, I think that an &quot;implementation of VO-DML&quot; is a data model expressed using that language (in VO-DML/XML to be precise) and validated using software. The latter enforces that the language should allow automated validtion.</span></div><div><span style="font-size:12.8px">I think interoperable implementations of VO-DML are two or more valid models that are linked by &quot;modelimport&quot; relationships. I.e.one model &quot;imports&quot; the other(s) and uses types from the other as roles or super types in the definition of its own types. This is supported by the VODMLID/VODMLREF meachanism of the language.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers</span></div><span><font color="#888888"><div><span style="font-size:12.8px">Gerard</span></div><div><span style="font-size:12.8px"> </span></div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 9:04 AM, Matthew Graham <span dir="ltr">&lt;<a href="mailto:mjg@cd3.caltech.edu" target="_blank">mjg@cd3.caltech.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We&#39;re trying to define specifically what would satisfy the reference implementation requirement for an IVOA Spec in the context of a data model. The proposal is that:<br>
<br>
(1) If the DM has been described using VO-DML it can be validated as valid VO-DML<br>
<br>
(2) An XML serialization of the DM can be validated<br>
<br>
so therefore is the combination of the two sufficient to demonstrate the validity and potential interoperability of the data model (which is the purpose of the reference implementations).<br>
<br>
        Cheers,<br>
<br>
        Matthew</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><span class="HOEnZb"><font color="#888888"><br>-- <br><div><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><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>
</font></span></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>