Nathan wrote:
Hi All,
Admittedly a rather bold subject line, but I was just thinking about the
often suggested usage of isDescribedBy for associating a subject with a
resource describing it, and whilst good for RDF it appears to break
Linked Data from what I can see.. consider:
<http://example.org/a#t> dcterms:relation <http://nowgone.org/b#t> .
Of course that's broken, but it has nothing to do with isDescribeBy, its
the triple in question at fault :-)
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#>
<http://dbpedia.org/resource/Linked_Data> wdrs:describedby
<http://dbpedia.org/page/Linked_Data#this> .
Linked Data breaks if we assume Documents aren't Data Objects in their own
right, and then assume that URLs suffice as their Identifiers. Yes, in this
case it does break, hence the twister of a triple above (note the #this object
of a slash URI based subject in the relation above).
Note: Link: response from server can also unveil the Data Object and Description
bearing Resource relation. Just as the doc could carry same info in <link/>.
Trouble is that nowgone.org is now gone; and there is no way to
dereference the data to find out what <http://nowgone.org/b#t>
"When someone looks up a URI, provide useful information, using the
standards", of course the very fact the information is gone breaks this
Linked Data guideline, and whilst the subject of this mail was a bit
over the top; I would like to make it clear that (imho) using
isDescribedBy as a workaround to say that the description of subject is
now available <here> simply won't work; because you can't dereference
the subject to get that all important triple!
I hope I didn't say or imply: using isDescribedBy *is* a workaround to
say that the description of subject is now available.
I hope I implied: "wdrs:describedby" is a good property for the
relation that connects a Data Objects to a Resource bearing its
Description.
Re. Data Object Reference availability, its depends on where the loss of
visibility occurs. If looking at the Web of Linked Data in general,
erasing an Identifiers will be hard (i.e. across all Subject or Objects
slots in a Web Scale Distributed Graph). See:
curl -I -H "Accept: text/html" http://dbpedia.org/resource/Linked_Data
HTTP/1.1 303 See Other
Server: Virtuoso/06.01.3127 (Solaris) x86_64-sun-solaris2.10-64 VDB
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Date: Tue, 09 Mar 2010 16:31:49 GMT
Accept-Ranges: bytes
Link:
<http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/Linked_Data>;
rel="timegate"
Location: http://dbpedia.org/page/Linked_Data
Content-Length: 0
What about:
<<http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resource/Linked_Data>>
(note: when its live and functional) ditto other places that have
accessed and stored the Representation of the Description of said Data
Object?
As far as I can tell, in order to keep everything dereferencable when
URIs change, the URI itself must be changed where ever possible.
When a Data Object Identifier that is inextricably bound to its
Description bearing Resource URL changes, then you have two things to
change. Otherwise, its one or the other.
Thus I guess I would like to get thoughts on how this very real scenario
of sites dropping / relocating can be addressed in Linked Data terms;
and what can be leveraged to communicate the changing or removal of URIs
(!) and documents describing them.
Real example:
Consider "flashden.net" which is a long lived, stable site and will be
for years to come - for legal reasons they've had to change their name
and domain to "activeden.net" - had this been 2 years down the line when
they'd also be publishing linked data this could cause a real problem.
They would *have* to change all their URIs.
Shove the triples in an new RDF store capable of deploying Linked Data
and make the appropriate URL re-write rules, with regards to new
location. As for the old location, if legally usable: put 301's in
place, beyond that the Linked Data archive service providers and Google
cache are the only options I know of.
Many Regards!
Nathan
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
