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

Re: Demo SPARQL notes

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 18 Apr 2007 02:17:28 +0100
Message-Id: <5BE06E3A-9DB7-4655-B260-7DB388BA322E@cs.man.ac.uk>
Cc: samwald@gmx.at, public-semweb-lifesci@w3.org
To: Bijan Parsia <bparsia@cs.man.ac.uk>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:47 GMT