- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 10 Nov 2010 16:29:13 -0500
- 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 -- 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 21:29:41 UTC