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:51:02 +0000
Message-ID: <4B9AA936.6060207@webr3.org>
CC: Kingsley Idehen <kidehen@openlinksw.com>, Leigh Dodds <leigh.dodds@talis.com>, Linked Data community <public-lod@w3.org>
Nathan wrote:
> 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.

correction, no need to use #fragments as we currently are, other than
for a few use-cases which I really don't want to cover at the minute
till the above is discussed a little bit and I've had time to write it
up semi properly.

regards
Received on Friday, 12 March 2010 20:51:45 UTC

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