RE: Definitions and provenance and invariance

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