Re: Definitions and provenance and invariance

I can (*), but I'm not sure it helps our main goals.

#g
--

(*) to me, it implies some feature that is fundamental to "identifying" (**): 
defining what makes en entity what it is, and what distinguishes it from other 
entities.  The colour of my eyes is not, in my view, such a feature.


(**)

(a) "to recognize or establish as being a particular person or thing"
-- http://dictionary.reference.com/browse/identify

(b) "establish or indicate who or what (someone or something) is"
-- http://oxforddictionaries.com/definition/identify


Luc Moreau wrote:
> You may be right,  can you explain how you understand it?
> Luc
> 
> On 06/20/2011 11:22 AM, Graham Klyne wrote:
>> It seems we understand the phrase "integral to identity" somewhat 
>> differently, so that's a different reason not use it as part of the 
>> definitions of "things" and "invariant views".  The more you say, the 
>> more room there is for disagreement ...
>>
>> #g
>> -- 
>>
>> Luc Moreau wrote:
>>> Hi Simon and Graham,
>>>
>>> I added a response to Graham's comment on invariant property and 
>>> identity.
>>> See 
>>> http://www.w3.org/2011/prov/wiki/ConceptInvariantViewOnThing#Comments
>>>
>>> Cheers,
>>> Luc
>>>
>>> On 06/19/2011 12:18 PM, Simon Miles wrote:
>>>> Graham,
>>>>
>>>> OK, thanks for the clarification. I agree with your point, and am also
>>>> sympathetic to your discomfort with everything invariant being
>>>> "integral to identity".
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>>
>>>> On 17 June 2011 23:00, Graham Klyne<GK@ninebynine.org>  wrote:
>>>>> 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
>>>>>>> ______________________________________________________________________ 
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ______________________________________________________________________
>>>>> This email has been scanned by the MessageLabs Email Security System.
>>>>> For more information please visit http://www.messagelabs.com/email
>>>>> ______________________________________________________________________
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Monday, 20 June 2011 13:45:02 UTC