Re: PROV-ISSUE-384 (prov-role-in-attribution): prov:role in attribution or not? [prov-dm]

Hi Tim,

A definition can be worked out for your suggestion.

/A role is the function of an entity, activity, or agent in the context 
of a relation.
The subject and object of relations may be given roles.
/
e.g.

wasAttributedTo(doc, bob, [ prov:oRole="editor", prov:sRole="bestPaper" ] ])

wasInformedBy(a2,a1,  [ prov:oRole="publisher", prov:sRole="subscriber" ]

+: general relations and simple definition
-: obviously, we end up with two attributes/object properties.

Question: what about the other linked concepts in n-ary relations: do 
they have roles?
e.g. plan in an association, starter in a start, ender in an end, 
activity in a delegation/derivation?

Luc

On 31/05/12 16:40, Timothy Lebo wrote:
> FWIW, what about making prov:oHadRole and prov:sHadRole to distinguish between talking about the subject or object of the Involvement?
>
>
> -Tim
>
> On May 30, 2012, at 10:16 AM, Timothy Lebo wrote:
>
>    
>> Luc and Graham,
>>
>>
>> On May 30, 2012, at 4:52 AM, Graham Klyne wrote:
>>
>>      
>>> On 29/05/2012 22:37, Luc Moreau wrote:
>>>        
>>>> Hi Tim, Stephan, Graham,
>>>>
>>>> So, you are all defending role, as an alternative way of specializing relations.
>>>> OK.
>>>>
>>>> So, we now need to agree:
>>>> 1. on the domain of prov:hadRole
>>>>          
>>> By domain here, I assume you mean the relations for which it may be an attribute.  The easy answer would be "all of them".
>>>        
>> "all of them" would be much easier to wrestle.
>>
>>      
>>>        
>>>> 2. on a definition of role that works with this domain
>>>>
>>>> Currently: we have:
>>>> /A role is the function of an entity with respect to an activity, in the context
>>>> of a usage, generation, association, start, and end./
>>>>          
>>> Yes, the wordsmithing could be tricky if it is to preserve the intuitions.
>>>
>>> Technically, I think it's just introducing a subrelation of the relation to which it is applied.  (So if a binary relation is a set of pairs, its a subset of those pairs, similarly for N-way relations).
>>>        
>>
>> I don't follow the sub relation point. Is this following from the previous points (that I also don't follow):
>>
>>      
>>>>> This brings up a question: /what is the difference between prov:role and
>>>>> prov:type?/
>>>>>            
>>>> I think it's similar to the difference (in RDF) between subClass and
>>>> subProperty, or class and property).
>>>>          
>>
>>
>>
>>
>>      
>>>        
>>>> We seem to be in agreement that we want roles also for
>>>> - invalidation
>>>>          
>>> Consistency and uniformity would suggest so, though in this case I'm not sure what the intuition would be.
>>>
>>>        
>>>> The current definition works for: usage, generation, start, end, invalidation.
>>>>
>>>> This definition:
>>>>
>>>> /A role is the function of an entity or an *agent* with respect to an activity
>>>>
>>>> /would also work for association.
>>>>
>>>> It's not clear this definition would work for:
>>>> - delegation
>>>> actedOnBehalfOf(ag2,ag1,a)
>>>> a role for which agent ? responsible? delegate?
>>>>          
>>> I think it's not so far off - it would presumably be some subset of the roles that ag1 has with respect to a that are being delegated?
>>>
>>>        
>>>> - attribution
>>>> no activity here.
>>>>          
>>> I think the notion of role works here: e.g. you etal are attributed as editors of PROV-DM, several more of us are attributed as authors.
>>>
>>>        
>>>> - communication?
>>>> wasInformedBy(a2,a1) here no entity
>>>>          
>>> Again, I think it could apply here.  As a student, my writing of an essay would be informed by my learning of material;  as a miscreant, my writing of a penance piece (remember "lines"?) could be informed by my misdeed.  I think "student" and "miscreant" stand here as roles.
>>>
>>>        
>>>> - derivation?
>>>> wasDerivedFrom(e2,e1,a,g,u)
>>>> a role for which entity?
>>>>          
>>> Neither, or both.  The role designates a relationship between the entities, not about one of them in isolation.
>>>        
>> Yes, but the role name changes depending on which side you choose to describe. "pupil" becomes "teacher".
>>
>> I think the resource cited by the prov:involvee (i.e, rdf:object) should be the one whose role we should be describing with hadRole.
>>
>>
>>
>>      
>>>        
>>>> So, I would propose:
>>>> /A role is the function of an entity or an *agent* with respect to an activity,/
>>>> /in the context of a usage, generation, association, start, end, and invalidation.
>>>> /For all these relations, an activity is subject or object.
>>>>          
>>> My inclination would be to start from a simple technical definition that can apply to all relationships, and then to illustrate it with a series of examples, rather than to try and capture all the (sometimes diverse) intuitions in the definition.
>>>        
>>
>> +1
>>
>> Can we relax the domain of prov:hadRole to simply prov:Involvement?
>>
>> Thanks,
>> Tim
>>
>>
>>
>>
>>      
>>> #g
>>> --
>>>
>>>        
>>>> On 29/05/12 18:29, Graham Klyne wrote:
>>>>          
>>>>> On 29/05/2012 17:02, Luc Moreau wrote:
>>>>>            
>>>>>> Hi Tim and Paul,
>>>>>>
>>>>>> We should also add it to Invalidation (because there is an activity).
>>>>>>
>>>>>> So, it looks like, if we follow Tim's suggestion, roles would be
>>>>>> allowed on all qualified relations, except Derivation and Communication.
>>>>>> Why not these now?
>>>>>>
>>>>>> This brings up a question: /what is the difference between prov:role and
>>>>>> prov:type?/
>>>>>>              
>>>>> I think it's similar to the difference (in RDF) between subClass and
>>>>> subProperty, or class and property).
>>>>>
>>>>> (In the RDF formal semantics, they actually look very similar - properties
>>>>> have 2-part relational extensions, and types have single-value extensions.
>>>>> Several years ago, Peter Patel-Schneider proposed an alternative semantic
>>>>> model over the underlying RDF/XML structure that unified these.)
>>>>>
>>>>> But I think to try and unify them in PROV-DM would cause more head-scratching
>>>>> than it would save - I think the notions of type and role carry some useful
>>>>> intuition which may be good to keep. (Noting that roles in PROV-DM may be
>>>>> 2-way and sometimes multi-way relations.)
>>>>>
>>>>> #g
>>>>> --
>>>>>
>>>>>
>>>>>            
>>>>>> These are examples of prov:role in prov-dm.
>>>>>>
>>>>>> wasAssociatedWith(ex:edit1, ex:Paolo, -, [ prov:role="editor" ])
>>>>>> wasAssociatedWith(ex:edit1, ex:Simon, -, [ prov:role="contributor" ])
>>>>>> wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [ prov:role="editor" ])
>>>>>> wasAttributedTo(tr:WD-prov-dm-20111215, ex:Simon, [ prov:role="contributor" ])
>>>>>> wasAssociatedWith(ex:a, ex:ag1, -, [ prov:role="loggedInUser",
>>>>>> ex:how="webapp" ])
>>>>>> wasAssociatedWith(ex:a, ex:ag2, ex:wf, [ prov:role="designer",
>>>>>> ex:context="project1" ])
>>>>>> wasAssociatedWith(a, ag1, [ prov:role="loggedInUser" ])
>>>>>> wasAssociatedWith(a, ag, [ prov:role="operator" ])
>>>>>> used(ex:div01, ex:cell, [ prov:role="divisor" ])
>>>>>>
>>>>>> They could have been written as (Sorry for the sometime poor choice of name, but
>>>>>> you should get
>>>>>> the idea)
>>>>>>
>>>>>> wasAssociatedWith(ex:edit1, ex:Paolo, -, [
>>>>>> prov:type="WasAssociatedWithAsEditor" ])
>>>>>> wasAssociatedWith(ex:edit1, ex:Simon, -, [
>>>>>> prov:type="WasAssociatedWithAsContributor" ])
>>>>>> wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [
>>>>>> prov:type="WasAttributedToEditorEditor" ])
>>>>>> wasAttributedTo(tr:WD-prov-dm-20111215, ex:Simon, [
>>>>>> prov:type="WasAttributedToEditorContributor" ])
>>>>>> wasAssociatedWith(ex:a, ex:ag1, -, [
>>>>>> prov:type="WasAssociatedWithAsLoggedInUser", ex:how="webapp" ])
>>>>>> wasAssociatedWith(ex:a, ex:ag2, ex:wf, [
>>>>>> prov:type="WasAssociatedWithAsDesigner", ex:context="project1" ])
>>>>>> wasAssociatedWith(a, ag1, [ prov:type="WasAssociatedWithAsLoggedInUser" ])
>>>>>> wasAssociatedWith(a, ag, [ prov:type="WasAssociatedWithAsOperator" ])
>>>>>> used(ex:div01, ex:cell, [ prov:type="UsedAsDivisor" ])
>>>>>>
>>>>>> It feels that all role information can be expressed as type.
>>>>>>
>>>>>> So,
>>>>>> 1. when should we encode this kind of information with prov:type and when should
>>>>>> do with prov:role.
>>>>>> 2. what distinguishes prov:role from prov:type?
>>>>>> 3. what's the definition of prov:role
>>>>>> 4. should we drop prov:role, and just use prov:type?
>>>>>>
>>>>>> Luc
>>>>>>
>>>>>>
>>>>>> On 05/29/2012 02:54 PM, Timothy Lebo wrote:
>>>>>>              
>>>>>>> Currently, only Association (or Start, End, Usage, Generation) may use hadRole.
>>>>>>>
>>>>>>> Looking back, I see that one of the prov-o examples violates this:
>>>>>>> https://dvcs.w3.org/hg/prov/raw-file/default/ontology/Overview.html#qualifiedResponsibility
>>>>>>>
>>>>>>>
>>>>>>> by putting a role on a Delegation.
>>>>>>>
>>>>>>>
>>>>>>> Association, Attribution, and Delegation are the three ways to ascribe
>>>>>>> responsibility.
>>>>>>>
>>>>>>> May we relax hadRole and permit its use on Attribution and Delegation?
>>>>>>>
>>>>>>> (so, for this issue, +1; and a new issue to add it to Delegation, too :)
>>>>>>>
>>>>>>> -Tim
>>>>>>>
>>>>>>>
>>>>>>> On May 26, 2012, at 5:48 AM, Paul Groth wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> Hi Luc,
>>>>>>>>
>>>>>>>> It's unclear to me if attribution has an underlying activity. If we
>>>>>>>> agree on that then the definition falls out and we should could use
>>>>>>>> prov:role with respect to activity.
>>>>>>>>
>>>>>>>> I guess the argument could be that there is always an activity that
>>>>>>>> links the agent to an entity in the end. Is that what we say in the
>>>>>>>> end?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> On Thu, May 24, 2012 at 11:14 PM, Provenance Working Group Issue
>>>>>>>> Tracker<sysbot+tracker@w3.org>  wrote:
>>>>>>>>                  
>>>>>>>>> PROV-ISSUE-384 (prov-role-in-attribution): prov:role in attribution or not?
>>>>>>>>> [prov-dm]
>>>>>>>>>
>>>>>>>>> http://www.w3.org/2011/prov/track/issues/384
>>>>>>>>>
>>>>>>>>> Raised by: Luc Moreau
>>>>>>>>> On product: prov-dm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In the example,
>>>>>>>>> http://www.w3.org/TR/prov-dm/#anexample-attribution,
>>>>>>>>> we write:
>>>>>>>>> wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [prov:role="editor"])
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But in
>>>>>>>>> http://www.w3.org/TR/prov-dm/#term-attribute-role
>>>>>>>>> we say:
>>>>>>>>> The attribute prov:role denotes the function of an entity with respect to an
>>>>>>>>> activity, in the context of a usage, generation, association, start, and end.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So,
>>>>>>>>> 1. Do we want to accept prov:role in Attribution?
>>>>>>>>> (or, it's not a prov:role but prov:type we should use?)
>>>>>>>>>
>>>>>>>>> 2. If yes, does it mean the definition of prov:role needs to be changed?
>>>>>>>>> where is the activity?
>>>>>>>>>
>>>>>>>>> 3. Should we have an optional activity in Attribution?
>>>>>>>>>
>>>>>>>>> Luc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Dr. Paul Groth (p.t.groth@vu.nl)
>>>>>>>> http://www.few.vu.nl/~pgroth/
>>>>>>>> Assistant Professor
>>>>>>>> Knowledge Representation&  Reasoning Group
>>>>>>>> Artificial Intelligence Section
>>>>>>>> Department of Computer Science
>>>>>>>> VU University Amsterdam
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>                
>>>>>>              
>>>>>            
>>>>          
>>>
>>>        
>>
>>
>>      
>
>    

Received on Thursday, 31 May 2012 20:55:12 UTC