On Apr 18, 2007, at 1:35 AM, Bijan Parsia wrote:
On Apr 17, 2007, at 7:28 PM, [EMAIL PROTECTED] 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.
