- From: Jim McCusker <mccusj@rpi.edu>
- Date: Mon, 5 Mar 2012 17:29:32 +0000
- To: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
- Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
- Message-ID: <CAAtgn=RQXBy++eCJ+-h_fFtFwUXPfX35HQfGTuumKs6=+oNH+Q@mail.gmail.com>
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> 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> > >> 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 >> > > -- 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 17:30:25 UTC