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

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)?
 Jim


From: Jim McCusker [mailto:mccusj@rpi.edu]
Sent: Thursday, September 15, 2011 4:06 PM
To: Myers, Jim
Cc: Provenance Working Group WG
Subject: 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<mailto: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<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<mailto: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<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<mailto: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<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