W3C home > Mailing lists > Public > semantic-web@w3.org > March 2005

Re: SemWeb Non-Starter -- Distributed URI Discovery

From: Stephen Rhoads <rhoadsnyc@mac.com>
Date: Fri, 18 Mar 2005 21:11:54 -0500
Message-Id: <2677ae8be4e5a9a4dda26cd5dc53b051@mac.com>
To: semantic-web@w3.org

Giovanni,

When I refer to the concept of a "URI owner" or "URI authority" I am  
speaking about the Person, Organization or Entity that "minted" the  
URI.  In other words, someone, somewhere wanted to make statements  
about a "Concept" or "Thing" and felt it was important enough to mint a  
URI to represent that Thing or Concept.  Clearly, then, there ought to  
be some standard mechanism or facility whereby others can query the  
owner of the URI and discover what Concept or Thing it represents and  
what the owner of the URI cares to say about it.

Suppose I encounter,

ex:Stephen rdf:type    foaf:Person
ex:Stephen ex:wrote    http://www.sampledomain.org/TrickedOut
ex:wrote   rdfs:range  ex:WrittenWork

and I want to know what kind of WrittenWork  
"http://www.sampledomain.org/TrickedOut" is.  It could be a Book, an  
Article, a Poem ...

The only recourse is to either (a) crawl "http://www.sampledomain.org"  
with a spider and (hopefully) find an RDF Description of the URI  
therein, or (b) query the owner of the URI for a description.  I prefer  
that latter.

This is orthogonal to the problem you elude to in your Mozart example.   
A discussion about *which* URI within a set of available options will  
become generally accepted by the public for the purposes of making  
statements about the Thing or Concept represented by that (those)  
URI(s) is a separate topic.

So there are two problems here and I don't want for them to become  
confused.  This discussion is about how to query the  
minter/owner/authority of a URI for a description of that URI.

--- Stephen



On Mar 18, 2005, at 6:42 PM, Giovanni Tummarello wrote:

> I believe the biggest problem is the concept of "uri owner".
> While there are is clearly interesting use cases where querying the  
> "uri owner" in needed and or useful, there are probably more where  
> this makes not much sense.
> URI are not dereferenciable in general, just a very small subset is.  
> An even bigger problem is what one wants to refer to something that  
> doesnt have an "owner" using an in fact
> dereferencialbe URI, e.g. referring to Mozart using some  
> example.org/myfavouritemusicians/mozart#
> in this case how do you know he is really "the authoritative" ? what  
> about some other Mozart fan?
>
> Even if it was the authoritative then do you really want to know what  
> it has to say? of course yes, but will you get fair "reviews" for  
> example?
> One of the nice things of the SW if not the nicest is that in theory  
> anyone is entitled to talk about anything that has a uri. .. So a "uri  
> centric" query interface
> is inherently complicated, albeit very desirable ("i dont where it is  
> written, please tell me what do you know this") .
>
> [adv :-)]
> That is why we came out with RDFGrowth, an approach where your peer  
> will greedily collect all other people know about URIs that he is  
> interested into. [1]
> [/adv]
>
> About "SPARQL Protocol for RDF", yes it is meant to provide the  
> ability to ask a server about a URI, anyway if you want to test  
> something now i suggest nokia uriqa implementation
>
> Giovanni
>
> [1]  
> http://semedia.deit.univpm.it/submissions/ISWC2004_workshop_p2p/ 
> RDFGROWth_workshopISWC2004.pdf
>
>
> Stephen Rhoads wrote:
>
>> Until today, I considered myself to be squarely in the "slash" camp  
>> in the hash/slash debate.  Then something occurred to me which has  
>> got me all upset because it has serious implications for my project  
>> [1] -- which is inherently distributed in nature.
>>
>> As far as I can tell, there is no formal, generalized mechanism to  
>> reliably query the owner of a URI in order to obtain an RDF  
>> Description of that URI.  And this is a serious impediment to the  
>> Semantic Web.
>>
>> "hashing" at least gets you part of the way because -- given an HTTP  
>> URI containing a hash and frag ID -- it is *likely* that one can  
>> dereference the URI into a document containing (amongst other things)  
>> an RDF description of the URI in question.
>>
>> For example, if I encounter the URI
>>
>> http://www.somemediacompany.com/rdfdata/music/classical#resource
>>
>> chances are I can dereference  
>> “http://www.somemediacompany.com/rdfdata/music/classical” and find  
>> within that document an RDF description of “#resource”.
>>
>> If, one the other hand, I encounter
>>
>> http://www.somemediacompany.com/rdfdata/music/classical/resource
>>
>> then I can’t make any assumptions about whether or not this URI  
>> refers to some sort of document containing an RDF description of  
>> “resource”.  The URI owner may just have chosen to mint URIs using  
>> some logical hierarchy.
>>
>> So, given an arbitrary URI, how can I obtain an RDF Description of  
>> that URI?
>>
>> I suppose I could crawl the domain “containing” the URI with a spider  
>> and harvest RDF data until I find the description I’m looking for,  
>> but that’s a bit of a mess.  And it certainly doesn’t scale.
>>
>> I read up a bit on SPARQL -- particularly the "SPARQL Protocol for  
>> RDF" -- and, unless I'm misunderstanding, it seems to be the intended  
>> long term solution to the problem described herein.  Is that correct?  
>>  Is it expected that URI owner/minters will operate some sort of  
>> SPARQL server for providing RDF Descriptions of their URIs?  Will  
>> there be some convention as to the location of these servers such  
>> that one can *reliably* and automatically query for an RDF  
>> Description of a URI?
>>
>> Have I framed this problem correctly?  Are there solutions or angles  
>> which I have missed?  Input would be greatly appreciated.
>>
>> --- Stephen
>>
>> [1] http://www.dmmp.org (Digital Media Metadata Project)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Received on Saturday, 19 March 2005 02:12:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:45 UTC