- From: Myers, Jim <MYERSJ4@rpi.edu>
- Date: Mon, 27 Jun 2011 09:13:05 -0400
- To: Pgroth <pgroth@gmail.com>, Paolo Missier <Paolo.Missier@ncl.ac.uk>
- CC: <public-prov-wg@w3.org>
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 > -----Original Message----- > From: public-prov-wg-request@w3.org [mailto:public-prov-wg- > request@w3.org] On Behalf Of Pgroth > Sent: Sunday, June 26, 2011 4:57 AM > To: Paolo Missier > Cc: public-prov-wg@w3.org > Subject: Re: Definitions and provenance and invariance > > For my clarification, once an asseter has an invariant view of some stuff the > asserter can talk about the stuff's provenance with respect to the set of > properties that have been declared fixed? > > Thanks > Paul > > Sent from my iPad > > On Jun 25, 2011, at 8:31 PM, Paolo Missier <Paolo.Missier@ncl.ac.uk> wrote: > > > I have added some comments to the "smaller example" page: > > http://www.w3.org/2011/prov/wiki/FileExample#Comments_.28Paolo.29 > > in an attempt to understand the definitions. There is also a pretty > > picture that tries to capture the gist of the example. See if you like > > it > > > > I believe I fundamentally agree with Jim when I rename "invariant > properties" to "properties whose value is constant across a time span or a > sequence of observable events (which may include transformational > processes)". Time is tricky though, as we know, because of the issues with > distributed clocks potentially being used by different observers. > > > > -Paolo > > > > > > On 6/24/11 8:44 PM, Myers, Jim wrote: > >> I think it's possible to consider the invariance to be defined in terms of > processes (in the same sense we discussed time not necessarily being core > but useful corroborating evidence on the weekly call): B is a view of A implies > that some of the processes that are part of A's lifecycle are things that > start/end the existence of Bs. That maps to time in that there are time > intervals when no such processes occur during which a view exists and the > properties that define that view don't change (for A or B). > >> > >> I know I'm sliding close to the 'invariant properties integral to identity' > discussion by saying 'properties that define the view' but my sense of that > discussion was that really about a strict sense of integral to identity versus a > distinguishing feature of, and both are OK - there's a set of properties that are > either integral to B's identity or distinguishing features of B that together > define what type of thing B is. And the processes that modify those properties > are the ones we're documenting with the provenance statements. > >> > >> Jim > >> > >> > >>> -----Original Message----- > >>> From: public-prov-wg-request@w3.org [mailto:public-prov-wg- > >>> request@w3.org] On Behalf Of Stian Soiland-Reyes > >>> Sent: Friday, June 24, 2011 12:03 PM > >>> To: public-prov-wg@w3.org > >>> Subject: Re: Definitions and provenance and invariance > >>> > >>> On Fri, Jun 24, 2011 at 14:33, Paolo Missier<Paolo.Missier@ncl.ac.uk> > wrote: > >>> > >>> > >>>> I initially thought "invariant" was relative to Time, but it is not > >>>> the case. so what is invariance relative to, here? all possible > >>>> views of this particular rectangle A? but then we are back to > >>>> "properties that are integral to identity", which I thought we had > >>>> dropped > >>> Invariant *is* relative to time, or immune to changes if you like. > >>> > >>> See http://www.w3.org/2011/prov/wiki/FileExample : > >>> > >>> i0: A file, for which we have a property name (/home/towns.txt) and > >>> a property creator (Alice), which are invariant in the interval > >>> [t,t+4[ > >>> i1: A file (i0) with added property content which is empty; it > >>> exists in the interval [t,t+1[ > >>> i2: A file (i0) with added property content with value London and > >>> Edinburgh; it exists in the interval [t+1,t+3[ > >>> i3: A file (i0) with added property content with value London, > >>> Edinburgh, NY, LA; it exists in the interval [t+3,t+4[ > >>> > >>> So invariant properties are properties which can not change over the > >>> lifetime that for *that* IVPT. In the example here the content of i0 > >>> is changing over its lifetime, but its name and creator are immutable. > >>> The name might or might not be integral to identity, but we are not > >>> saying anything about that. In i2 the content is immutable as well > >>> (but perhaps not the "last accessed time" property). > >>> > >>> When we want to say that Charles is emailing the file content, we > >>> want to say "the file with this particular content". So we'll say > >>> that the email i4 is derived from i2 - which is a view of i0 for the > >>> period when the content was London/Edinburgh. It might not be > >>> important exactly when that was, or what was before or after, as > >>> long as we are able to distinguish i2 from i1 and i3. (In fact, in a > >>> distributed setting, Charles might well attach the i2 content after > >>> David has added NY and LA - perhaps his Dropbox had not synchronized > >>> yet) > >>> > >>> > >>> > From this, if B is an invariant of A - then properties they share > >>> > must > >>> have corresponding values - so over that time period all the > >>> immutable properties of B should correspond to (possibly mutable) > properties in A. > >>> > >>> I guess it depends on the 'corresponding' if this means that those > >>> properties are unchanged in A during B's life span - and (just > >>> thought about this) - if B stays being an invariant of A over B's life span. > >>> > >>> > >>> (BTW - why are we saying View Or Perspective - when is it > >>> Perspective and when is it a View?) > >>> > >>> -- > >>> Stian Soiland-Reyes, myGrid team > >>> School of Computer Science > >>> The University of Manchester > > > > > > -- > > ----------- ~oo~ -------------- > > Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org School > > of Computing Science, Newcastle University, UK > > http://www.cs.ncl.ac.uk/people/Paolo.Missier > > > >
Received on Monday, 27 June 2011 13:13:48 UTC