W3C home > Mailing lists > Public > public-lod@w3.org > March 2010

isDescribedBy breaks Linked Data

From: Nathan <nathan@webr3.org>
Date: Tue, 09 Mar 2010 17:15:54 +0000
Message-ID: <4B96824A.40902@webr3.org>
To: Linked Data community <public-lod@w3.org>
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> .

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>
isDescribedBy. Even if it's description is now somewhere else.

"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!

As far as I can tell, in order to keep everything dereferencable when
URIs change, the URI itself must be changed where ever possible.

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.

Many Regards!

Received on Tuesday, 9 March 2010 17:16:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:57 UTC