Re: PROV-ISSUE-95 (Recipes as Classes): Recipes as classes? [Conceptual Model]

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
> 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