Re: Status codes / IR vs. NIR -- 303 vs. 200

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