On 11/10/10 2:18 PM, Lars Heuer wrote:
Hi there,
I followed the 303 vs. 200 discussion and I tried to understand it. I
assume it is correct that I cannot use
<http://en.wikipedia.org/wiki/John_Lennon>
as subject (or object if that matters) if I want to talk about the
person "John Lennon" and not about the web page since it returns 200
and not 303.
That's a Document Address, by default i.e., HTTP 200 OK response when
you HTTP GET.
Let's assume Wikipedia would return 303 like DBpedia does. Does it
solve the problem?
No, they would have to implement a disambiguation heuristic using 303
that separates Document Address from Entity Name, assuming they adopt
what is known as a slash terminated style of URI re. Linked Data.
I think, it does not solve it, since I cannot make
statements about the *page*
<http://en.wikipedia.org/wiki/John_Lennon> (since I always get 303 and
an agent would interpret it as NIR).
If they adopt the heuristic in play re. DBpedia, it will be fine.
1. http://dbpedia.org/resource/John_Lennon -- Name
2. http://dbpedia.org/page/John_Lennon -- HTML Document with RDFa inside
For other Document formats note:
curl -I http://dbpedia.org/page/John_Lennon
HTTP/1.1 200 OK
Date: Wed, 10 Nov 2010 19:36:20 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Server: Virtuoso/06.02.3128 (Linux) x86_64-generic-linux-glibc25-64 VDB
Accept-Ranges: bytes
Expires: Wed, 17 Nov 2010 19:36:20 GMT
Link: <http://dbpedia.org/data/John_Lennon.rdf>; rel="alternate";
type="application/rdf+xml"; title="Structured Descriptor Document
(RDF/XML format)", <http://dbpedia.org/data/John_Lennon.n3>;
rel="alternate"; type="text/n3"; title="Structured Descriptor Document
(N3/Turtle format)", <http://dbpedia.org/data/John_Lennon.json>;
rel="alternate"; type="application/json"; title="Structured Descriptor
Document (RDF/JSON format)", <http://dbpedia.org/data/John_Lennon.atom>;
rel="alternate"; type="application/atom+xml"; title="OData (Atom+Feed
format)", <http://dbpedia.org/resource/John_Lennon>;
rel="http://xmlns.com/foaf/0.1/primaryTopic";,
<http://dbpedia.org/resource/John_Lennon>; rev="describedby",
<http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/page/John_Lennon>;
rel="timegate"
Content-Length: 144975
Thus, dbpedia.org becomes wikipedia.org.
To cut a long story really short, Wikipedia just needs to install their
own Virtuoso instance with all the data preloaded. That's it! Linked
Data heuristics will be handled automatically by Virtuoso.
My conclusion would be, that neither 303 nor 200 solves the identity
problem, you get always some black spots where an agent cannot decide
if something is meant as IR or NIR.
It's an Identifier Type ambiguity problem i.e. Name or Address
disambiguation via imperfect heuristics.
Personally, it can be solved at the application level by application
developers making a decision about the source of semantic fidelity i.e
HTTP or the Data itself.
The pragmatic question would be:
Which solution gives less black spots? And I think Ian thinks that 200
gives us less black spots than 303.
Ian is indicating that RDF based Linked Data should dog-food i.e., if
RDF formats are about the content of structured data documents, where
the data describes itself, who is HTTP to determine otherwise re. Name
or Address? :-)
Basically, the age-old question re. Moses and the Entity behind the
burning bush:
Moses: who art thou?
Entity: I am Who I am!
Note: the comprehensible manifestation that Moses had to work with was a
"burning bush", even though his cognition was 100% clear about the fact
he wasn't talking to a bush.
200 OK + Content-Location header exposing a self-describing structured
document == I am Who I say I am!
Thus, Ian is pushing the option to let the structured data document be
the mechanism of disambiguation rather than HTTP.
Best regards,
Lars
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
