W3C home > Mailing lists > Public > public-swd-wg@w3.org > September 2007

Re: [ALL] Review requested for "Cool URIs"

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 24 Sep 2007 20:39:09 +0200
Message-ID: <46F8044D.7040008@few.vu.nl>
To: "Novacek, Vit" <vit.novacek@deri.org>
CC: Thomas Baker <baker@sub.uni-goettingen.de>, SWD Working Group <public-swd-wg@w3.org>

Hi Vit,

A question on your comment below:
> Consider for instance Gene Ontology (GO in the following text), which is being monthly updated in many formats, RDF/XML being one of them [2]. According to the requirement number 1 of the document under review, every resource identifiable by a URI should be on the web. But it is not very clear how to actually publish all resources GO contains following any of the strategies presented in the document. As stated in the Conclusion frame in Section 4.3, the hash URI strategy is not appropriate for GO, since its RDF/XML serialisation has currently about 30MB. It is definitely neither "rather small", nor "stable" (changes may occur every month). So, should we use the 303 URI approach? Possibly yes, but this would mean that we should establish and regularly maintain tens of thousands of different URIs for every resource represented in GO, each of this URIs representing generally very small piece of information (since the GO descriptions are usually rather shallow). It is questionable whether such approach is either reasonable or practical... Maybe we could combine both approaches, which is one of the possibilities mentioned in Section 4.3 as well. However, it is not very clear from the document, how we should actually combine the two approaches in order to deal with situations similar to this "GO problem" optimally. 

I think the 303 solution redirecting to some specific query to a SPARQL 
endpoint (which is described in D2R server in section 5) would make the 
redirection of tens of thousands URIs without too much harm, wouldn't 
it? Or do you envision other problems?


Received on Monday, 24 September 2007 18:39:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:45 UTC