- From: Timothy Lebo <lebot@rpi.edu>
- Date: Thu, 31 May 2012 11:40:18 -0400
- To: Timothy Lebo <lebot@rpi.edu>
- Cc: Graham Klyne <graham.klyne@zoo.ox.ac.uk>, public-prov-wg@w3.org
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 15:41:24 UTC