Re: Is 303 really necessary?

On 11/4/10 10:22 AM, Ian Davis wrote:
> On Thu, Nov 4, 2010 at 2:13 PM, Kingsley Idehen<kidehen@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

Received on Thursday, 4 November 2010 15:00:43 UTC