<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Dear Markus and DM,</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">We could continue playing ping-pong, but we reached a point where there is no longer great benefits to expect by doing so. </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Anyway, this helped me to better understand your problem. </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">I propose to restart from your case as I understand it and to clarified what is not clear or even wrong.<br class="">
<br class="">
The case</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">=======</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">A annotator (perhaps a DACHS extension) is in charge of building a MIVOT block on the top of a query result.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">We assume that this annoter has been provided with things (magic for LM, documentation for MD) telling it </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">which model has to be used and which class of that model(s) can be mapped on that particular VOTable.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">The rules</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">=======</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">The annotator code is totally model agnostic. </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">It only has 2 available ressources:</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">- a good knowledge of the MIVOT syntax</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">- all needed VODML files</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Let’s see how it can do it.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">The Position example</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">================</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">It turns out that the dataset has a position (columns ra/dec/err)</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">To map this quantity, the annoter has to build meas:Position instance in the TEMPLATES.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">It can proceed as follow:</div>
<ol class="">
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">open measure.vodml.1.xml</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">look for the ObjectTYPE with VODML-ID=Position</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">see that meas:Position extends meas:Measure</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">look for the ObjectTYPE with VODML-ID=Measure</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Measure has an attribute (a composition in fact) with the following setup</li>
<ol class="">
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class=""> NAME=error , VODML-ID=Measure.error</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">type=meas:Error</li>
</ol>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">At this point, the annotator knows that it must build an instance with a role given by the model; 2 options:</li>
<ol class="">
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">taking the NAME (Markus option) —> @dmrole=error</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">taking the VODML-ID prefixed with the model name (MIVOT) —> @dmrole=meas:Measure.error</li>
</ol>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Going further, the annoter sees that the ObjectType meas:Error is abstract: It cannot be instantiated as such; the annotater has to choose one specific subclass. As we just have one error column, we can guess that the ObjectType=meas:Symmetrical is a good candidate.</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">restart the same sequence but from the meas:Symmetrical object type.</li>
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">etc…</li>
</ol><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class=""><br class="">
Anyone can see that this sequence can be applied on all further types to be mapped.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">If I was a DACHS contributor I would proceed that way.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">We can see that the point of contention with Markus is limited to a small sequence: 5.1: using VODML/NAME or VODML/VOMDL-ID to build MIVOT roles. </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">I agree that both options could work but we preferred working with VODML/VOMDL-ID prefixed with the model name because this allows clients to pick elements by their roles without having to first isolate the enclosing instance:</div>
<ul class="">
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class=""><span style="font-stretch: normal; font-size: 12px; line-height: normal;" class=""></span>with the roles ala MIVOT , the client selecting “.//INSTANCE[@dmrole=meas:Measure.error]: is sure of what it gets</li></ul>
<ul class="">
<li style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class=""><span style="font-stretch: normal; font-size: 12px; line-height: normal;" class=""></span>with the roles ala Markus , the client selecting “.//INSTANCE[@dmrole=error]: will return anything playing any role named error, either from the meas:Measure class or any other. This is the price for using non-unique identifiers.</li>
</ul><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">What to do next</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">============</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">We can add a section in the spec relating the process above. I admit that would help.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">I will be less open-minded about the requirement of assigning the RFC ending with the release of software pieces operating all steps of the model mapping process with a good test coverage furthermore; very new in the IVOA landscape! </div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">The purpose of MIVOT is to map data on models serialised in VODML. All the implementations we provide show that this requirement is achieved even if we could dream about tools making the job easier.</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue"; min-height: 15px;" class=""><br class=""></div><span class="">Actually I’ve code generating MIVOT instances from VODML (github:ivoa/modelinstanceinvot-code branch:feature/instance-generator), i’m using it to build the snippets I was talking about i my previous mail. This code is not ready to be published, I would be happy to do it but I’ve just no time to complete the job; but anyway, this must not block the REC. <br class=""></span><span class=""><br class=""></span><span class=""><br class=""></span><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; font-family: "Helvetica Neue";" class="">Laurent</div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 14 Feb 2023, at 13:04, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear Laurent,<br class=""><br class="">On Mon, Feb 13, 2023 at 02:26:07PM +0100, Laurent Michel wrote:<br class=""><blockquote type="cite" class="">If your client is very comfortable with the mapped model, it could<br class="">just replace role==x.y.z with role.endswith(z) But please do not<br class="">prevent naive clients to get lost because of shortened roles.<br class=""></blockquote><br class="">I'd still like to see an example of such a naive client and how we<br class="">would lose it by using plain attribute names -- but in the interest<br class="">of keeping the discussion manageable, I'd suggest we postpone this<br class="">point until we have some agreement the part of the annotation<br class="">workflow.<br class=""><br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">provide a non-contrived prototype implementation of that), solving it<br class="">through the fully qualified attribute names seems extremely unwise,<br class="">as it explodes the annotation process.<br class=""></blockquote><br class="">I worked a lot on the anotation process, and this never bother me.<br class="">I'm always using components (XML snippets).<br class=""></blockquote><br class="">Well, those will not work for software like DaCHS, which is used by<br class="">many people in many different settings, prospectively with models I<br class="">have never heard of. I just cannot ask people to provide VOTable<br class="">snippets and hope *anything* halfway correct will come of it -- not<br class="">to mention I'd still have to dissect those snippets to annotate TAP<br class="">results.<br class=""><br class="">No, whatever I do basically has to allow my annotators to look at a<br class="">class description, and that needs to be enough for them to write the<br class="">annotation.<br class=""><br class=""><blockquote type="cite" class="">I have never seen any situation where using longer roles<br class="">(qualified) make any trouble.<br class=""></blockquote><br class="">Hmha, so the first non-author who tried to implement MIVOT (which<br class="">is, to my knowledge, yours truly) immediately ended up in such a<br class="">situation. Admittedly, I may miss a lot, and perhaps I'm approaching<br class="">the problem the wrong way, but if so, I'd be grateful for some<br class="">consulting.<br class=""><br class="">Actually, after re-skimming the spec I am now fairly convinced that<br class="">there is a large hole in the specification: You do not say how to<br class="">form the fully qualified role names that you imply in your examples.<br class="">If you *really* insist on keeping these long role names, you must<br class="">specify a proper algorithm to derive them *from VO-DML* -- and,<br class="">really, provide a reference implementation for the algorithm that you<br class="">define.<br class=""><br class="">Note that there are plenty of subtleties involved. For instance, if<br class="">you said:<br class=""><br class=""> To find the value of the role attribute, walk up the inheritance<br class=""> tree until you find a class that defines the attribute; take the<br class=""> name of that class and concatenate it with the attribute name.<br class=""><br class="">that may or may not be what you want when classes overwrite base<br class="">classes' attributes. Consider:<br class=""><br class="">class LowerBase:<br class=""> myAttr: integer<br class=""><br class="">class UpperBase(LowerBase):<br class=""> myAttr: positiveInteger<br class=""><br class="">class Thing(UpperBase):<br class=""> pass<br class=""><br class="">Now, when I annotate a Thing, will I use role="UpperBase.myAttr" or<br class="">role="LowerBase.attr"? (I admit that an informated answer would need<br class="">to be based on the reason why your're doing the long names to begin<br class="">with; I could come up with arguments for both, but I think both<br class="">options are, well, a lot "wronger" than the obvious,<br class="">used-in-every-programming-language option of using plain attribute<br class="">names).<br class=""><br class="">If you answer that question (and as I said, this must be in normative<br class="">language in the MIVOT document), try providing a reference<br class="">implementation of this very central part of the specification:<br class=""><br class=""> Given a set of VODML files, a class name, and an attribute name,<br class=""> find the value of @role you must use to denote the attribute in<br class=""> that class.<br class=""><br class="">If you try to implement that, I think you will understand what I mean<br class="">by "explodes the implementation of the annotation". But if you (or,<br class="">for that matter, anyone else) do (reasonably) implement it in Python<br class="">under a suitable licence and with reasonable test coverage, I'll also<br class="">shut up, because then it's not my implementation effort any more :-)<br class=""><br class="">And, well, there's always the convenient (and IMHO sane) alternative:<br class="">just use plain attribute names like everyone else.<br class=""><br class=""><blockquote type="cite" class="">Imagine that your annoter detects that the query result has a sky position.<br class="">We can assume that:<br class="">- it is able to build a Mivot representation of a Position object<br class="">(e.g. with an instance of meas:LonLatPosition)<br class=""></blockquote><br class="">No, we cannot -- as I said, DaCHS may be dealing with data models<br class="">I personally have never heard of. The best I can expect is to have<br class="">VO-DML available. But if I can do without parsing VO-DML (and for<br class="">all I have seen in my current implementation I reasonably can if we<br class="">use plain attribute names), that's certainly better, because carrying<br class="">around the basic vo-dml files and letting people infuse their own is<br class="">something I'd rather postpone for a while.<br class=""><br class=""><br class=""><blockquote type="cite" class="">If by some magic, the annotator discovers that for that particular<br class=""></blockquote><br class="">That's not magic -- it's the users who'd be writing:<br class=""><br class=""> (meas:SymmetricGaussianError) {...}<br class=""><br class="">because they've found that in a suitable documentation. What I'm<br class="">asking is that it's non-magic to figure out what to write instead of<br class="">those three dots.<br class=""><br class=""><blockquote type="cite" class="">it just has to build an instance (I definitely prefer using preset<br class="">components) of a meas:SymmetricGaussianError and put it at the right place<br class="">in the Position mapping block.<br class=""></blockquote><br class="">As I said, XML snippets won't work for DaCHS for a whole host of<br class="">reasons. And either way, you still have to define how to come with<br class="">the values of @role.<br class=""><br class=""><blockquote type="cite" class="">VOMDL gives you the model hierarchy with all related types and<br class="">roles and MIVOT connects that stuff with data. I do not see any<br class="">flaw in this process.<br class=""></blockquote><br class="">That's the view form 30'000 feet, and I'm not criticising that. From<br class="">10'000 feet, I already have a lot to criticise when hovering over the<br class="">DM landscape, but that's not what this is about.<br class=""><br class="">This is about the @role attribute, where we're on the hard ground of<br class="">implementation and executable code. And there it would be easy to<br class="">convince me the fully qualified names are well-defined and doable<br class="">without undue effort: write the a function returning the role name<br class="">for a set of VO-DML files, a class name, and an attribute name as<br class="">specified above.<br class=""><br class="">Or, preferably, just use plain attribute names; I remain solidly<br class="">unconvinced why they shouldn't be good enough for MIVOT when all<br class="">programming languages I've seen can do without them.<br class=""><br class=""> -- Markus<br class=""></div></div></blockquote></div><br class=""></body></html>