On 11/19/10 5:57 PM, Nathan wrote:
Kingsley Idehen wrote:
On 11/19/10 4:55 PM, David Booth wrote:
On Fri, 2010-11-19 at 07:26 -0500, Kingsley Idehen wrote:
[ . . . ]
To conclude, I am saying:
1. No new HTTP response codes
2. Web Servers continue to return 200 OK for Document URLs
3. Linked Data Servers have option handle Name or Address
disambiguation using 303 redirection for slash URIs
4. Linked Data Servers have option to be like Web Servers i.e. do no
Name or Address disambiguation leaving Linked Data aware user agents
to understand the content of Description Documents
5. Linked Data aware User Agents handle Name or Address
disambiguation.
IMHO: when the dust settles, this is what it boils down to. On our
side, we're done re. 1-5 across our Linked Data server and client
functionality, as delivered by our products :-)
I think the above reflects reality, regardless of what is recommended,
because:
- some Linked Data Servers *will* serve RDF with 200 response
codes via
slash URIs, regardless of what is recommended;
- some User Agents *will* still try to use that data;
- those User Agents may or may not care about the ambiguity
between the
toucan and its web page;
- those that do care will use whatever heuristics they have to
disambiguate, and the heuristic of ignoring the 200 response code is
very pragmatic.
David,
Great! We're going to point back to this post repeatedly in the
future :-)
I truly hope not, recognizing that some people *will* do whatever the
hell they please, doesn't make what they're doing a good idea, or
something that should be accepted as best / standard practise.
I am not implying that :-)
I am trying to say that 1-5 represent the landscape, and solutions
simply operate within that reality. Next time these matters arise we can
save time returning to 1-5.
As David mentioned earlier, having two ways to do things is already
bad enough (hash/303) without introducing a third.
There will always be many ways to skin a rat, Linked Data can't stop
that reality.
There's already been half a decade of problems/ambiguity/nuisance
because of the httpRange-14 resolution, ranging from technical to
community and via conceptual, why on earth would we want to compound
that by returning to the messy state that prompted the range-14 issue
in the first place?
I don't see how I am advocating that. There are no mandates in 1-5,
again that outlines how things are. Server, Servers and User Agents, or
User Agents can make decisions.
Fact is, the current reality is primarily due to the fact there is so
much confusion with no single clear message coming through, and until
that happens the future reality is only likely to get messier.
It won't get any messier since 1-5 simply implies that there isn't
anything to change re. HTTP response codes. Developers should make
choices and live with the consequences, as they do every day :-)
Best,
Nathan
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
