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