- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 18 Apr 2007 02:17:28 +0100
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: samwald@gmx.at, public-semweb-lifesci@w3.org
On Apr 18, 2007, at 1:35 AM, Bijan Parsia wrote: > On Apr 17, 2007, at 7:28 PM, samwald@gmx.at wrote: [snip] >> e.g. for an ontology containing around 200.000 triples, would it >> be possible to run a webserver that uses this approach to answer >> concurrent queries of dozens of users without excessive lag? > > # of triples is an exceedingly crude measure that really doesn't > give me enough info so say. But I think that, with compromise and > tuning, there are plenty of ontologies that fit this scenario that > could be made to work on reasonable server hardware. You'd want > help in a lot of cases, but it's not out of reach by any means. [snip] Partially in response to a message from Alan Ruttenberg off list, let me be even clearer: I think *if the ontology classifies reasonably at all*, then this sort of query approach can achieve reasonable performance for this rough application profile with a reasonable amount of engineering effort in many cases. That is, it doesn't necessarily kill you to query about the parents (or children, or ancestors) of an arbitrary (but reasonable) class expression even without specific incremental reasoning support. Obviously this is a vaguely expressed optimism, but then the requirements I've gotten thus far are vague too :) To temper the optimism, I'll point out that it shouldn't be *that* hard to construct a 10000 triple ontology with 100 triple class queries that would kill us. Cheers, Bijan.
Received on Wednesday, 18 April 2007 01:17:39 UTC