W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 10 Nov 2010 16:29:13 -0500
Message-ID: <4CDB0EA9.3020400@openlinksw.com>
To: Lars Heuer <heuer@semagia.com>
CC: "public-lod@w3.org" <public-lod@w3.org>
On 11/10/10 3:59 PM, Lars Heuer wrote:
> Hi Kingsley,
> Thanks for your reply.
> [GET<http://en.wikipedia.org/wiki/John_Lennon>]
>> That's a Document Address, by default i.e., HTTP 200 OK response when
>> you HTTP GET.
> ACK.
>>> 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.
> Why? Doesn't the response depend on the requested content/media type?
> If I want an RDF/XML representation of the document, I can ask for
>       Accept: application/rdf+xml
> and Wikipedia would (ideally) return an RDF/XML representation of that
> resource which tells me that John Lennon is a person who was born at
> ... murdered at ... was part of a group named ... etc.

Yes, so you received a document stating all of the above, who is the 
Subject? How is the Subject Identified?

Have to drop the fact that your non-web-sign-processor (DNA CPU)  
already groks "John Lennon", and does a lot of fancy processing with 
frames en route to disambiguation and context manifestation.

Web isn't anywhere close to the Human Brain (not that I have 100% 
comprehension of how it works, but from the little I understand, it 
trumps anything produced by computers so far).

>>> 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
> I see, DBpedia provides different IRIs. That's fine. But it's not
> possible to keep<http://en.wikipedia.org/wiki/John_Lennon>  (or
> <http://dbpedia.org/resource/John_Lennon>  if that matters) and make
> statements about that, right? I cannot make statements which are
> interpreted rightly without an Internet connection. I need the status
> codes.
> [...]
>> 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.
> To take an practical example: If I want to make statements about the
> following NIR:
>     <http://psi.connectors.de/product/8974>
> What would I have to do? Do I need a redirect? Why? If the above
> mentioned IRI would return RDF/XML (or any other media type requested
> by the client), why do I need a 303? 200 + requested media type +
> content should be enough, shouldn't it?

I am not a proponent of one size fits all re. heuristics for resolvable 
Identifiers re. Linked Data.

If you are developing a Linked Data app. and you make a commitment in 
your code to self-describing data, then 200 OK + Content-Location header 
+ Structured Document (a Descriptor) is fine. Your data handles the Name 
vs. Address disambiguation.

> [...]
>> 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?  :-)
> I am unsure if I am falling into the same trap?!?

Why is it a trap?

What Ian proposes is an option.

> Side note: Each subject/object needs a GET (assuming that predicates
> are always NIRs) to interpret the statement correctly... Does it
> scale? Let's assume you'd send me a DBpedia dump. I cannot interpret
> it correctly, unless I have an Internet connection?
What about when I send you DBpedia in the post on a USB key ? :-)
> Best regards,
> Lars



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 21:29:41 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC