<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"><<a href="mailto:mjg@cd3.caltech.edu" target="_blank">mjg@cd3.caltech.edu</a>></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'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'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'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 "low level" models but not for "high level" 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 "model import" evidence as a "soft requirement", 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's probably not something you can automate. This should also be a good way to involve implementors from the community, so it'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"><<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"><div dir="ltr">Hi<div>What is meant by item 2, "<span style="font-size:12.8px">An XML serialization of the DM".</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's worthy, I think that an "implementation of VO-DML" 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 "modelimport" relationships. I.e.one model "imports" 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"><<a href="mailto:mjg@cd3.caltech.edu" target="_blank">mjg@cd3.caltech.edu</a>></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'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>