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

Hi Jim,

I think this is domain specific.  The DM does not say anything about it.

Luc

On 03/05/2012 05:29 PM, Jim McCusker wrote:
> 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 
> <mailto: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 <mailto: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 <mailto: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
>>             <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 <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
>
>
>
>
>         -- 
>         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
>
>
>
>
>
> -- 
> 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

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Monday, 5 March 2012 17:40:33 UTC