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

Hi Simon,

On 08/05/2011 08:49 AM, Simon Miles wrote:
> Hi Luc,
>
> OK, the distinction makes sense, but leads to some thoughts.
>
> If "role name" is used to identify a parameter/input/port name, then
> "role type" may be interpreted as the data type of that
> parameter/input. We will have to be clear that it is about the
> relation of the entity to the process, not the type of entity required
> by the process.
>
>    

Yes indeed

> I wonder how people will use "role name" in practice - it is clear for
> web services or method calls, but not so obvious for document editing,
> surgery or publishing. I have not thought it through deeply, but might
> it be that "role name" and the constraint of its uniqueness only makes
> sense in specialised contexts? Not every process is accurately
> replayable. As an alternative, I could imagine the model only talking
> about role in the sense of role type, and then having a "workflow
> profile" to the model which requires role types to match parameter
> names and be unique per execution.
>    

Even for edits, roles can be useful. Stephen C "replays" edits
by applying a patch to a document.

I think the use case for replay/validation/checking is strong enough,
that we should not drop the idea of role name.  (We can change the
terminology if appropriate!)


> My view on role type itself is that, as the value of the role type is
> one place where domain-specific information can be put when using the
> language, it would be good to make this explicit in the document (see
> issue [1]). I guess this means it needs to be included in the language
> somehow, e.g. as an additional parameter of the used/generated/etc
> relations.
>    

Even for role names, we say that their interpretation is outside the scope
of this document, and left to process execution ontology designers.
> With regards to formalisation, a role type on a used edge says "how,
> specifically, the process execution used the bob" (and equivalently
> for other edges). I think this matches exactly the meaning of
> rdfs:subClassOf / rdfs:subPropertyOf, i.e. to specify a role type you
> are simply specialising the Uses class / property. This implies that
> we do not need "role type" to be explicitly part of the formal model
> as RDFS already captures the concept. I think this is the approach
> taken by OPMV.
>    

Note that the model is supposed to be independent of RDFS.

However, I agree with you that role types may be left out of the model.
Given a mapping role-name x process execution -> role-type, we should
be able to derive role types.

On the other hand, it's not unrealistic to write a query such as "give
me all contributors to this document", and role types may become useful.

> I note that roles only apply to use, generation and control relations.
> For role type at least, I'm not sure why derived relations would be
> excluded. If we say "X is a prior version of the same thing as Y" or
> "X was the template for Y", then we are expressing specifically how X
> was involved in Y's derivation. This doesn't seem different in kind to
> role types on other edges.
>
>    

Roles apply to use/gen/control, because they are "about the relation of 
the entity to the process execution"
as you say. Roles for derivation seem to make less sense.

Luc
> [1] http://www.w3.org/2011/prov/track/issues/65
>
> Thanks,
> Simon
>
> On 4 August 2011 21:25, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  wrote:
>    
>> Hi Simon,
>>
>> I am in agreement.  Paolo and I discussed the idea
>> of distinguishing role type from role name (like parameter name and
>> parameter type).
>> Uniqueness property applies to role name, not to role type.
>>
>> One of the reasons for the uniqueness property is the ability to replay
>> executions.
>> You need to be able to know which value to  "plug" to which input/port.
>>
>> Currently, all the constraints and definitions pertaining to roles in the
>> specification are about role names.
>>
>> One might argue that role types could be found in the process execution
>> specific
>> ontology that declares role names.  Alternatively, we can make them
>> explicit in PIL.
>>
>> Views on this?
>>
>> Regards,
>> Luc
>>
>>
>> On 04/08/11 16:00, Simon Miles wrote:
>>      
>>> Hi Luc,
>>>
>>> Reading Graham's comment I'm also unclear what the purpose of this
>>> requirement is.
>>>
>>> I have a suspicion that the lack of clarity could from the conflation
>>> of two issues:
>>>
>>> 1. the desire to express the role played by bobs in executions
>>> 2. the desire to have uniquely named parameters for executions, so
>>> that bobs used can be uniquely referenced
>>>
>>> Maybe I'm wrong and this is not the problem at all. But if it is, then
>>> I suggest that we untangle the two issues. It is counter-intuitive to
>>> me, and I strongly suspect it would be to users of the standard, to
>>> disallow us from saying that two bobs played the same role in an
>>> execution. If I want to say that process P chose numbers randomly from
>>> two lists L1 and L2, then I would want to assert that L1 and L2 played
>>> the same role in P. There may well always be a difference in each
>>> bob's role if you look in fine detail at P, but I might not know that
>>> difference nor want to model it if I did.
>>>
>>> thanks,
>>> Simon
>>>
>>> On 4 August 2011 09:41, Graham Klyne<GK@ninebynine.org>    wrote:
>>>
>>>        
>>>> Luc Moreau wrote:
>>>>
>>>>          
>>>>> Hi Graham,
>>>>>
>>>>> On 07/29/2011 10:13 AM, Provenance Working Group Issue Tracker wrote:
>>>>>
>>>>>            
>>>>>> [[
>>>>>> A reference to a given BOB may appear in multiple use assertions that
>>>>>> refer to a given process execution, but each of those use assertions
>>>>>> must have a distinct role.
>>>>>> ]]
>>>>>> In light of the above, this seems nonsensical to me.
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>> I am trying to understand what the issue is.
>>>>>
>>>>> We're trying to say:
>>>>>
>>>>> For any b, bob(b,[...])
>>>>> For any pe, processExecution(pe)
>>>>>
>>>>>       for any two assertions use(pe,b,r1,t1) and use(pe,b,r2,t2), then
>>>>>        r1<>    r2
>>>>>
>>>>> Is there a problem with this?
>>>>>
>>>>>            
>>>> I now understand what you are trying to express.
>>>>
>>>> Is there a problem?  I don't know, because I don't properly understand what
>>>> purpose "role" is serving here.
>>>>
>>>> Does anything actually break if this requirement is dropped?  I.e. if it's OK to
>>>> say:
>>>>
>>>>     use(pe,b,r1,t1)
>>>> AND
>>>>     use(pe,b,r1,t2)
>>>>
>>>> #g
>>>>
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>>      
>
>
>    

-- 
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 Friday, 5 August 2011 08:41:58 UTC