Re: Definitions and provenance and invariance

Simon Miles wrote:
> Graham, Stian, all,
> 
> I might be confused, but this seems a more complex model than the one
> proposed by Jim and Luc.  Why do we need to both a Dynamic Resource
> and a View Resource?  I can't see any meaningful difference between
> them either in Graham's definition or Stian's (helpful) concrete
> example.  What is the point of saying anything about a mutable
> property, e.g. "content of DynamicResource i0", when any assertion of
> a mutable property's value will not always hold anyway?

Speaking for myself... I used the terms "Dynamic" and "View" as labels to 
distinguish their roles in the structure given.  I would not choose to model 
them as different types.

My point, expressed in terms of Stian's example, is that the notion we have been 
calling IVP is present in the viewOf relation rather than inherent in the 
resources themselves.  This was my point, which I think is also at the heart of 
the proposal by Jim and Luc.

I happen to think that the definition as proposed in the wiki at 
http://www.w3.org/2011/prov/wiki/ConceptInvariantViewOnThing#ACCEPTED_at_teleconference_2011-06-16 
is over-specified (I've added some comments there).  But having expressed that 
reservation, I'm content to let them stand pro tem for the purposes of discussion.

#g
--


> On 16 June 2011 15:39, Stian Soiland-Reyes
> <soiland-reyes@cs.manchester.ac.uk> wrote:
>> On Tue, Jun 14, 2011 at 12:09, Graham Klyne <GK@ninebynine.org> wrote:
>>
>>> Suppose that the "Dynamic resource has a number of different observable
>>> properties, some of which do not change over time, and others which do.
>>>  Then the View resource would be a resource for with a similar set of
>>> properties such that do not change over time, but correspond to the dynamic
>>> resource properties at a given time (including properties that do not change
>>> over time).  If the Dynamic resource does not change over time, then it may
>>> also serve as its own view resource:  the has view property can be
>>> reflexive.
>>>
>>> The provenance resource is an assertion about the properties of the view
>>> resource.  I believe the key requirement that we try to capture is that the
>>> properties about which the provenance resource makes assertions are
>>> invariant - there is no assertion in the provenance resource which is not
>>> always true of the view resource.
>>
>> This is a very beautifully simple model which I think we should keep
>> in mind before digging too much into the exciting discussions.
>>
>>
>>
>> "simplified" for the File example:
>>
>>
>> :i0 a :DynamicResource ;
>>  :name "/home/towns.txt" ;
>>  :content [ :bytes "" ] ;
>>  :creator :Alice .
>>
>>
>> :i0View a :ViewResource ;
>>   :viewOf :i0 ;
>>   :name "/home/towns.txt" ;
>>   :creator :Alice .
>>
>>
>> # Metadata stored in filesystem
>> :i0Provenance a :ProvenanceResource ;
>>   :provenanceOf :i0View ;
>>   :account :FileSystem ;
>>   :processes (
>>      [  :agent :Alice ;
>>         :location :server1 ;
>>         :process :fileCreation ;
>>         :time "2011-06-15 18:00:01 UTC"  ]
>>    ) .
>>
>> # however the log file claims the file was created on her workstation
>> (not server), and 1 second later (clocks out of sync?)
>>
>> :i0Provenance2 a :ProvenanceResource ;
>>   :provenanceOf :i0View ;
>>   :account :ServerLogFile ;
>>   :processes (
>>      [  :agent :Alice ;
>>         :location :AliceWorkstation;
>>         :process :fileCreation ;
>>         :time "2011-06-15 18:00:02 UTC"  ]
>>    ) .
>>
>>
>>
>> ### New graph - Content changed
>>
>> :i0 a :DynamicResource ;
>>  :content [ :bytes "New York\nLos Angeles\n"  ] ;
>>  :name "/home/towns.txt" ;
>>  :creator :Alice ;
>>  :readBy (:Alice :Bob :Charles :David)
>>
>>
>> :i2 a :ViewResource ;
>>  :viewOf :i0 ;
>>  :name "/home/towns.txt" ;
>>  :creator :Alice ;
>>  :content [ :bytes "New York\nLos Angeles\n"  ] .
>>
>> :i2Provenance a :ProvenanceResource ;
>>  :provenanceOf :i2 ;
>>   :account :FileSystem ;
>>   :processes (
>>      [  :agent :Alice ;
>>         :location :server1 ;
>>         :process :fileCreation ;
>>         :time "2011-06-15 18:00:03 UTC"  ]
>> # Lost as :FileSystem metadata only keeps last-modified
>> #     [   :agent :Alice ;
>> #         :location :server1 ;
>> #         :process :fileWrite ;
>> #         :time "2011-06-15 18:00:03 UTC"  ]
>>     [
>>         #  :agent :Bob;  - not recorded as only owner/creator is kept
>>         :location :server1 ;
>>         :process :fileWrite ;
>>         :time "2011-06-15 18:14:12 UTC"  ]
>>    ) .
>>
>>
>> So say there are additional mutable properties such as :readBy above -
>> would you consider those propagating into the view as mutable
>> properties? There could be another view over :i2 for the file before
>> it was read by Charles, where :readBy is an immutable property.
>>
>> The example graph above does not distinguish between mutable and
>> immutable properties - perhaps we shouldn't as they could be difficult
>> to find, identify and measure.
>>
>> Here :readBy is not kept by neither the log file or file system and is
>> a kind of conceptual property - it could be discovered by simply
>> asking everyone who could have read it, or inferred from traced file
>> usage, like if its sent in an email.
>>
>> --
>> Stian Soiland-Reyes, myGrid team
>> School of Computer Science
>> The University of Manchester
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
> 
> 
>

Received on Friday, 17 June 2011 22:00:13 UTC