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

Re: URI Fragments (typo fixed version)

From: Nathan <nathan@webr3.org>
Date: Fri, 12 Mar 2010 20:42:36 +0000
Message-ID: <4B9AA73C.8040207@webr3.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: Leigh Dodds <leigh.dodds@talis.com>, Linked Data community <public-lod@w3.org>
Kingsley Idehen wrote:
> Nathan wrote:
>> Leigh Dodds wrote:
>>  
>>> Hi,
>>>
>>>    
>>>> exactly.. how *DO* you remove a resource from the web of linked data?
>>>>
>>>> let's just suppose that the high court has instructed it; it *must*
>>>> happen - how?
>>>>       
>>> What would you do for a document?
>>>
>>> Its on your web site. Its also in the Google cache and the Wayback
>>> Machine. What do you do? What are your legal requirements, and what
>>> are your practical limitations?
>>>     
>>
>> maybe we can address this for the web of linked data resources before
>> the same issues arise..?
>>
>> 410 Gone and obedient http clients with link editing capabilities.
>>
>> google cache remove, would be interesting to test the 410 with them
>> though:
>> http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164734
>>
>>
>> wayback:
>> http://www.archive.org/about/exclude.php
>>
>> note the identical way's of doing it; robots.txt handles the current web
>> of documents (pretty much).
>>
>>   
> How does that remove TimBL's URI in my linked data space? A URI that is
> owl:sameAs my local URI for him?
> 

hence why the subject is "URI Fragments" :) as I said earlier:

"however if we take the case of TimBL's card; personally I can't see any
reason why he couldn't have a personal uri of say
http://www.w3.org/TimBL which 303 See Other through to his card; then
his personal uri is a resource all of its own and independent of any
representation; thus allowing representations to be moved around /
deleted without any effect on his personal URI, and further allow for
multiple information resources describing him, with different
media-types."

and obviously as mentioned a few minutes ago in a reply to Richard, the
410 Gone could only apply (unambiguously) to resources without a hash.

All in I'm gunning for Roy T. Fieldings original single version of a
resource (and no fragments, except for a few use-cases which I'll cover
later) none of this "two kinds of resource", and use HTTP status codes
and dereferencing to:

1: 204 No Content = resource which maps to an empty set / reserved
resource that can't be used for anything else

2: 303 See Other = indicates that the requested resource does not have a
representation of its own that can be transferred by the server over
HTTP (the way linked data already uses it)

3: 301 Moved Permanently = The requested resource has been assigned a
new permanent URI and any future references to this resource SHOULD use
one of the returned URIs.  Clients with link editing capabilities ought
to automatically re-link references to the request-target to one or more
of the new references returned by the server

4: 410 Gone = The requested resource is no longer available at the
server and no forwarding address is known.  This condition is expected
to be considered permanent.  Clients with link editing capabilities
SHOULD delete references to the request-target after user approval.

Regardless of semantic web, linked data is bound to http for the time
being thanks to dereferencing, http does give us the utilities to do
everything we need with regards linked data.

as for it not being bound in the future; all of these use cases can also
be represented in rdf with existing ontologies (dcterms:replaces and so
forth), and when something can't simply make a predicate that allows it,
shouldn't be too hard..

further in to the future I can't see any reason why we can't simply:

<http://a.org/b> owl:sameAs <aprotocol://a.org/http://a.org/b>

I'm strongly putting focus back on the "conceptual mapping" side of
resources; that allows for anything and covers everything, afaict we
have no need to use #fragments at all.

regards!
Received on Friday, 12 March 2010 20:43:21 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:25 UTC