MIVOT: fully qualified attribute names

Thu Feb 16 16:40:32 CET 2023

Dear Markus and DM,

We could continue playing ping-pong, but we reached a point where there is no longer great benefits to expect by doing so. 
Anyway, this helped me to better understand your problem. 
I propose to restart from your case as I understand it and to clarified what is not clear or even wrong.

The case
=======
A annotator (perhaps a DACHS extension) is in charge of building a MIVOT block on the top of a query result.
We assume that this annoter has been provided with things (magic for LM, documentation for MD) telling it 
which model has to  be used and which class of that model(s) can be mapped on that particular VOTable.

The rules
=======
The annotator code is totally model agnostic. 
It only has 2 available ressources:
- a good knowledge of the MIVOT syntax
- all needed VODML files

Let’s see how it can do it.

The Position example
================
It turns out that the dataset has a position (columns ra/dec/err)
To map this quantity, the annoter has to build meas:Position instance in the TEMPLATES.

It can proceed as follow:
open measure.vodml.1.xml
look for the ObjectTYPE with VODML-ID=Position
see that meas:Position extends meas:Measure
look for the ObjectTYPE with VODML-ID=Measure
Measure has an attribute (a composition in fact) with the following setup
NAME=error ,  VODML-ID=Measure.error
type=meas:Error
At this point, the annotator knows that it must build an instance with a role given by the model; 2 options:
taking the NAME (Markus option) —> @dmrole=error
taking the VODML-ID prefixed with the model name (MIVOT) —> @dmrole=meas:Measure.error
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.
restart the same sequence but from the meas:Symmetrical object type.
etc…

Anyone can see that this sequence can be applied on all further  types to be mapped.
If I was a DACHS contributor I would proceed that way.

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. 
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:
with the roles ala MIVOT , the client selecting “.//INSTANCE[@dmrole=meas:Measure.error]: is sure of what it gets
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.

What to do next
============
We can add a section in the spec relating the process above. I admit that would help.

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! 
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.

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. 

Laurent

> On 14 Feb 2023, at 13:04, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear Laurent,
> 
> On Mon, Feb 13, 2023 at 02:26:07PM +0100, Laurent Michel wrote:
>> If your client is very comfortable with the mapped model, it could
>> just replace role==x.y.z with role.endswith(z) But please do not
>> prevent naive clients to get lost because of shortened roles.
> 
> I'd still like to see an example of such a naive client and how we
> would lose it by using plain attribute names -- but in the interest
> of keeping the discussion manageable, I'd suggest we postpone this
> point until we have some agreement the part of the annotation
> workflow.
> 
> 
>>> provide a non-contrived prototype implementation of that), solving it
>>> through the fully qualified attribute names seems extremely unwise,
>>> as it explodes the annotation process.
>> 
>> I worked a lot on the anotation process, and this never bother me.
>> I'm always using components (XML snippets).
> 
> Well, those will not work for software like DaCHS, which is used by
> many people in many different settings, prospectively with models I
> have never heard of.  I just cannot ask people to provide VOTable
> snippets and hope *anything* halfway correct will come of it -- not
> to mention I'd still have to dissect those snippets to annotate TAP
> results.
> 
> No, whatever I do basically has to allow my annotators to look at a
> class description, and that needs to be enough for them to write the
> annotation.
> 
>> I have never seen any situation where using longer roles
>> (qualified) make any trouble.
> 
> Hmha, so the first non-author who tried to implement MIVOT (which
> is, to my knowledge, yours truly) immediately ended up in such a
> situation.  Admittedly, I may miss a lot, and perhaps I'm approaching
> the problem the wrong way, but if so, I'd be grateful for some
> consulting.
> 
> Actually, after re-skimming the spec I am now fairly convinced that
> there is a large hole in the specification: You do not say how to
> form the fully qualified role names that you imply in your examples.
> If you *really* insist on keeping these long role names, you must
> specify a proper algorithm to derive them *from VO-DML* -- and,
> really, provide a reference implementation for the algorithm that you
> define.
> 
> Note that there are plenty of subtleties involved.  For instance, if
> you said:
> 
>  To find the value of the role attribute, walk up the inheritance
>  tree until you find a class that defines the attribute; take the
>  name of that class and concatenate it with the attribute name.
> 
> that may or may not be what you want when classes overwrite base
> classes' attributes.  Consider:
> 
> class LowerBase:
>  myAttr: integer
> 
> class UpperBase(LowerBase):
>  myAttr: positiveInteger
> 
> class Thing(UpperBase):
>  pass
> 
> Now, when I annotate a Thing, will I use role="UpperBase.myAttr" or
> role="LowerBase.attr"?  (I admit that an informated answer would need
> to be based on the reason why your're doing the long names to begin
> with; I could come up with arguments for both, but I think both
> options are, well, a lot "wronger" than the obvious,
> used-in-every-programming-language option of using plain attribute
> names).
> 
> If you answer that question (and as I said, this must be in normative
> language in the MIVOT document), try providing a reference
> implementation of this very central part of the specification:
> 
>  Given a set of VODML files, a class name, and an attribute name,
>  find the value of @role you must use to denote the attribute in
>  that class.
> 
> If you try to implement that, I think you will understand what I mean
> by "explodes the implementation of the annotation".  But if you (or,
> for that matter, anyone else) do (reasonably) implement it in Python
> under a suitable licence and with reasonable test coverage, I'll also
> shut up, because then it's not my implementation effort any more :-)
> 
> And, well, there's always the convenient (and IMHO sane) alternative:
> just use plain attribute names like everyone else.
> 
>> Imagine that your annoter detects that the query result has a sky position.
>> We can assume that:
>> - it is able to build a Mivot representation of a Position object
>> (e.g. with an instance of meas:LonLatPosition)
> 
> No, we cannot -- as I said, DaCHS may be dealing with data models
> I personally have never heard of.  The best I can expect is to have
> VO-DML available.  But if I can do without parsing VO-DML (and for
> all I have seen in my current implementation I reasonably can if we
> use plain attribute names), that's certainly better, because carrying
> around the basic vo-dml files and letting people infuse their own is
> something I'd rather postpone for a while.
> 
> 
>> If by some magic, the annotator discovers that for that particular
> 
> That's not magic -- it's the users who'd be writing:
> 
>  (meas:SymmetricGaussianError) {...}
> 
> because they've found that in a suitable documentation.  What I'm
> asking is that it's non-magic to figure out what to write instead of
> those three dots.
> 
>> it just has to build an instance (I definitely prefer using preset
>> components) of a meas:SymmetricGaussianError and put it at the right place
>> in the Position mapping block.
> 
> As I said, XML snippets won't work for DaCHS for a whole host of
> reasons.  And either way, you still have to define how to come with
> the values of @role.
> 
>> VOMDL gives you the model hierarchy with all related types and
>> roles and MIVOT connects that stuff with data. I do not see any
>> flaw in this process.
> 
> That's the view form 30'000 feet, and I'm not criticising that.  From
> 10'000 feet, I already have a lot to criticise when hovering over the
> DM landscape, but that's not what this is about.
> 
> This is about the @role attribute, where we're on the hard ground of
> implementation and executable code.  And there it would be easy to
> convince me the fully qualified names are well-defined and doable
> without undue effort: write the a function returning the role name
> for a set of VO-DML files, a class name, and an attribute name as
> specified above.
> 
> Or, preferably, just use plain attribute names; I remain solidly
> unconvinced why they shouldn't be good enough for MIVOT when all
> programming languages I've seen can do without them.
> 
>         -- Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230216/e1df5403/attachment-0001.htm>