Re: Is 303 really necessary?

On 11/4/10 12:20 PM, bill.roberts@planet.nl wrote:
>
> Can I attempt to broker peace between Ian and Kingsley in this 
> discussion? :-)
>
> Because it seems to me that they are fundamentally agreeing with each 
> other, though considering different aspects of the problem.  Kingsley 
> is taking a very broad view, Ian is addressing a specific aspect of 
> best practices around Linked Data in the TimBL design 
> document/HTTP/RDF sense of the word.
>

Accurate. Very well spotted I must say :-)

>
> Whether it's a mandate or a best practice, it is clear to me that the 
> consensus of general guidance on the web around Linked Data advocates 
> the httpRange-14 distinction between 200/IR and 303/NIR(maybe) 
> approach.  So Ian's attempt to simplify this to make implementing a 
> best practice approach to Linked Data easier seems a worthwhile 
> discussion to have.
>

Yes, but see my comments (dropped a few minutes ago) re. statements made 
by Ian that are simply unhelpful. Example:

  @iand: seems that the lod mailing list is overwhelmingly supportive of 
**dropping** 303 redirects #linkeddata.

How did we arrive at that?

Where was the original mandate?
>
>
> On the broader scale of Linked Data, I broadly agree with Kingsley 
> that ultimately the technologies are less important than the concept. 
> But to implement it in practice, we need to apply at least one 
> technology, and the HTTP/RDF approach is currently the most widely 
> applied.
>
Yes-ish, but RDF a as moniker of comprehension is one-really-dead-Lazarus .

RDF was broken the day it left the station as being equivalent to 
RDF/XML. Conflating a Syntax and Semantics was an expensive snafu re. 
mind share assembly.

My one hope is that we veer away from opening up the door to FUD that 
simply exploits the age-old image problems of "RDF".

There is still a broader community of technically endowed practitioners 
in our industry that grok at least one of the following:

1. EAV
2. Graph Theory
3. Data Access
4. Data Management
5. Data Intergration
6. Distributed Object Management
7. Descriptions Logic
8. Logic in General.

None of the aforementioned individual profiles should find "Linked Data" 
confusing. It should be obvious.

Google has GData, Microsoft has OData, while Facebook has OpenGraph. Now 
we can burn cycles claiming they aren't RDF, or we can actually 
demonstrate separation of Syntax and Model by embracing all of these 
endeavors (i.e., start a conversation) and then lead each to its 
respective cul-de-sac (gently) as segue to unveiling the power of deeper 
Semantics as espoused RDF (model and associated syntaxes).
>
>
> I definitely agree with Ian that the 200/303 distinction is 
> complicated to explain to newcomers and adds an extra layer of effort 
> in implementing Linked Data. I'm convinced so far by Ian's argument 
> that the sky would not fall in if we return HTTP 200 together with 
> descriptions of real world things in response to an HTTP call to their 
> identifier.
>
My issue is with the mutual exclusion dimension. Why boolean OR when it 
should be about AND?

"Dropping" and "Mandates", don't reek of AND (inclusion) to me.

I am seeking inclusion and fundamental conceptual clarity. Let's kill 
off conflation driven confusion.

>
> After all, it's just a convention that we need to agree on regarding 
> how to deliver bits of documentation around the web.  I don't think it 
> changes any fundamental points about the semantics of RDF etc.
>

And I don't believe Cool URIs or any other suggestive document re. best 
practices is broken :-)

>
> To try to bring the discussion back to Ian's original point - are 
> there good reasons that force us to stick with the more complicated 
> 303 approach?
>
You were never forced to use 303. Ian has somehow jumped to that 
conclusion.

>   If not, then let's keep life simple and just return HTTP 200 for 
> HTTP URIs of real world things.
>

I don't think Ian is espousing that. On the other hand, I might have 
missed that point, thus if that's actually Ian's position, I completely 
disagree.


>
> Bill
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen