- From: Jim McCusker <mccusj@rpi.edu>
- Date: Fri, 23 Sep 2011 16:02:44 -0400
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Cc: public-prov-wg@w3.org
- Message-ID: <CAAtgn=RpLEoX-reg644gZA9VqNsppinvA4dJ9fkkdzw77rZ8Xw@mail.gmail.com>
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>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>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> 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 | (203) 785-6330 >> http://krauthammerlab.med.yale.edu >> >> PhD Student >> Tetherless World Constellation >> Rensselaer Polytechnic Institute >> mccusj@cs.rpi.edu >> http://tw.rpi.edu >> >> >> >> -- >> ----------- ~oo~ -------------- >> Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org >> School of Computing Science, Newcastle University, UKhttp://www.cs.ncl.ac.uk/people/Paolo.Missier >> >> > > > -- > Jim McCusker > Programmer Analyst > Krauthammer Lab, Pathology Informatics > Yale School of Medicine > james.mccusker@yale.edu | (203) 785-6330 > http://krauthammerlab.med.yale.edu > > PhD Student > Tetherless World Constellation > Rensselaer Polytechnic Institute > mccusj@cs.rpi.edu > http://tw.rpi.edu > > -- Jim McCusker Programmer Analyst Krauthammer Lab, Pathology Informatics Yale School of Medicine james.mccusker@yale.edu | (203) 785-6330 http://krauthammerlab.med.yale.edu PhD Student Tetherless World Constellation Rensselaer Polytechnic Institute mccusj@cs.rpi.edu http://tw.rpi.edu
Received on Friday, 23 September 2011 20:03:33 UTC