- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 10 Nov 2010 14:52:01 -0500
- To: Lars Heuer <heuer@semagia.com>
- CC: Linked Data community <public-lod@w3.org>
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
Received on Wednesday, 10 November 2010 19:52:30 UTC