- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 03 Apr 2012 07:47:40 -0400
- To: www-tag@w3.org
- Message-ID: <4F7AE35C.30007@openlinksw.com>
On 4/2/12 11:27 PM, Larry Masinter wrote: > I think it really leads you down the wrong path to talk about first > minting the URI and then putting something out there that explains > what you meant by it. Possibly, and I don't particular espouse that kind of narrative. Re. DBpedia I was simply explaining to you that cases exist where the goal of publishing Linked Data triggers the construction of re-write rules that is basically a URI minting process. Beyond DBpedia, we even do more of this "on the fly" via our URIBurner [1] service. > I know thats what people WANT to think, but it leads you to imagine > that a URI could have two senses, one the "natural", undocumented > sense, and another the sense which appears when you put up the > description (and disappears when the server goes down for the last time). From a functional narrative perspective, I look at all of this as being akin to DBMS functionality where the DBMS system (Linked Data Server) generates keys. End-users aren't actually exposed to the lower level mechanics and model implications. > > You can avoid this fallacy merely by being more careful about the > order. Your dbpedia server arranges its state so that subsequent later > requests for a URI will (DNS and Apache willing) result in some results. We don't use Apache. We use Virtuoso [2] which is a full blown Linked Data server. Producing and managing keys is native functionality. > But the URI choice is constrained almost completely by the server > configuration, DNS, available protocols, etc. Yes, that's part of the linked data server functionality in our case. The re-write rules reference was all about the underlying mechanism that drives the system. It also leverages SPARQL since the end game is basically about transient and persistent (or materialized) views endowed with functional keys that resolve to descriptions expressed in 3-tuple form etc.. In the case of DBpedia, we have a sorta hybrid natural keys style of identifier since we also want end-users to easily triangulate back to Wikipedia resource URLs. > > You can change the case of the host, add or omit the port, perhaps hex > encode some characters or even do Unicode normalization and get the > same behavior. > > If you are depending on the web behavior to establish meaning, then > all of those spellings should mean the same thing. URIs simply identify data objects that are represented in 3-tuple based graph pictorial form. Our keys are mapped to actual SPARQL DESCRIBE (or in extreme cases CONSTRUCT) queries. We basically use the SPARQL protocol to compensate for HTTPs non existent DESCRIBE method. > > If you are not, if the web behavior of the URI is just advisory and > you could use http://example.com and HTTP://eXAMplE.com:80 > <http://eXAMplE.com:80>/ to meam different things, then why bother > setting up a server at all? It isn't advisory. We are exposing a Web scale DBMS that leverages URIs and structured data representation . DBpedia and URIBurner instances are examples of what a Linked Data and conventional DBMS combo can deliver. Identifiers are integral to databases (intensional, extensional, or hybrid variants). "In a relational database, we never record information about something we cannot identify." -- C.J. Date Links: 1. http://uriburner.com -- a service that describes Web resources via dynamically generated Linked Data graphs 2. http://virtuoso.openlinksw.com -- Virtuoso home page. Kingsley > > /Connected by DROID on Verizon Wireless/ > > > -----Original message----- > > *From: *Kingsley Idehen <kidehen@openlinksw.com>* > To: *"www-tag@w3.org" <www-tag@w3.org>* > Sent: *Mon, Apr 2, 2012 16:00:02 GMT+00:00* > Subject: *Re: A Dirk and Ndia story about RDF and URIs and HTTPrange14 > > On 4/2/12 9:06 AM, Larry Masinter wrote: > > I said > >> There are no "owners" of URIs here. > >> There is no process of "mint" here. > >> There is no notion of "resource" and "representation" here. > >> There's no need to talk about two resources being the "same", > or using "different" URIs for the "same" resource. > >> There's no separation of "information resource" vs. "general > resource". > > ... to which I got some use cases where these terms, processes, > distinctions might make sense. > > > > But by "here" I meant "in my story ". I am not denying there > are circumstances where you would naturally like to use that > terminology, but rather that there are enough use cases where the > those terms and distinctions do not make sense, and it isn't > necessary to reference those concepts. > > > > So spare me the use cases where you think "mint" makes sense, > where you can argue that there is someone who really does seem to > "own" a URI, where there is a clear distinction between "resource" > and "representation", etc. > > > > Larry > > > > > > > When publishing Linked Data via a Linked Data oriented server. > > DBpedia is a live example. The server is *minting* URIs to serve a > very > specific purpose :-) > > -- > > Regards, > > Kingsley Idehen > Founder& CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > <http://www.openlinksw.com/blog/%7Ekidehen> > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > -- 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, 3 April 2012 11:48:09 UTC