Re: 303 redirect to a fragment – what should a linked data client do?

于 2010/6/11 5:41, Christoph LANGE 写道:
> Hi Nathan,
>
>    thanks for your clarifying reply!  That gave me the confirmation that we
> were on the right track.  Indeed I should not judge such issues from the
> behavior of browsers that are not even RDF-aware.
>    
During I was developing a PIM tool, I realized that the only useful part 
of URI is its uniqueness. URI has nothing to the representation of 
content and the semantic meaning of content).URI organize things in a 
tree model, but information/Knowledge is networked, so URI isn't 
suitable for organizing information/knowledge. This fact let me think 
about how to organize information/knowledge by itself, and then I found 
a way to search by 'knowledge'.

regards

Peng
> Cheers,
>
> Christoph
>
> 2010-06-10 14:24 Nathan<nathan@webr3.org>:
>    
>> ...
>>
>> long:
>> I've asked this question and several related a few times over the past
>> few months (hence responding).
>>
>>   From what I can tell what URI Identifier and dereferencing process (+
>> Request Response chain which follows) are entirely orthogonal issues.
>>
>> To illustrate, if you dereference http://dbpedia.org/resource/London
>> then the final RDF representation you get will be courtesy of
>> http://dbpedia.org/data/London.[n3/rdf/ttl], but the RDF will still
>> describe http://dbpedia.org/resource/London.
>>
>> If you consider from a client / code standpoint in a setup where you
>> have two modules abstracted from each other, an HTTP Client and an RDF
>> Parser, the RDF Parser will request something like:
>>     rdf = HTTP->get( uri );
>> What the HTTP Client does, the deferencing process, the request response
>> chain which follows, the values in the HTTP Header fields, is completely
>> abstracted, transparent to the RDF Parser and indeed of no concern.
>>
>> Thus regardless of how the HTTP request chain works out, if you try to
>> get a RDF description for http://example.org/foo#bar then you'll still
>> be looking for http://example.org/foo#bar in the RDF that you get back.
>>      
>

Received on Thursday, 10 June 2010 23:10:17 UTC