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

Tim,

I'll just try and clarify my comment about sub-relations.

Technically, a relation is a set of pairs, or tuples (cf. 
http://simple.wikipedia.org/wiki/Relation_(mathematics)), indicating the items 
which are held to be /in/ that relation.

A sub-relation is then a subset of the tuples of a relation.

Consider the relation <= over the set of integers {1,2,3}.  It's members would 
be {(1,1),(1,2),(1,3),(2,2),(2,3),(3,3)}.  The relation == over the same domain 
of discourse would be a subrelation of this with members {(1,1),(2,2),(3,3)}

Sorry if I'm labouring the obvious here.  For RDF, this kind of construction can 
be seen in the formal semantics (look for IEXT and ICEXT).  I'm applying similar 
thinking to PROV-DM, though maybe the actual language I use should be left to 
the PROV semantics?

The key consequence, I perceive, is that any set of values (a,b,...) that 
satisfy some PROV-DM relation

    prov-relation(id;a,b,...,[prov:role=foo])

would also satisfy

    prov-relation(id;a,b,...)

#g
--


On 30/05/2012 15:16, 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 Wednesday, 30 May 2012 15:04:55 UTC