W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

Re: A Dirk and Ndia story about RDF and URIs and HTTPrange14

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 03 Apr 2012 07:47:40 -0400
Message-ID: <4F7AE35C.30007@openlinksw.com>
To: www-tag@w3.org
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






Received on Tuesday, 3 April 2012 11:48:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC