MIVOT: fully qualified attribute names

[Markus Demleitner]

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