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

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
> 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, pmissier@acm.org
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier

Received on Friday, 23 September 2011 10:33:32 UTC