Re: PROV-ISSUE-64 (definition-use): definition of use [Conceptual Model]

Hi Simon,

The latest version of the document addresses your comments.
The circumstances when qualifiers are required to be unique (for 
annotation, for expressing pe-linked-derivations)
have been made explicit.

We believe this solves this issue, which has now been closed, pending 
review.
Feel free to re-open if you feel the the answer is inadequate.

Cheers,
Luc

On 09/09/2011 15:21, Luc Moreau wrote:
> Hi Simon,
>
> On 09/09/2011 02:59 PM, Simon Miles wrote:
>> Hi Luc,
>>
>>> I may not have been clear. I think that the requirement of roles to
>>> define derivation is a stronger justification than data structure
>>> uniformity.
>> OK. I think this raises three sub-issues: (i) that is not the
>> justification for mandatory roles currently given in the text; (ii)
> Yes, text would need to be change
>
>> the use of roles in derivation assertions sounds like role types
>> rather than role names, i.e. there appears to be no necessity for the
> no, in derivation, it's definitely role names you need, and unicity is 
> required.
>> roles mentioned to be unique; (iii) roles are optional in derivation
>> assertions, so it seems odd that this be a rationale for them being
>> mandatory in other assertions.
> optional to assert, but they do exist, as per inference.
> exactly like in use, roles are optional to assert
>>> You still seem not to take into account the optional nature of 
>>> asserting
>>> roles. Maybe, it's a question of presentation in the document.  But
>>> ultimately, we are
>>> telling people you are free not to express roles. Under the bonnet, 
>>> there
>>> will be an unspecified role. I don't understand what the problem is 
>>> with
>>> this approach, where a default value is provided.
>> My problem with this approach is that I am unclear what "under the
>> bonnet" really means. I also agree with Graham's point that, whatever
>> it is, I don't know whether we should be standardising it.
>>
> forget this sentence, sorry.
> I meant to say that not asserting a role is defined as asserting a role
> in the set "unspecified".
>> Regardless of any of the above, I still think the opaqueness of "Roles
>> are mandatory since they allow for uniform data structures" is the
>> most pressing issue. I think it answers a necessary question (why
>> mandatory?) but in an unhelpful way.
> We would drop this statement, since derivation is a better justification.
>
> Luc
>> Thanks,
>> Simon
>>
>>
>> On 5 September 2011 10:20, Graham Klyne<GK@ninebynine.org>  wrote:
>>> On 05/09/2011 08:17, Luc Moreau wrote:
>>>> You still seem not to take into account the optional nature of 
>>>> asserting
>>>> roles. Maybe, it's a question of presentation in the document. But 
>>>> ultimately,
>>>> we are
>>>> telling people you are free not to express roles. Under the bonnet, 
>>>> there
>>>> will be an unspecified role. I don't understand what the problem is 
>>>> with
>>>> this approach, where a default value is provided.
>>> I think there may be a mismatch here between designing a *system* 
>>> and defining a
>>> *standard* - the point of a standard is to specify what is visibly 
>>> exchanged
>>> between systems.
>>>
>>> In particular, if the role is optional, then it is unhelpful to say 
>>> "Under the
>>> bonnet, there will be an unspecified role", because what exists 
>>> "under the
>>> bonnet" is exactly an implementation choice.  If I write a system 
>>> that uses
>>> provenance information in a limited fashion that never involves 
>>> roles (which is
>>> OK, as you have said they are optional), then there is no 
>>> unspecified role under
>>> the bonnet.
>>>
>>> Thus, if the presence of a role is optional in the exchange of 
>>> provenance
>>> information, then I think it should be optional in the model, as it 
>>> is the
>>> exchangeable provenance information that we need to model here.  
>>> Maybe, as you
>>> say, this is simply a matter of choosing appropriate phrasing.
>>>
>>> #g
>>> -- 
>>>
>>>
>>
>>
>

Received on Friday, 23 September 2011 10:58:56 UTC