W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

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

From: Jim McCusker <mccusj@rpi.edu>
Date: Fri, 23 Sep 2011 14:49:48 -0400
Message-ID: <CAAtgn=QULDRJRjc7KdDZPgAwrD2UmCCsrJsUuimU_x-GUmNnNw@mail.gmail.com>
To: Paolo Missier <Paolo.Missier@ncl.ac.uk>
Cc: public-prov-wg@w3.org
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
Received on Friday, 23 September 2011 18:50:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:42 GMT