- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Mon, 05 Mar 2012 17:39:56 +0000
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|85e52ef26af4df12c5035b198aad6a45o24Hdx08L.Moreau|ecs.soton.ac.uk|4F54FA6C>
Hi Jim, I think this is domain specific. The DM does not say anything about it. Luc On 03/05/2012 05:29 PM, Jim McCusker wrote: > I'm not sure that it yet addresses my comments. Plans are entities, > sure, but how are we to know that a plan was successfully followed? > > Jim > > On Mon, Mar 5, 2012 at 1:31 PM, Daniel Garijo > <dgarijo@delicias.dia.fi.upm.es > <mailto:dgarijo@delicias.dia.fi.upm.es>> wrote: > > Hi Jim, > this issue (http://www.w3.org/2011/prov/track/issues/95) is still > raised against the ontology. > After the latest changes (plans are entities, that are related to > an Association), are you ok to close it? > > Thanks, > Daniel > > > 2011/9/23 Jim McCusker <mccusj@rpi.edu <mailto:mccusj@rpi.edu>> > > Yes. However, does the ASN distinguish between PEs that use > plans (but not successfully followed) and PEs that > successfully use plans? The first casualty of war, and all > that... > > Jim > > > On Fri, Sep 23, 2011 at 3:25 PM, Luc Moreau > <L.Moreau@ecs.soton.ac.uk <mailto:L.Moreau@ecs.soton.ac.uk>> > wrote: > > Hi Jim, > Does it map into the same process execution expression in > PROV-ASN? > Luc > > > On 23/09/11 19:49, Jim McCusker wrote: >> Not quite what you have below. myspace:workflow is a >> subclass of ProcessExecution and has rdf:type Plan. Plan >> is a meta-class of ProcessExecutions. So it would look >> more like this: >> >> Class: prov:Plan >> Class: prov:ProcessExecution >> >> ObjectProperty: prov:hasPlan Domain: prov:ProcessExecution >> Range: prov:Plan >> >> ObjectProperty: prov:hasSpecification >> Domain: prov:Plan >> # range: unconstrained, owl:Thing >> >> ## this is an extension for workflows >> >> Class: myspace:workflow >> SubClassOf: prov:ProcessExecution >> >> ## instances >> >> Individual: myspace:workflow >> Type: prov:ProcessExecution >> >> >> Individual: pe1 >> >> Type: >> prov:ProcessExecution >> >> myspace:workflow >> >> Facts: >> prov:hasPlan workflow1 >> >> >> On Fri, Sep 23, 2011 at 6:32 AM, Paolo Missier >> <Paolo.Missier@ncl.ac.uk >> <mailto:Paolo.Missier@ncl.ac.uk>> wrote: >> >> Hi, >> >> further to Luc's latest mail: we (the editors) >> believe it's a reasonable idea, but wanted to check >> with you that we understand it well. >> >> What you propose is OWL-specific modelling (that's >> why we have moved the issue), so the only real >> requirement for us is that it maps /bidirectionally, >> in a lossless way/ to the conceptual model view of >> ProcessExecutionExpression. >> >> Specifically: would the following work? >> >> Conceptual: processExecution(pe1, somePlanURI, ...) >> >> where somePlanURI is a URI that can be resolved to an >> otherwise undefined plan (for instance, an XML doc >> describing a workflow) >> >> OWL: >> >> ## this is prov >> >> Class: prov:Plan >> Class: prov:ProcessExecution >> >> ObjectProperty: prov:hasPlan >> Domain: prov:ProcessExecution >> Range: prov:Plan >> >> ObjectProperty: prov:hasSpecification >> Domain: prov:Plan >> # range: unconstrained, owl:Thing >> >> ## this is an extension for workflows >> >> Class: myspace:workflow >> SubClassOf: prov:Plan >> >> ## instances >> >> Individual: workflow1 >> Type: >> myspace:workflow >> prov:hasSpecification somePlanURI >> >> Individual: pe1 >> >> Type: >> prov:ProcessExecution >> prov:hasPlan workflow1 >> >> >> >> -Paolo >> >> >> >> >> >> On 9/15/11 9:46 PM, Jim McCusker wrote: >>> On Thu, Sep 15, 2011 at 4:22 PM, Myers, Jim >>> <MYERSJ4@rpi.edu <mailto:MYERSJ4@rpi.edu>> wrote: >>> >>> Got it – makes sense. That mechanism in OWL >>> addresses the distinction between process and >>> description/definition we were discussing. Would >>> it be better to think of the class as Process >>> (versus plan?) – HTTPGet is a subclass of >>> process (whose instances are PEs) and the >>> HTTPGet instance defines the process (and hence >>> is the plan)? >>> >>> >>> That's the idea - the class HTTPGet is a subclass of >>> ProcessExecution, and, since it defines processes, >>> is also a Plan. Since plans can be used (or had) but >>> not followed, the fact that a particular >>> ProcessExecution had a particular plan, but isn't of >>> that type expresses that it didn't go to plan. Which >>> means that I have to tweak my HTTPGet class a little >>> bit: >>> >>> Class: HTTP_1.1:GET >>> SubClassOf: >>> prov:ProcessExecution >>> prov:used exactly 1 >>> HTTP_1.1:UniformResourceLocator >>> prov:generated exactly 1 HTTP_1.1:Transaction >>> prov:hasPlan value HTTP_1.1_GET >>> >>> since having a plan doesn't guarantee that it >>> succeeded, it's a necessary condition that you have >>> the plan to be of that kind of process, but not >>> sufficient (hence, moving it from EquivalentTo to >>> SubClassOf). >>> >>> Jim >>> -- >>> Jim McCusker >>> Programmer Analyst >>> Krauthammer Lab, Pathology Informatics >>> Yale School of Medicine >>> james.mccusker@yale.edu >>> <mailto:james.mccusker@yale.edu> | (203) 785-6330 >>> <tel:%28203%29%20785-6330> >>> http://krauthammerlab.med.yale.edu >>> >>> PhD Student >>> Tetherless World Constellation >>> Rensselaer Polytechnic Institute >>> mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu> >>> http://tw.rpi.edu >> >> >> -- >> ----------- ~oo~ -------------- >> Paolo Missier -Paolo.Missier@newcastle.ac.uk <mailto:Paolo.Missier@newcastle.ac.uk>,pmissier@acm.org <mailto:pmissier@acm.org> >> School of Computing Science, Newcastle University, UK >> http://www.cs.ncl.ac.uk/people/Paolo.Missier >> >> >> >> >> >> -- >> Jim McCusker >> Programmer Analyst >> Krauthammer Lab, Pathology Informatics >> Yale School of Medicine >> james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> >> | (203) 785-6330 <tel:%28203%29%20785-6330> >> http://krauthammerlab.med.yale.edu >> >> PhD Student >> Tetherless World Constellation >> Rensselaer Polytechnic Institute >> mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu> >> http://tw.rpi.edu > > > > > -- > Jim McCusker > Programmer Analyst > Krauthammer Lab, Pathology Informatics > Yale School of Medicine > james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> | > (203) 785-6330 <tel:%28203%29%20785-6330> > http://krauthammerlab.med.yale.edu > > PhD Student > Tetherless World Constellation > Rensselaer Polytechnic Institute > mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu> > http://tw.rpi.edu > > > > > > -- > Jim McCusker > Programmer Analyst > Krauthammer Lab, Pathology Informatics > Yale School of Medicine > james.mccusker@yale.edu <mailto:james.mccusker@yale.edu> | (203) 785-6330 > http://krauthammerlab.med.yale.edu > > PhD Student > Tetherless World Constellation > Rensselaer Polytechnic Institute > mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu> > http://tw.rpi.edu -- 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
Received on Monday, 5 March 2012 17:40:33 UTC