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

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

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

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

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

#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 Wednesday, 30 May 2012 09:00:49 UTC