于 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<[email protected]>:
...
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.
