| From | Sent On | Attachments |
|---|---|---|
| Ian Davis | Nov 4, 2010 6:21 am | |
| Kingsley Idehen | Nov 4, 2010 7:13 am | |
| Ian Davis | Nov 4, 2010 7:22 am | |
| Kingsley Idehen | Nov 4, 2010 7:59 am | |
| Giovanni Tummarello | Nov 4, 2010 8:20 am | |
| Ian Davis | Nov 4, 2010 8:22 am | |
| Ian Davis | Nov 4, 2010 8:27 am | |
| Leigh Dodds | Nov 4, 2010 8:38 am | |
| William Waites | Nov 4, 2010 8:43 am | |
| Giovanni Tummarello | Nov 4, 2010 8:50 am | |
| Leigh Dodds | Nov 4, 2010 8:53 am | |
| Kingsley Idehen | Nov 4, 2010 8:55 am | |
| Ian Davis | Nov 4, 2010 8:57 am | |
| Ian Davis | Nov 4, 2010 9:06 am | |
| Bradley Allen | Nov 4, 2010 9:06 am | |
| Kingsley Idehen | Nov 4, 2010 9:10 am | |
| Ian Davis | Nov 4, 2010 9:13 am | |
| Kingsley Idehen | Nov 4, 2010 9:16 am | |
| bill...@planet.nl | Nov 4, 2010 9:20 am | |
| Ian Davis | Nov 4, 2010 9:22 am | |
| Bradley Allen | Nov 4, 2010 9:25 am | |
| Harry Halpin | Nov 4, 2010 9:33 am | |
| Robin YANG | Nov 4, 2010 9:51 am | |
| Ian Davis | Nov 4, 2010 9:54 am | |
| David Wood | Nov 4, 2010 9:56 am | |
| Mike Kelly | Nov 4, 2010 10:12 am | |
| Ian Davis | Nov 4, 2010 10:13 am | |
| Patrick Durusau | Nov 4, 2010 10:17 am | |
| David Wood | Nov 4, 2010 10:24 am | |
| Patrick Durusau | Nov 4, 2010 10:36 am | |
| Nathan | Nov 4, 2010 10:51 am | |
| Kingsley Idehen | Nov 4, 2010 11:06 am | |
| Nathan | Nov 4, 2010 11:07 am | |
| Patrick Durusau | Nov 4, 2010 11:08 am | |
| Ian Davis | Nov 4, 2010 11:18 am | |
| Ian Davis | Nov 4, 2010 11:24 am | |
| Robert Fuller | Nov 4, 2010 11:38 am | |
| Nathan | Nov 4, 2010 11:38 am | |
| Kingsley Idehen | Nov 4, 2010 11:41 am | |
| Jörn Hees | Nov 4, 2010 11:45 am | |
| Nathan | Nov 4, 2010 11:46 am | |
| Robert Fuller | Nov 4, 2010 11:48 am | |
| Ian Davis | Nov 4, 2010 11:58 am | |
| Kingsley Idehen | Nov 4, 2010 12:00 pm | |
| Harry Halpin | Nov 4, 2010 12:03 pm | |
| Kingsley Idehen | Nov 4, 2010 12:07 pm | |
| Jörn Hees | Nov 4, 2010 12:10 pm | |
| Kingsley Idehen | Nov 4, 2010 12:12 pm | |
| Kingsley Idehen | Nov 4, 2010 12:12 pm | |
| Kingsley Idehen | Nov 4, 2010 12:14 pm | |
| Nathan | Nov 4, 2010 12:26 pm | |
| Kingsley Idehen | Nov 4, 2010 12:36 pm | |
| David Wood | Nov 4, 2010 12:56 pm | |
| Hugh Glaser | Nov 4, 2010 12:59 pm | |
| 97 later messages | ||
| Subject: | Re: Is 303 really necessary? | |
|---|---|---|
| From: | Kingsley Idehen (kide...@openlinksw.com) | |
| Date: | Nov 4, 2010 7:59:50 am | |
| List: | org.w3.public-lod | |
On 11/4/10 10:22 AM, Ian Davis wrote:
On Thu, Nov 4, 2010 at 2:13 PM, Kingsley Idehen<kide...@openlinksw.com> wrote:
Ian,
Q: Is 303 really necessary?
A: Yes, it is.
Why? Read on...
I don't think you explain this in your email.
What's the problem with having many options re. mechanics for associating an HTTP based Entity Name with a Descriptor Resource Address?
Do you mean associate a resource with a description? Or do you mean something else? Can you rephrase using the terminology that everyone else uses please.
Who is everyone else? How about the fact that terminology that you presume to be common is actually uncommon across broader spectrum computing.
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?
We shouldn't be narrowing options for implementing the fundamental essence of Linked Data -- hypermedia based data representation. Of course, we can discuss and debate individual, product, or organization preferences etc.. But please lets not push these as mandates. We should never mandate that 303's are bad, never. Its an implementation detail, no more no less.
I'm suggesting that we relax a mandate to always use 303 and since you're saying we must not narrow options then you seem to be supporting my suggestion,
I didn't know there was a mandate to always use 303. Hence my comments.
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..
Ironically, bearing in mind my comments, we do arrive at the same conclusion, but in different ways. I phrase my conclusion as: heuristics for implementing HTTP based Entity Names that Resolve to structured Descriptor Resources shouldn't dominate the Linked Data narrative, especially as comprehension of the fundamental concept remains mercurial.
So are you contradicting your answer at the start of the post?
Huh?
I am saying, what I've already stated: heuristics re. essence of Linked Data mechanics shouldn't front the conversation. You sort of arrive there too, but we differ re. mandates.
Potential point of reconciliation:
You assumed that 303 is an existing mandate. I am totally unaware of any such mandate.
I don't even buy into HTTP scheme based Names as a mandate, they simply make the most sense courtesy of Web ubiquity. As is already the case re., LINK semantics [1], Hammer stack [2], and WebFinger [3], mailto: and acct: schemes work fine as Resolvable Names for Linked Data. In addition, XRD [4] also works fine as Descriptor Doc option.
To sum the broader picture up here: let's be inclusive rather than exclusive re. Linked Data.
Links:
1. http://tools.ietf.org/html/draft-nottingham-http-link-header-05 2. http://hueniverse.com/2009/11/the-discovery-protocol-stack-redux/ 3. http://webfinger.org/ 4. http://hueniverse.com/2009/03/the-discovery-protocol-stack/ .
--
Regards,
Kingsley Idehen
Ian
--
Regards,
Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen





