- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 20 Nov 2012 10:05:48 -0500
- To: public-webid@w3.org
- Message-ID: <50AB9C4C.9060700@openlinksw.com>
On 11/20/12 9:11 AM, Henry Story wrote: > > On 20 Nov 2012, at 00:36, Stéphane Corlosquet <scorlosquet@gmail.com > <mailto:scorlosquet@gmail.com>> wrote: > >> I don't deny the fact that hash URIs have their advantages and I >> personally prefer them too for WebID, but I don't see the need to set >> that in stone wrt to WebID URIs. Like I said before, who knows what >> new mechanism will come out of the TAG or elsewhere 2 years down the >> road? Mandating hash URIs means that any kind of innovation in the >> realm of WebID will be impossible without breaking the spec. >> >> Can't we agree on the following compromise? => only use hash URIs in >> the non-nominative examples. This is leave for innovation down the >> road, in the meantime most people can follow the hash routes unless >> they prefer some other way. >> >> Does mandating "hash URIs only" provide any advantage in terms of >> implementing a WebID verifier? A verifier would still rely on HTTP to >> dereference the WebID URI, and follow any redirect if necessary. What >> are the advantages from a verifier standpoint? How does it make is >> simpler than just any kind of URI? > > I think Tim Berners Lee had a number of objections on the of tracking > 303 redirected URIs. He said it massively slowed down the Tabulator code. The issues aren't new. Now to TimBL's credit (please note what follows carefully) he pointed out the issues and implementation challenges. At no point did he imply a mandate to make this part of the WebID definition. Again, he explained his concerns backed up with specific experience with Tabulator. > > It also makes our explanation more complex in the explanation in the spec. It doesn't. Is TimBL's Linked Data meme more complex? Is DBpedia more complex? http://dbpedia.org/resource/Linked_Data is the HTTP URI that denotes the concept 'Linked Data' . http://dbpedia.org/page/Linked_Data is the HTTP URI that denotes the document that describes the concept 'Linked Data'. You can bookmark either URI and end up with the same document comprised of content that describes the concept 'Linked Data' . > > As I see we all have consensus that #uri are WebIDs, and there is lack > of consensus on whether > 303s non has uris should also be. Untrue. When did you actually poll the participants in this project. Why not run a poll right now so that a broad audience of Linked Data savvy folks can participate? > The new principle has to be: wherever we can make things simpler we do > so - as long as we don't close options further down. That's a contradictory statement. This isn't what you are doing right now by pushing this effort. I understand where TimBL is coming from, I understand how HTTP URI denoting real world entities got mucked up etc.. The trouble is there has been consensus within the W3C re. HTTP URIs . The cat is out of the bag and we can't use this effort to simply add more problems down the line. Hashless URIs are in broad use re. Linked Data, simply look at the LOD cloud. Do you seriously want to consider dislocating the LOD cloud from this endeavor? If you are unclear re. the last sentence it means: Facebook doesn't become a nice Linked Data source (data space) for exploitation via WebID over TLS. > By defining WebIDs to be just #uris, we don't close options further > down, and we leave it to other people who want to join to make their > case when we go to W3C WG. What a waste of time. They join the WG to start debating instead of enjoying the euphoria of compatibility via dexterous architecture. Come on now! > > The idea is make it simple for people to join. No, the idea is to stay true to the "deceptive simple" principle that makes the Web what it is. > > My problem with 303's vocabs such as foaf is that you don't know when > a uri is defined in a document > until you dereference each URI. For example each of > > http://xmlns.com/foaf/0.1/knows > http://xmlns.com/foaf/0.1/mbox > http://xmlns.com/foaf/0.1/Person > http://xmlns.com/foaf/0.1/Agent > > Are all defined by the > > http://xmlns.com/foaf/spec/ > > but you don't know that until you have done an HTTP GET for each of > those resources. You seek and find knowledge. Basically, the act of dereferencing an identifier that denotes something. Knowledge doesn't have to be presumptuous. > This is important because understanding which document is defining a > term, is key to > WebID-TLS authentication. No, the entity relationship semantics from the retrieved profile graph is what's important. > A document that defines a term is making something close > to a necessarily true assertion, as you know from mathematics. I don't think that's relevant at all. The authentication protocol is about machine and human comprehensible entity relationship semantics and the logical reasoning they facilitate. > > That means that even though you may already have fetched all the foaf > definitions, > you still have to interact with the server to find out if you have the > definitions. We are using HTTP URIs. Cache invalidation is baked into HTTP. > > Notice the security hole that breaks up if you are not careful otherwise: > > I create a WebID+ for </ppl/joe> > this redirects to > > /ppl > > which describes ( and seems to define) also > > </ppl/smith> > </people/smith> > You can know imagine a server implementing WebID protocol badly that > on the > authentication of /people/smith thinks it already has the definition > for that WebID in > store... Anything can be implemented badly. You know that. A spec isn't supposed to teach engineering. > > There are a lot of things that end up needing explanation suddenly > which we can > cut out by keeping our definition rigorously simple. HTTP URI is "deceptively simple" enough, if it wasn't then why didn't TimBL mandate hash style of HTTP URIs when minting the LInked Data meme? Kingsley > > Henry > >> >> Steph. >> >> On Mon, Nov 19, 2012 at 6:16 PM, Melvin Carvalho >> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote: >> >> >> >> On 19 November 2012 23:58, Kingsley Idehen >> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: >> >> All, >> >> To understand this old problem please read: >> http://www.w3.org/TR/2007/WD-cooluris-20071217/#hashuri . >> >> Important point to note, this matter ultimately becomes a >> permathread whenever a spec attempts to pick one style over >> the other. >> >> The solution to these kinds of problems stem back to biblical >> stories, such as the one illustrating the wisdom of Solomon >> re. splitting a disputed baby in half. >> >> HTTP URIs are "horses for course" compliant. It is always >> best to keep them that way when designing specs for HTTP >> based solutions. >> >> >> Thanks >> >> "Conclusion. >> Hash URIs should be preferred for rather small and stable >> sets of resources that evolve together. An ideal case are RDF >> Schema vocabularies and OWL ontologies, where the terms are >> often used together, and the number of terms is unlikely to >> grow much in the future. >> >> Hash URIs without content negotiation can be implemented by >> simply uploading static RDF files to a Web server, without >> any special server configuration. This makes them popular for >> quick-and-dirty RDF publication. >> >> 303 URIs should be used for large sets of data that are, or >> may grow, beyond the point where it is practical to serve all >> related resources in a single document. >> >> If in doubt, it's better to use the more flexible 303 URI >> approach. >> >> " >> >> Will try and digest this a bit more. I may still be missing >> something but if you have a paradigm of one data item per page >> and call it #, like facebook do, I'm still trying to see the >> advantage of 303s. As pointed out, facebook is not a small data >> set. >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> <http://www.openlinksw.com/> >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> <http://www.openlinksw.com/blog/%7Ekidehen> >> Twitter/Identi.ca <http://Identi.ca> handle: @kidehen >> Google+ Profile: >> https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> >> >> >> >> >> -- >> Steph. > > Social Web Architect > http://bblfish.net/ > -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 20 November 2012 15:06:17 UTC