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

That's precisely what I'm NOT implying. Here's the example fleshed out more
in manchester syntax:

==== in PROV ====
Class: prov:Plan

Class: prov:ProcessExecution

ObjectProperty: prov:hasPlan
    Domain:
        prov:ProcessExecution
    Range:
        prov:Plan

==== in HTTP provenance extension ====
# I'm adding extra restrictions here to show how you can go about
formulating what the plan needs.
# These actions can also be based on service descriptions from SADI and
SAWSDL.
Class: HTTP_1.1:GET
    SubClassOf:
        prov:ProcessExecution
        prov:used exactly 1 HTTP_1.1:UniformResourceLocator
        prov:generated exactly 1 HTTP_1.1:Transaction
    EquivalentTo:
        prov:ProcessExecution and prov:hasPlan value HTTP_1.1_GET

# This is not the same thing as the class HTTP_1.1:GET. Note that it's type
is prov:Plan.
Individual: HTTP_1.1:GET
    Types: prov:Plan
    Annotations:
        rdfs:comment "This is the plan that is defined by the HTTP 1.1 GET
operation."

==== in provenance graph ====

Individual: pe1
    Types:
        HTTP_1.1:GET
        prov:ProcessExecution
    Facts:
        prov:hasPlan HTTP_1.1:GET


>From http://www.w3.org/TR/owl2-new-features/#F12:_Punning:

OWL 1 DL required a strict separation between the names of, e.g., classes
and individuals. OWL 2 DL relaxes this separation somewhat to allow
different uses of the same term, e.g., Eagle, to be used for both a class,
the class of all Eagles, and an individual, the individual representing the
species Eagle belonging to the (meta)class of all plant and animal species.
However, OWL 2 DL still imposes certain restrictions: it requires that a
name cannot be used for both a class and a datatype and that a name can only
be used for one kind of property. The OWL 2 Direct Semantics treats the
different uses of the same name as completely separate, as is required in DL
reasoners.

Similarly, the class HTTP_1.1:GET is a class representing all process
executions that conform to the HTTP 1.1 GET operation. The individual
HTTP_1.1:GET represents the specification for HTTP 1.1 GET, and is of the
(meta)class Plan.

Jim

On Thu, Sep 15, 2011 at 2:17 PM, Myers, Jim <MYERSJ4@rpi.edu> wrote:

>  This seems to imply that an event is an instance of class: plan and the
> individual plans are instances of class: plan. In this case when I say
> individual plan I’m talking about something like the workflow template – a
> definition of the generic process versus an event where both the generic and
> parameterized inputs are all defined and can only occur once. Do you want
> the workflow template and event to both be instances of the same class?***
> *
>
> ** **
>
> Jim****
>
> ** **
>
> *From:* Jim McCusker [mailto:mccusj@rpi.edu]
> *Sent:* Thursday, September 15, 2011 1:40 PM
>
> *To:* Myers, Jim
> *Cc:* Provenance Working Group WG
> *Subject:* Re: PROV-ISSUE-95 (Recipes as Classes): Recipes as classes?
> [Conceptual Model]****
>
>  ** **
>
>  I was saying that an event that follows a recipe/plan is an instance of
> that recipe/plan. The URI for a plan can be used two ways in OWL 2: as an
> individual (the description of the plan, such as components, parameters,
> whatnot), and as a class (defining members of the set, formally defining
> what is used in a plan).****
>
> ** **
>
> Note: I find myself avoiding saying recipe because, while it's specific, it
> just doesn't sound right. Plan might be specific enough while covering other
> usages that recipe normally wouldn't be used for.****
>
> ** **
>
> Jim****
>
> On Thu, Sep 15, 2011 at 12:29 PM, Myers, Jim <MYERSJ4@rpi.edu> wrote:****
>
> ??? Sorry -not sure I understand your comment – I was saying that while PEs
> are instances of some class (process), I didn’t think it could recipe since
> instances of that class would be files, not PEs. Are you
> agreeing/disagreeing/re-framing?****
>
>  ****
>
> Jim****
>
>  ****
>
> *From:* Jim McCusker [mailto:mccusj@rpi.edu]
> *Sent:* Thursday, September 15, 2011 12:02 PM
> *To:* Myers, Jim
> *Cc:* Provenance Working Group WG
> *Subject:* Re: PROV-ISSUE-95 (Recipes as Classes): Recipes as classes?
> [Conceptual Model]****
>
>  ****
>
> On Thu, Sep 15, 2011 at 11:23 AM, Myers, Jim <MYERSJ4@rpi.edu> wrote:****
>
> We had discussions earlier about the idea that a PE was an instance of a
> process which has a recipe and then decided that we could just represent PE
> hasRecipe R without realizing the process itself in the model. I don't have
> an opinion about the decision but I bring it up because I think process
> would be the right thing to be the class for a PE instance, not recipe. One
> type of instance of a recipe could be a file (text, workflow description,
> etc.) - a PE wouldn't be an instance of a recipe, but could be an instance
> of the process the recipe describes.****
>
>  ****
>
> I think that's where the punning comes in. When treated as an individual,
> the recipe is the plan. When treated as a class, it is the group of things
> that conform to that plan.****
>
>  ****
>
> 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****
>
>
>
> ****
>
> ** **
>
> --
> 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