atom feed151 messages in org.w3.public-lodRe: Is 303 really necessary?
FromSent OnAttachments
Ian DavisNov 4, 2010 6:21 am 
Kingsley IdehenNov 4, 2010 7:13 am 
Ian DavisNov 4, 2010 7:22 am 
Kingsley IdehenNov 4, 2010 7:59 am 
Giovanni TummarelloNov 4, 2010 8:20 am 
Ian DavisNov 4, 2010 8:22 am 
Ian DavisNov 4, 2010 8:27 am 
Leigh DoddsNov 4, 2010 8:38 am 
William WaitesNov 4, 2010 8:43 am 
Giovanni TummarelloNov 4, 2010 8:50 am 
Leigh DoddsNov 4, 2010 8:53 am 
Kingsley IdehenNov 4, 2010 8:55 am 
Ian DavisNov 4, 2010 8:57 am 
Ian DavisNov 4, 2010 9:06 am 
Bradley AllenNov 4, 2010 9:06 am 
Kingsley IdehenNov 4, 2010 9:10 am 
Ian DavisNov 4, 2010 9:13 am 
Kingsley IdehenNov 4, 2010 9:16 am 
bill...@planet.nlNov 4, 2010 9:20 am 
Ian DavisNov 4, 2010 9:22 am 
Bradley AllenNov 4, 2010 9:25 am 
Harry HalpinNov 4, 2010 9:33 am 
Robin YANGNov 4, 2010 9:51 am 
Ian DavisNov 4, 2010 9:54 am 
David WoodNov 4, 2010 9:56 am 
Mike KellyNov 4, 2010 10:12 am 
Ian DavisNov 4, 2010 10:13 am 
Patrick DurusauNov 4, 2010 10:17 am 
David WoodNov 4, 2010 10:24 am 
Patrick DurusauNov 4, 2010 10:36 am 
NathanNov 4, 2010 10:51 am 
Kingsley IdehenNov 4, 2010 11:06 am 
NathanNov 4, 2010 11:07 am 
Patrick DurusauNov 4, 2010 11:08 am 
Ian DavisNov 4, 2010 11:18 am 
Ian DavisNov 4, 2010 11:24 am 
Robert FullerNov 4, 2010 11:38 am 
114 later messages
Subject:Re: Is 303 really necessary?
From:Kingsley Idehen (kide@openlinksw.com)
Date:Nov 4, 2010 8:55:48 am
List:org.w3.public-lod

On 11/4/10 11:23 AM, Ian Davis wrote:

On Thu, Nov 4, 2010 at 3:00 PM, Kingsley Idehen<kide@openlinksw.com> wrote:

On 11/4/10 10:22 AM, Ian Davis wrote:

On Thu, Nov 4, 2010 at 2:13 PM, Kingsley Idehen<kide@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.

Again, you presume. Capitalization might not work for you, but you are not the equivalent of an entire mailing list audience. You are one individual entitled to a personal opinion and preferences.

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.

I don't believe its already at the front. I can understand if there was some quasi mandate that put it at the front. Again, you are jumping to conclusions, then pivoting off the conclusions to make a point. IMHO: Net effect, Linked Data concept murkiness and distraction. You are inadvertently perpetuating a misconception.

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.

Please provide a URL for the document that establishes this mandate. I know of no such document. Of course I am aware of documents that offer suggestions and best practice style guidelines.

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

That is a Name via HTTP URI (using its Name aspect).

That is the Address of a Resource (URL) that carries structured representation of the unambiguously named entity: <http://dbpedia.org/resource/Paris> .

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

Your resource is not my resource. In my world you have:

1. Referent 2. Identifier 3. Resource.

A trinity that delivers Subject Sense (capitalization deliberate).

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.

See comment above:

1. Paris -- Referent 2. <http://dbpedia.org/resource/Paris> -- Identifier used for Name 3. <http://dbpedia.org/page/Paris> -- Address of an actual Web Resource that carries the description of Paris.

Again, in my world there exists a trinity. In short, if you look back at the history of how "Resource" made it into URI you will see that TimBL did try to fix this anomaly [1], without success.

As you can see, oveloading of Resource simply confuses matters, especially when talking to a broader pool of people that have long understood these matters prior to the fusion of hypermedia with the internet aka. World Wide Web fo HTML Documents.

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.

Of course, my comments are irrelevant, off topic. If that works for you, then good for you. You spent all this time debating an irrelevance.

FWIW - 303 is an implementation detail, RDF is an implementation detail, and so is SPARQL. When you front line any conversation about the concept of Linked Data with any of the aforementioned, you are only going to make the core concept incomprehensible.

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.

Of course its irrelevant to you. But it isn't irrelevant to the real point: how you make resolvable names, and what's the mandated approach?

The concept of Linked Data is what I am fundamentally interested in. And I don't want that concept to be lost in distractions such as:

1. RDF 2. URI Schemes 3. Resolvable Name Mechanics (e.g. 303, SPARQL etc..).

I want to be able to have simple conversations about the concept of Linked Data, supported by examples that compute, and move on etc..

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.

See comments above. I kinda read and write ahead.

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.

You are 100% entitled to your personal opinions, 100% of the time. Don't start a conversation in a public space, that you don't own, if you aren't ready to entertain broad commentary.

Links:

1. http://lists.w3.org/Archives/Public/www-tag/2009Aug/0000.html -- The History of Resource in URI TimBL

Kingsley

Regards,