- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 02 Dec 2009 10:34:06 -0500
- 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 :-) Kingsley > regards! > > -- 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