W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > February 2007

Re: [BioRDF] URI Resolution

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Fri, 02 Feb 2007 10:24:11 -0500
Message-ID: <45C3579B.8010404@musc.edu>
CC: public-semweb-lifesci <public-semweb-lifesci@w3.org>

> My overall comment: Yes!  I believe a URI resolution ontology could
> significantly help address these problems, while still permitting URIs
> to be based on the http scheme, thus facilitating bootstrapping and
> minimizing barriers to adoption.
I am very doubtful about the practicality of such an ontology. First, 
consider the size.  RDF is all about URI.  If an RDF document has n 
statement, there will be 3n URIs.  If k statements are needed to 
describe the resolution of one URI, the solution unnecessarily increased 
the KB k-fold.  Image the load for an RDF engine, the impact will be 
even bigger.  In theory, this seems O.K. but in practice, I have serious 

Unless, perhaps, you can describe the composition of URI - as a string.  
But, RDF is used to describe resource, which is identified a string.  
The meaning of these string should be specified "outside" of the 
system.  Just like URI specification is not a sub-specification of RDF.  
Even if you can succeed in doing so, though I am not clear how it can, 
the system ended up may be too complicated to be used.

Sometime, we need to strike a balance between a "complete" and a 
"reasonable" solution.  Especially, in software engineer field, we see 
the constant battle.  EJB vs. POJO and "specification" vs. 
"convention".  Most of the time, most of the practical and reasonable 
solution wins out.

In terms of URI's stability, I think what is important will always be 
taken care of. And so what is broken is not important and just let it 
be. As for our brain, forgetting isn't necessarily a bad thing.  Broken 
URIs will not necessarily a bad thing for the health of web either.  For 
me, it is more appropriate to discuss the problem in a social, but not 
technical, context.

Received on Friday, 2 February 2007 15:25:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:29 UTC