Re: isDescribedBy breaks Linked Data

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

Received on Tuesday, 9 March 2010 18:01:25 UTC