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