Re: Change Proposal for HttpRange-14

On 27/03/2012 18:12, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> On 3/27/12 12:35 PM, Michael Smethurst wrote:
>> 
>> 
>> On 27/03/2012 16:53, "Kingsley Idehen"<kidehen@openlinksw.com>  wrote:
>> 
>>> On 3/27/12 11:17 AM, Michael Smethurst wrote:
>>>> No sane publisher trying to handle a decent amount of traffic is gonna
>>>> follow the dbpedia pattern of doing it in one step (conneg to 303) and
>>>> picking up 2 server hits per request. I've said here before that the
>>>> dbpedia
>>>> publishing pattern is an anti-pattern and shouldn't be encouraged
>>> Circa. 2006-2007, with Linked Data bootstrap via the LOD project as top
>>> priority, the goal was simple: unleash Linked Data in a manner that just
>>> worked. That meant catering for:
>>> 
>>> 1. frameworks and libraries that send hash URIs over the wire
>>> 2. work with all browsers, no excuses.
>>> 
>>> Linked Data is now alive and in broad use (contrary to many
>>> misconceptions to the contrary), there is still a need for slash URIs.
>>> This isn't a matter of encouragement or discouragement, its a case of
>>> what works for the project goals at hand. If slash URIs don't work then
>>> use hash URIs or vice versa. Platforms that conform to Linked Data meme
>>> principles should be able to handle these scenarios.
>>> 
>>> BTW - Imagine a scenario where Linked Data only worked with one style of
>>> URI, where would we be today or tomorrow, re. Linked Data? Being
>>> dexterous and unobtrusive has to be a celebrated feature rather than a
>>> point of perpetual distraction.
>> My point wasn't about hashes or slashes or any style of uri.
> Your comment was:
> 
> " No sane publisher trying to handle a decent amount of traffic is gonna
> follow the dbpedia pattern of doing it in one step (conneg to 303) and
> picking up 2 server hits per request."

Yes, but I was making a point about the one step, not the slashes or the 303
> 
> You described DBpedia method of doing things as being one to be
> discouraged. DBpedia deploys Linked Data via slash URIs, hence my
> response. Also, in the context of Linked Data slash URIs ultimately lead
> to the contentious 303 entity name / web resource address disambiguation
> heuristic.

But they don't have to lead to doing conneg and 303 in one step

>>   It was about
>> conflating 303s ((I can't give you that but) here's something that might be
>> useful) with conneg (here's the useful thing in the representation you asked
>> for).
> 
> 303 isn't a conflation of anything. It's a redirection mechanism that
> can be used in different ways. Sometimes it facilitates access to
> alternative representations and sometimes it can just be used to
> facilitate indirection re. "data access by name reference" as per Linked
> Data principles.

I didn't say 303 is a conflation. I said when you conflate the 303 part with
the conneg... that's a conflation.

I don't think it's 303s job to "facilitate access to alternative
representations"; that's what conneg's for

Dbpedia does:

Thing that's not a web document > conneg + 303 > representation of a web
document

Instead of:

Thing that's not a web document > 303 > resource uri for a web document >
conneg > representation of web document

If you do the latter then all html links can point to the resource uri of
the web document so the publisher still incurs a conneg cost for each
request (which is reasonable) but doesn't incur a 303 cost for every request
(which isn't). The only place you need to refer to the uri of the thing
that's not a web document is when you want to make statements about it

If you do the former then (as per dbpedia) you end up linking to the thing
that is not a web document and picking up a 303 penalty for every request

So I'm saying that you can do slashes and 303s but in way that's more
palatable to publishers than dbpedia

I still think there are other problems with 303s:
- some people who want to publish linked data just don't have access to
configure their server to do this (which would also be a problem for any new
20x response)
- persuading your manager and your manager's manager and your manager's
manager's manager (not to mention ops!) is not easy

But this is heading off topic so apologies

Michael
> 
> In the Linked Data system, you are seeking the description of an Entity
> that's been identified using a URI. If it so happens that the URI is
> hashless (or slash based) the system doesn't reply with an actual entity
> descriptor resource address, it redirects you. The very same thing
> happens with a hash URI but it has the benefit of delivering said
> indirection and disambiguation implicitly.
> 
> 
> There is always indirection in play. 303 isn't conflation, its simply
> redirection that is exploitable in a variety of ways.
>> And about how not exposing the generic IR URI and not linking to it
>> imposes too high a penalty
> 
> Here are the potential penalties, both ultimately about entity name /
> entity descriptor (description) resource address disambiguation:
> 
> 1. 303 round trip costs
> 2. agreement about which relations and constituent predicates provide
> agreed up semantics that address actual entity name / entity descriptor
> resource address ambiguity .
> 
> Here are some of the constituencies to which these potential costs apply:
> 
> 1. Web Page Publishers -- content publishers
> 2. Linked Data publishers -- structured data publishers
> 3. Web Page Consumers -- content consumers
> 4. Linked Data Consumers -- structured data consumers.
> 
> Expand the items above and you get an interesting cost vs benefits matrix.
> To cut a longish story short, if HTTP had a DESCRIBE method all of this
> confusion would vanish, pronto. Then you would have HTTP requests of the
> form:
> 
> DESCRIBE <http://dbpedia.org/resource/Linked_Data>
> and
> DESCRIBE <http://dbpedia.org/page/Linked_Data>
> 
> Net effect: an HTTP request could specifically return the relevant
> chunks of the description data that you seek. Today, the SPARQL protocol
> provides the next best thing.
>> Whether 303s are useful or not, there's a good and bad way to use them
> 
> As is the case with everything :-)
> 
> 
> Kingsley
> 
>> 
>> Cheers
>> micheel
>>> As is always the case, a good system must pass the "horses for courses"
>>> test. Linked Data -- courtesy of the underlying architecture of the
>>> World Wide Web -- does that with aplomb modulo the "distraction star"
>>> wanderings of planet HttpRange-14 into its solar system every so many
>>> months :-)
>> 
>> http://www.bbc.co.uk/
>> This e-mail (and any attachments) is confidential and may contain personal
>> views which are not the views of the BBC unless specifically stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in reliance
>> on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>> 
>> 
> 


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Wednesday, 28 March 2012 10:01:17 UTC