- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 04 Nov 2010 14:42:13 -0400
- To: Ian Davis <me@iandavis.com>
- CC: public-lod@w3.org
On 11/4/10 12:06 PM, Ian Davis wrote: > On Thu, Nov 4, 2010 at 3:56 PM, Kingsley Idehen<kidehen@openlinksw.com> wrote: >>> I don't presume. I prefer to use terms that are familiar with the >>> people on this list who might be reading the message. Introducing >>> unnecessary capitalised phrases distracts from the message. >> Again, you presume. Capitalization might not work for you, but you are not >> the equivalent of an entire mailing list audience. You are one individual >> entitled to a personal opinion and preferences. >> > I hope you agree i have the freedom to express those opinions. 100%. But taking your line of thought, of what relevance to the main topic? > >>>> Anyway, translation: >>>> >>>> What's the problem with having a variety of methods for using LINKs to >>>> associate a "Non Information Resource" with an "Information Resource" >>>> that >>>> describes it (i.e., carries its structured representation)? Why place an >>>> implementation detail at the front of the Linked Data narrative? >>> It's already at the front, and as I say in my post it's an impediment >>> to using Linked Data by mainstream developers. >> I don't believe its already at the front. I can understand if there was some >> quasi mandate that put it at the front. Again, you are jumping to >> conclusions, then pivoting off the conclusions to make a point. IMHO: Net >> effect, Linked Data concept murkiness and distraction. You are inadvertently >> perpetuating a misconception. > Thank you for your opinion. I don't believe I am jumping to conclusions. > I think you are, of course this could be inadvertent, at least so I hope. >>> There is. I find it surprising that you're unaware of it because it's >>> in all the primary documents about publishing Linked Data. >> Please provide a URL for the document that establishes this mandate. I know >> of no such document. Of course I am aware of documents that offer >> suggestions and best practice style guidelines. > Here is one cited by Leigh just now: http://www.w3.org/TR/cooluris/ That document has 3 occurrences of "must", not a single occurrence applies to 303 redirection. Zero occurrences of "mandate" . > Also http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html Zero occurrences of "must" or "mandate" . > And http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ 6 occurrences of must, proximity shown in snippet below for context: "... URIs that identify non-information resources must be set up in ** one of these ways **: Either the data source must return an HTTP response containing an HTTP 303 redirect to an information resource describing the non-information resource, as discussed earlier in this document. Or the URI for the non-information resource must be formed by taking the URI of the related information resource and appending a fragment identifier (e.g. #foo), as discussed in Recipe 7.1. ..." IMHO. You've jumped to a conclusion, and then pivoted from there, as per my initial assertion. Nobody ever mandated 303 redirection. It has always been an option, and so it should remain. >>>>>> The only thing that should be mandatory re. Linked Data is this: HTTP >>>>>> based >>>>>> Entity Names should Resolve to structured Descriptors that are Human >>>>>> and/or >>>>>> Machine decipherable. >>>>> Are you saying that requesting a URI should return a description >>>>> document? >>>> Resolve to a Descriptor Document which may exist in a variety of formats. >>>> Likewise, Descriptor documents (RDF docs, for instance) should clearly >>>> identify their Subject(s) via HTTP URI based Names. >>>> >>>> Example (in this example we have 1:1 re. Entity Name and Descriptor for >>>> sake >>>> of simplicity): >>>> >>>> <http://dbpedia.org/resource/Paris> -- Name >>>> <http://dbpedia.org/page/Paris> -- Descriptor Resource (HTML+RDFa) this >>>> resource will expose other representations via<head/> (<link/> + @rel) >>>> or >>>> "Link:" in response headers etc.. >>> Not sure what you are trying to say here. I must be misunderstanding >>> because you appear to be claiming that >>> <http://dbpedia.org/resource/Paris> is a name but >> That is a Name via HTTP URI (using its Name aspect). > This is an interesting distinction between the resource and a name. > Can you restate it in a new thread so we don't add noise to the 303 > discussion Not noise! URI Abstraction covers: 1. Names -- may or may not resolve 2. Addresses (URLs) -- where data resides. Using what looks like an Address as a Name, doesn't undermine existence of the Name aspect re. overarching URI abstraction. Linked Data, the concept, mandates that the data is Human or Machine decipherable ("useful") via structure outlined via a data model. We did have a computer industry pre. Web. TimBL's URI abstraction is one of the coolest innovations ever! It also remains one of the most widely misunderstood innovations ever! URI abstraction is why the concept of Linked Data at InterWeb scale is going to happen. Just as the Web of Linked Documents has, also at InterWeb scale. [SNIP] BTW - how would you explain your claim on Twitter about 303 being dropped? Here is the excerpt: @iand: seems that the lod mailing list is overwhelmingly supportive of **dropping** 303 redirects #linkeddata. I guess the statement above is also accurate, clear, and reflective of this conversation, right? -- 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 Thursday, 4 November 2010 18:42:42 UTC