<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 5:51 PM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> Since the value is directly tied to the definition of the EnumerationLiteral, these<br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> are the values which data providers MUST give when representing these literals.<br>
><br>
</span>No, this is absolutely not true.<br>
Data providers SHOULD annotate the enumerated values that appear in their own data sets with vodml-refs identifying the VO-DML EnumLiteral in some model that (best) represents their value. That's it.<br>
There is nowhere in our proposal a statement that VO-DML models MUST be implemented 1-1. In fact the whole effort started from the desire to have an annotation mechanism based on formal data models that can also annotate existing/legacy data sets.<br>
<span></span></blockquote><div><br></div></span><div>sure.. this is the goal, but there is some time between now and the day when data providers can annotate their products according to the not-yet-complete serialization spec, and vodml aware software can pick up those elements to map the provider's value to the desired literal. At this point, it wouldn't matter what the data provider's string was.. the declaration of it as the vo-dml EnumLiteral would make it irrelevant. A validator might have a problem if the string value did not match the literal name though, since typically one instantiates the literal based on the string.<br></div><div><br></div><div>These models we are working (DatasetMetadata, STC2, etc) are working to be vo-dml compliant to facilitate this path, but must also serve the present and near-term, where we have model aware, but not vodml aware software.<br></div><div><br></div><div>So, if I define vo-dml compliant enumeration in the DatasetMetadata model<br></div><div> SpectralBand<br></div><div> + Radio<br></div><div> + XRay<br></div><div><br></div><div>what value would a data provider need to give in order for model aware, but not vo-dml aware software to be able to instantiate the proper literal instance on <br></div><div> myObject.band:SpectralBand[1]<span class="HOEnZb"><font color="#888888"><br><br></font></span></div></div></div></div></blockquote><div class="gmail_quote"><br></div><div class="gmail_quote">Or.. in an annotated world, if we have a table whose column is populated with enumerated values ('band' column in obstap table?). The data product has a string field, that field is annotated with its vo-dml id , the vo-dml aware software can resolve this to see that the values represent instances of the SpectralBand enumeration..<br></div><div class="gmail_quote">what are the field values? Maybe there is a way of annotating each record?<br><br></div><div class="gmail_quote">mark<br><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><br><br><br></div><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div> </div></font></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><br></div></div>