Provenance team reply on the Agent roles

[Ole Streicher]

Hi Laurent, Markus,

On 17.12.19 11:30, Laurent MICHEL wrote:
>> Enabling interoperable use (which is "from different sources") is not
>> the only reason for wishing a clear and well-defined vocabulary --
>> with the current proposed set of terms, annotators will also have a
>> hard time picking terms, as the meanings severely overlap, and the
>> definitions are insufficient to disambiguate them.
>>
>> This will become painful as soon as some software client actually
>> wants to do interoperably interpret provenance information.  If you
>> feel that's a flaw you want to live with, that's fine.  I'd still
>> prefer it if things that you're not willing to define interoperably
>> weren't part of the standard in the first place -- it's always easier
>> to add something to a standard than to take something away.
>>
>> Be that as it may: I'd hope interoperable interpretation of
>> provenance can live without agent-role, and so, again, semantics
>> won't block provenance.
> To me this a design choice. Once you have said the a role *SHOULD* use a
> given vocabulary, you have broken the interoperability because whatever
> the proposed vocabulary is, the annotator could use its own words for
> this role and especially if he/she is not happy what is proposed by the
> standard. Then, the role of the agent must rather be understood as a
> descriptive thing.
> Taking this into account and in my opinion it is more important to
> suggest words making sense for our annotator than focusing on the use a
> limited but orthogonal vocabulary.

There are a couple of problems here, where at least I don't know how to
solve them all:

First, it is very difficult to have complete list of agent roles -- one
may see the need a specific role for the own use case. We could either
make role names that are not defined in the standard (or in a
vocabulary) illegal, or allow the user to extend the list if needed. We
(Provenance authors) have chosen the later alternative.

Second, the (RFC2119) wording here had some evolution -- in earlier
versions of the draft we said "we suggest to use the list", which leaves
all the freedom to the implementation (RFC 2119 "MAY"). This now was
strengthened to "SHOULD, if possible", which translates into

"[…] there may exist valid reasons in particular circumstances to ignore
a particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

The implication of an ignorance here is that it may destroy
interoperability, and I am not sure if "is not happy" is a "valid reason".

However, I could imagine that "MUST" would be the right term here: "If
one of the terms fits, it MUST be used". That would then however require
that we provide a much clearer definition of the terms we use, so that
it is not a subjective decision. And the definitions must be disjunct in
this case, since otherwise the rule would be ambiguous.

The current solution has another disadvantage: while one can introduce
new agent roles in an implementation, there is no way to transport their
semantics. Different from usage/generation roles, we don't have a
description attached.

IMO it would be worth to develop the a restricted list of roles (so,
revise our design decision about extensibility) which can grow as a IVOA
repository, and to start with a list that solves the current
implementations. However, I am in a minority, and would have the danger
to get killed when I would propose this seriously.

And, IMO the main use of provenance is reproducibility, and this implies
that a result is independent of the specific agents and their roles. So,
at the end I am not sure how important the agent roles are in reality.

Best regards

Ole