On 11/4/10 12:20 PM, [email protected] 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
