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: Jim McCusker <mccusj@rpi.edu>
Date: Mon, 5 Mar 2012 17:29:32 +0000
Message-ID: <CAAtgn=RQXBy++eCJ+-h_fFtFwUXPfX35HQfGTuumKs6=+oNH+Q@mail.gmail.com>
To: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
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> 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>
>
>> 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
>>
>
>


-- 
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 17:30:25 GMT

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