- From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
- Date: Mon, 5 Mar 2012 14:31:50 +0100
- To: Jim McCusker <mccusj@rpi.edu>
- Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
- Message-ID: <CAExK0DdovNm8NsfKEhm0XB2dCczV_f0FuNx2hTxxjjiQS8V5mg@mail.gmail.com>
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> > 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 Monday, 5 March 2012 13:32:27 UTC