- From: Paul Groth <p.t.groth@vu.nl>
- Date: Tue, 4 Sep 2012 17:42:57 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Hi, There seems to be some beginning of a consensus that the furtherest we would go would be to define a "place-holder" relationship that does not require us to revisit constraints. The question then is to whether such a place-holder relationship would be in the prov namespace or exist outside of it such as dc:partof. We do have some backing for defining such a place holder relationship in prov namely prov:hasMember. On the other hand, it may be odd to have such a relation without having more specifics given the work that went into prov:specializationOf. cheers Paul On Tue, Sep 4, 2012 at 5:31 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: > Hi Khalid, > > I am opposed to introduce wasSubactivityOf without studying > constraints/inferences/etc... > > I don't think this example makes much sense: > > activity(a1,2011-11-16T00:00:00,2011-11-17T00:00:00) // in 2011 > activity(a2,2012-11-16T00:00:00,2012-11-17T00:00:00) // in 2012 > wasSubactivity(a1,a2) > > As indicated previously, it's a whole complete new design that > we have to undertake, for which we don't have enough experience. > > Cheers, > Luc > > > On 04/09/12 17:23, Khalid Belhajjame wrote: >> I would go for option 1 provided that we dont say anything from the >> point of view of ordering sub activities, with respect to the parent >> activity. If the only requirement is to have a means to know that one >> activity is a child activity of another then I dont see a problem in >> introducing the relation sub-activity. We did some thing similar with >> collections to a certain degree, when we choose to keep in the DM the >> membership relation, so why not do the same for activities. >> >> Thanks, khalid >> >> On 4 September 2012 14:57, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: >>> >>> Dear all, >>> >>> I would like to kickstart discussion on this public comment. >>> This has already been asked on several occasions, and this has previously >>> been raised on the mailing list. >>> >>> I essentially see two options: >>> 1. We change the model and add a sub-activity relation. >>> 2. We don't change the model, but we come with a good justification for not >>> changing it. In particular, we previously said this was out of scope. >>> Perhaps, >>> we could point to some vocabularies already doing this. >>> >>> What are your views? >>> Regards, >>> Luc >>> >>> >>> On 06/07/12 18:12, Provenance Working Group Issue Tracker wrote: >>>> PROV-ISSUE-447: subactivity relation [prov-dm] >>>> >>>> http://www.w3.org/2011/prov/track/issues/447 >>>> >>>> Raised by: Timothy Lebo >>>> On product: prov-dm >>>> >>>> There is a thread discussing the issue raised by Sutra at >>>> http://www.w3.org/mid/CAJCyKRqtC47OWc_rDRhFcQGdJ-yy2toQBCguUywFGZpHO5Q8Jw@mail.gmail.com >>>> >>>> The original email: >>>> >>>> On Fri, Jul 6, 2012 at 2:45 PM, Satrajit Ghosh <satra@mit.edu> wrote: >>>> hello, >>>> >>>> i was discussing this with luc and based on his feedback thought it might >>>> be >>>> useful to bring this up on the list. >>>> >>>> ---- >>>> question: >>>> how do you encode that a certain activity "emailing a letter" happened >>>> during another activity "a meeting"? >>>> >>>> for example we conduct research studies/projects. >>>> >>>> activity(p1, [prov:type='ex:Project']) >>>> activity(p2, [prov:type='ex:MRIScanning', ex:session=1]) >>>> activity(p3, [prov:type='ex:MRIScanning', ex:session=2]) >>>> >>>> how would i encode that this activity p2 and p3 were conducted during p1? >>>> how would i encode p3 followed p2? >>>> >>>> >>>> luc's response: >>>> Regarding your question, there may be a few options: >>>> you could add time information to your activities. This will help you >>>> understand their ordering. >>>> >>>> Alternatively, if you want an explicit dependency in your graph, then p2 >>>> may >>>> generate something >>>> that starts p3, and/or is consumed by p3 >>>> >>>> Finally, prov doesn't have relations between activities, to express their >>>> nesting, etc. It's important >>>> but we felt this is not specific to provenance, but to process executions. >>>> ---- >>>> >>>> it's the last point on this response that i was not completely sure about. >>>> why "relations between activities" is "not specific to provenance, but to >>>> process executions." >>>> >>>> in the above example, one could say: >>>> >>>> wasSubtaskOf(p2, p1) >>>> wasSubtaskOf(p3, p1) >>>> wasFollowedBy(p2, p3) >>>> >>>> any clarification as to why such relations would be outside the realm of >>>> provenance would be much appreciated. >>>> >>>> cheers, >>>> >>>> satra >>>> >>>> >>>> >>> -- >>> Professor Luc Moreau >>> Electronics and Computer Science tel: +44 23 8059 4487 >>> University of Southampton fax: +44 23 8059 2865 >>> Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk >>> United Kingdom http://www.ecs.soton.ac.uk/~lavm >>> >>> > > -- > Professor Luc Moreau > Electronics and Computer Science tel: +44 23 8059 4487 > University of Southampton fax: +44 23 8059 2865 > Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk > United Kingdom http://www.ecs.soton.ac.uk/~lavm > > -- -- 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 - The Network Institute VU University Amsterdam
Received on Tuesday, 4 September 2012 16:43:30 UTC