Re: Sparql endpoints +1

Matthias Samwald wrote:
> *) Most of the entities that have URIs on the Semantic Web are not 
> documents, rather they are entities in the real world that cannot be 
> 'resolved' in any meaningful way. What people mean when they talk about 
> 'resolving' such non-information-entities is in fact the process of 
> getting RDF triples that have the URI as subject, object or maybe predicate.

...or just getting some human-readable information, better than nothing!


> *) Existing resources on the Semantic Web should be re-used where 
> possible. However, we can observe that most projects tend to mint new 
> URIs and create new resources rather than re-using equivalent resources 
> from other ontologies. The two main reasons for this seem to be
> 
>   - purely cosmetical: The URI that has already been minted in another 
> ontology does not 'look good', for example because it contains the 
> server name of another group.

The problem I see is that almost none of the databases provide official, 
proper URIs for their resources. So each project ends up generating their 
own. And why should I use your unofficial URIs over my unofficial URIs?

Now if a database does provide usable URIs, there should be no excuse to 
not use those (hint, hint :-), or if you do want to have your own URIs, it 
should be your responsibility for providing a mapping to the official URIs.


>   - ontological: Importing the other ontology would mean polluting our 
> own ontology with statements that we do not need or agree with. Rather 
> than bothering with that just in order to re-use some of the resources 
> in that ontology, we mint our own URI and define a redundant entity.

Another issue here is that you don't want to end up in namespace hell, 
though I guess that wouldn't preclude having some owl:sameAs' somewhere...


> *) The majority of the web pages we see through our browsers have been 
> created dynamically, mostly through PHP scripts or other server-side 
> scripting languages. Static HTML pages have become relatively rare, and 
> even the cheapest webspace provider offers PHP and MySQL support. But 
> for some reason, most of the proposals for serving RDF on the web ignore 
> this situation and are based on static RDF files, either as large sets 
> of small files or small sets of large files. This seems a bit 
> unwarranted to me.
> 
> *) Sparql is one of the best developments in the Semantic Web area so 
> far. Almost everyone likes Sparql, or at least thinks that it is of 
> utmost importance (ok, there are exceptions). Sparql allows us to pull 
> very specific statements out of very large triple stores that are housed 
> on a server. Discovering these statements in a conglomerate of tiny RDF 
> files, or downloading a big chunk of RDF just to query it for a few 
> statements on the client-side, are far less efficient in comparison.

Hosting a Sparql endpoint is still a lot less trivial (i.e. it is a big 
challenge, especially if your database is large) than exposing your data as 
"static" documents. I think latter is the most you can expect of most 
database providers. But perhaps there will be some Semantic Web crawlers 
that will retrieve and make such data available through Sparql endpoints!

Received on Friday, 13 July 2007 14:01:11 UTC