W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2011

Re: Definitions and provenance and invariance

From: Paolo Missier <Paolo.Missier@ncl.ac.uk>
Date: Mon, 27 Jun 2011 15:14:39 +0100
Message-ID: <4E08904F.7040009@ncl.ac.uk>
To: "Myers, Jim" <MYERSJ4@rpi.edu>
CC: Pgroth <pgroth@gmail.com>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Jim,

thanks for your comments -- the intent there was to see if the IVP model could be casted as something we are more familiar with, 
such as an object mode. It can't, to a large extent, as you point out.
That's fine, so I am going to propose something else that avoids the object framework altogether, in an attempt to facilitate consensus.
   Creating names for things in a given state is fine.  However, I feel that at some point you will have to contend with the issue 
of "what has changed" between two things. It may not be the values of some properties, but surely somehow you have to account for 
the nature of a change?

Thanks,
    -Paolo


On 6/27/11 2:13 PM, Myers, Jim wrote:
> Paolo,
> Regarding your note about i0 and i1 being the same class- wouldn't an
> identity condition usually be something you'd associate with a  class,
> and if so, what would that be in this case? The way we've been
> discussing things, i0 would be 'the same as' i1, i2, etc. at different
> times, but i1 would never be 'the same as' i2.
>
> If I back up a bit, I think our original purpose with IVPs was to create
> a mechanism to be able to describe the effect of a process execution on
> a mutable object (like a file with changeable content). Broadly one
> could do that either by talking about the effect of processes on
> properties, or create names for the thing in given states (basically
> IVPs) so one can talk about thing-in-state-one disappearing and
> thing-in-state-2 appearing, etc. I think there are at least a couple
> reasons that the IVP route is preferable - it reuses the mechanism we
> like for immutable things, and it avoids the semantics of a process
> using and generating property values which sounds odd (to me anyway,
> particularly for the general cases where it is harder to think of one
> type of object and fixed property types) and has some implication that
> the object is not changed beyond that property (versus the process
> affecting the object with the visible/observable result of that state
> change being a property value change.)
>
> In your discussion, it isn't clear to me whether you're questioning
> things at this level - if i0...i5 are all the same class, and all have
> modifiable content (not sure why copies i3 and i5 of files have fixed
> content but i2 and i4 don't in your diagram), or even if just i1 does,
> how do you want to document the effect of an append process? Are you
> thinking of a model more like (i1, co=X)<-usedby- Append<--generatedBy-
> (i1, co=Y) ? i.e. everything is the same class, but we now have to
> explicitly identify the property(ies) as part of the used/generated by
> relations?
>
>    Jim
Received on Monday, 27 June 2011 14:15:20 GMT

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