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

Hi Simon and Graham,

We are now formally closing this issue.
It is now superseded, since with the introduction of identifiers for 
usage/generation,
we no longer need this requirement of qualifier uniqueness.

Regards,
Luc

On 09/23/2011 11:57 AM, Luc Moreau wrote:
>
> 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
>>>> -- 
>>>>
>>>>
>>>
>>>
>>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Wednesday, 30 November 2011 11:47:28 UTC