W3C home > Mailing lists > Public > public-lod@w3.org > December 2009

Re: Contd: [pedantic-web] question about sioc / foaf usage

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 02 Dec 2009 10:34:06 -0500
Message-ID: <4B1688EE.5030704@openlinksw.com>
To: pedantic-web@googlegroups.com
CC: natlu2809@gmail.com, Linked Data community <public-lod@w3.org>, SIOC-Dev <sioc-dev@googlegroups.com>
Nathan wrote:
> nat lu wrote:
>>    [snip]
>>>     The identity however is maintained by the "fingerprint" of the
>>>     object graphs, and the URI is just an image of that fingerprint at
>>>     some point in time/location ?
>>    I think Identity is managed by the beholder of things, the one that
>>    deems them important enough to be described, mentioned, talked
>>    about, or referenced :-)
>> I should have said what I was thinking in my head and not what my
>> fingers were thinking : "The identity however is defined by the
>> fingerprint of the object graphs, varying perhaps in time". If I have
>> today a graph [a->b->c]  identified by [http://example.lod/myThing] and
>> tomorrow I change it to [a->-b->c->d] or maybe [a->b->d], the address is
>> the same, the access path is the same, it identifies the same thing, but
>> the qualities of that thing have varied : ie, it is the same, but
>> different. That difference may or may not be important or have
>> consequences for the consumer of that thing.
>> And unless I provide a versioning URI its not going to be possible to
>> provide for recognising, or "replaying" an identity (or isolating the
>> change in identity) of a thing, at some previous time - the address for
>> instance start as [http://example.lod/v1/myThing] and then become
>> [http://example.lod/v2/myThing] and so on ? But in this case the address
>> has changed, and the internal access path might have, but they're still
>> the same thing (I note it may perhaps also proxied by an agnostic
>> [http://example.lod/myThing]. I suppose a canonical LoD-GUID and the
>> version chain would need to be qualities of each version ?
> <http://example.com/thing>
> <http://example.com/thing#v1>
> <http://example.com/thing#v2>
> <http://example.com/thing#v3>
> <http://example.com/thing#latest>
> then when you dereference the uri to get info you always hit the same
> graph since you remove the fragment to dereference.
> and to handle the versions you can use triples like..
> <http://example.com/thing#v3>
> 	<sioc:earlier_version>
> 		<http://example.com/thing#v1> ,
> 		<http://example.com/thing#v2> ;
> 	<sioc:previous_version>
> 		<http://example.com/thing#v2> ;
> 	<sioc:latest_version>
> 		<http://example.com/thing#latest> .
> <http://example.com/thing>
> 	<owl:sameAs>
> 		<http://example.com/thing#latest> .
Yes, this is all fine, but it falls bucket: how you or your application 
have decided to version data etc. :-)

> thus you can always describe a single version of a resource, the latest
> version, and so on.
Delta-V vocabulary for RDF would enable this sort of thing to be done in 
a uniform manner re. interoperability etc.. But its still application 
(Versioning) specific orchestration that also loosely connected to the 
Provenance space etc..
> <completely ducking out of the time-travel convo, even if it is related>
Time-travel via Dataset Deltas is a service that someone (or entity) may 
decide to offer; basically, a Linked Data driven Time Machine :-)

> regards!



Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Wednesday, 2 December 2009 15:34:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:02 UTC