VEP-007: datalink-core#detached-header

[Markus Demleitner]

Dear François,

On Wed, Sep 15, 2021 at 02:20:08PM +0200, BONNAREL FRANCOIS wrote:
> Le 15/09/2021 à 12:00, Markus Demleitner a écrit :
> > On Wed, Sep 15, 2021 at 11:25:14AM +0200, BONNAREL FRANCOIS wrote:
> > (a) have a clear need for the term, which for datalink/core means
> > (for now): A link that either doesn't fit any of the existing
> > concepts at all or requires splitting an existing concept because the
> > link needs a different treatment (by a machine) from other members of
> > that existing concept.
> > 
> > (b) have a clear and plausible ("digital") *pragmatics* for that
> > concept.  What we're doing here is machine-readable semantics, so to
> > make a term worthwhile, there must be at least an idea (even better:
> > implementation) of what a machine should do with the information that
> > the link belongs to the new concept (rather than an old one).
> 
> This is a point where I have a major disagreement with Markus I'm
> afraid.
> 
> If we want to build a consistent vocabulary we have to think a
> little bit ahead and also around the specific use case we are
> dealing with.

It would certainly be nice to do that, but frankly, all experience
has shown that it's hard to get that right.  The current debate on
#calibration is an example: I'll be the first to admit that the
VEP-006 solution isn't great, but it's the best we can do given
decisions passed when we didn't yet understand the problems as well.

Don't get me started on other things we got wrong because we tried
too early.  And sure, often it's better to jump and miss because
otherwise you never get started.  But...

> We cannot rule out the discussion of a specific term just because
> we don't  have a working example yet if it is obviously related to
> the term which was first proposed.

...can we at least try it here?  You see, I've built VocInVO2
specifically so we can hopefully move without too much speculative
specification, and move quick on top.

If the processes proposed don't lead to less difficult legacy, we can
go back to the old ways, but I'd ask everyone to indulge me for a
year or so.  I'm rather confident we'll have better vocabularies for
it.

> In other words the "pragmatics" should be contextualised.

What would "context" mean here?

I'm so stubborn about pragmatics (i.e.: What computer behaviour do
you want to effect) because in semantics, there's always the
temptation to model the world.

And that's a fool's errand.

Try it, and you'll never get anywhere.  That's happened to far too
many other projects in ontology building, and even with milder and
less actionable concept hierarchies.

I'm really sure that to build useful vocabularies in finite time, we
*have* to check, for every proposed concept, that we know:

* Why do we want a machine to give this information?
* What should the machine do with it in which situation?

The present discussion is a good example for that.

To me, it's evident that a user folding out the #documentation tree
will be happy to find the detached header there.  Which to me clearly
suggests that whereever #detached-header ends up in the concept
hierarchy, it should at least be below #documentation.

Do we need a #metadata between #documentation and #detached-header?
Well, Anne in
CANUExAMTwjVMqBYMm6d55tNjA3Yvg5fKvB_qgieWMbxBsx=-bg at mail.gmail.com I
think wisely said:

> So that sounds like an argument for creating #metadata specifically
> to be the supertype of #header.  If so, what non-#header type might
> there also be under #metadata? I don't object to having the
> occasional platypus in a taxonomy, but no more than are strictly
> necessary...

Exactly: For vocabularies, size matters: The smaller it is, the more
likely it is that people will pick the right concept and that
machines will understand them.

My point about VocInVO2's proposed workflow above here means that
once a second subconcept of this *#metadata comes up, we can just
introduce it, and we'll probably then be able to figure out what
special properties make a piece of #documentation a *#metadata.

Nothing will break just because this extra *#metadata will show up
between #documentation and #detached-header: Users will still fold it
out when they look for documentation, and machines will still find
the #detached-header they're looking for.  It's just the other
machines that need the (yet unclear) pragmatics for #metadata will
then pick up #detached-header and all its future siblings.  

And all that without committing to any specific definition or
position of #metadata at this point; that's good because as I said
the odds of us regretting such a commitment later are high.

So... Deal on VEP-007?

              -- Markus