- From: Dan Brickley <danbri@danbri.org>
- Date: Wed, 09 Apr 2008 09:16:39 +0100
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Leo Sauermann <leo.sauermann@dfki.de>, www-tag@w3.org, SWIG <semantic-web@w3.org>
Pat Hayes wrote: > Nice document. A few quibbles: > > ------------ > > "When using 303 URIs for an ontology, like FOAF, network delay can > reduce a client's performance considerable." > > This sentence is not grammatical English. Rewrite to: > > When using 303 URIs for an ontology, like FOAF, network delay can > considerably reduce a client's performance. > > or: > > When using 303 URIs for an ontology, like FOAF, network delay can > reduce a client's performance to a considerable degree. > My apologies for not reviewing the document more carefully. It seems to be good stuff, but I missed this claim. And (as responsible party for FOAF ns) think this overstates the problem. Overstates it to a considerable degree, even. Clients can cache the 303 redirects, and the resulting URL's content can also be cached. For a small ontology of 5 or 6 terms, this involves 5 or 6 HTTP redirects plus the main fetch. All cachable. For modest sized ontologies like FOAF, with ~60 terms, it may be a slight nuisance, ... but let's keep it in perspective: loading a single Flickr page probably involves more HTTP traffic. And for massive ontologies, like the various wordnet representations, breaking them up into parts has its own merits: why download a description of 50000 classes just because you've encountered @yone. If somone has specific software engineering problems with a Web client for FOAF data that is suffering "to a considerable degree", please post your code and performance stats and let's have a look at fixing it. Maybe http://en.wikipedia.org/wiki/HTTP_pipelining is something we can get wired into a few more SemWeb crawling environments; for instance data as much as for schemas. cheers, Dan -- http://danbri.org/
Received on Wednesday, 9 April 2008 08:17:22 UTC