W3C home > Mailing lists > Public > public-prov-wg@w3.org > March 2012

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

From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Date: Mon, 5 Mar 2012 14:31:50 +0100
Message-ID: <CAExK0DdovNm8NsfKEhm0XB2dCczV_f0FuNx2hTxxjjiQS8V5mg@mail.gmail.com>
To: Jim McCusker <mccusj@rpi.edu>
Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
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
>
Received on Monday, 5 March 2012 13:32:27 GMT

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