Re: Change Proposal for HttpRange-14

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

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

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


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen