Re: Change Proposal for HttpRange-14

Tue, 27 Mar 2012 10:14:51 -0700 

On 3/27/12 12:35 PM, Michael Smethurst wrote:



On 27/03/2012 16:53, "Kingsley Idehen"<kide...@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









Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature



























					Reply via email to