W3C home > Mailing lists > Public > public-prov-wg@w3.org > May 2012

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

From: Timothy Lebo <lebot@rpi.edu>
Date: Thu, 31 May 2012 17:03:15 -0400
Cc: public-prov-wg@w3.org
Message-Id: <DA574806-38FA-456B-A1E8-7630B61E2421@rpi.edu>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Luc,

On May 31, 2012, at 4:54 PM, Luc Moreau wrote:

> 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.

Nice. 
I'd try to scope "relation" down to "involvement", but that's b/c I've been trying to rename relation to involvement this entire time :-)
Relation probably makes more sense from a new user's perspective.

> 
> 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

+1. General, simple. Avoids the http://en.wikipedia.org/wiki/Wagon-wheel_effect

> -: obviously, we end up with two attributes/object properties.

Agree, hadRole became sRole and oRole.
Also, sRole and oRole are silly to look at by themselves.

> 
> Question: what about the other linked concepts in n-ary relations: do they have roles?

I think those roles are implied by their existing relations. (perhaps this is what Graham keeps talking about when he's arguing they are sub relations).


> e.g. plan in an association, starter in a start, ender in an end, activity in a delegation/derivation?

prov:hadPlan, prov:entity (on Start), prov:entity (on End), prov:hadActivity (on Delegation/Derivation).

One could argue that hadPlan is a kind of role, but I wouldn't say it explicitly (no point in drawing the connection).


Regards,
Tim

> 
> 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 21:04:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 May 2012 21:04:06 GMT