Re: Is 303 really necessary?

On Thu, Nov 4, 2010 at 3:00 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 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.
>

I don't presume. I prefer to use terms that are familiar with the
people on this list who might be reading the message. Introducing
unnecessary capitalised phrases distracts from the message.


> 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?

It's already at the front, and as I say in my post it's an impediment
to using Linked Data by mainstream developers. This is an
implementation detail that I think could do with improving, making it
simpler and in fact removing it from the front of the "narrative". It
just becomes like commonplace web publishing. Do you agree that's a
good goal to strive for?

>
>
>>> 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.

There is. I find it surprising that you're unaware of it because it's
in all the primary documents about publishing Linked Data.


>>>
>>> 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..

Not sure what you are trying to say here. I must be misunderstanding
because you appear to be claiming that
<http://dbpedia.org/resource/Paris> is a name but
<http://dbpedia.org/page/Paris> is a resource.

Assuming you are using angle brackets like they are used in Turtle
then I think they are both resources.

I would say:

<http://dbpedia.org/resource/Paris> -- a resource named by the string
"http://dbpedia.org/resource/Paris"
<http://dbpedia.org/page/Paris> -- a resource named by the string
"http://dbpedia.org/page/Paris"

Also, in my view the first resource is actually the city of paris
whereas the second is a document about the first resource.

I don't really see what relevance this all has to the issue of 303
redirection though. We are all agreed that things are not usually
their own descriptions, we are discussing how that knowledge should be
conveyed using Linked Data.


>>
>>> 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.

See my  comment above: I am removing them from the front.

>
> Potential point of reconciliation:
>
> You assumed that 303 is an existing mandate. I am totally unaware of any
> such mandate.

See above.

>
> 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.

This is an irrelevant point because 303 redirection only applies to
HTTP. So if you're not using HTTP then it doesn't apply to you and you
can ignore my post. I'm not sure why you bring this up in your
comments.

>
> To sum the broader picture up here: let's be inclusive rather than exclusive
> re. Linked Data.
>

I'm not disagreeing, but I don't see what that statement adds to the debate.

Ian

>
> 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:23:48 UTC