W3C home > Mailing lists > Public > semantic-web@w3.org > November 2005

Re: A vision about a Semantic Web Search&Reasoning Engine

From: Bjoern Hoehne <semantic-web@lists.unreach.net>
Date: Fri, 25 Nov 2005 20:18:52 +0100
To: Danny Ayers <danny.ayers@gmail.com>
CC: semantic-web@w3.org
Message-ID: <438771AC.19469.5C6F3E@localhost>

Dear Danny,

first I want to thank you for input.

On 25 Nov 2005 at 13:37, Danny Ayers wrote:

> The other hard parts I suspect will be scale and performance (fairly
> safe prediction ;-). Making the system have a distributed architecture
> from the ground up is probably a good idea, if possible.
Everything except searching the result tree (a database generated RDF Graph with a 
subset of triplets which should contain one or more results for the user query) is 
actually planned as distributed/distributeable component. This is planned to be just a 
small research project - but we want to be flexible if it will come to great success :o)

> Loosely-couple components, and all that. One Web-friendly approach
> might be for the service to rewrite the search terms as SPARQL
> queries, push those on to both local and remote stores (hosted by
> whoever - maybe Swoogle would be a good candidate, and how about
> individual PiggyBanks..?) and then use the reasoning engine to make
> something cohesive from the results.  Keying in to other data stores
> should also reduce the amount of work you have to do ;-)
Very good point.

> Another avenue to dealing with the scale/performance issues may be to
> support delayed results. i.e. I go query the system, it tells me what
> it knows *now*, but also sets async queries in action with remote
> systems. When they've got more results they pass these back to the
> centre (maybe via callback URIs). Revisiting the query site
> seconds/months later and asking the same question again (or following
> a link provided by the system) reveals the additional info.
Another good point. When extrapolating the current performance of (prototype)
search (for relevant triplets in the store) reasoning (with those triplets) and 
re-reseach (the final graph for good results) results are feasible within 10 - 50 
seconds - depending on the query. As we cannot expect a user waiting 50 seconds in 
front of a blank browser window the current idea is:
* Take the search terms from the user
* Lookup them in the Ressource Store containing known URI-Refs (searching 
rdf:label Literals, too and matching them to the paricular URIRef)
*show the user the resulting ressources (with some extra information like rdf:label 
and some hierarchy information)
*show the user a link where he could get more detailed information and truely 
reasoned and searched answers (with a hint, that the complete processing of his 
query may take a while)

Do you think this is passable and answers "normal" users in a satisfactoy manner? (I 
think we will need some marketing specialists who can exemplify the waiting user 
why it takes so long.....


Cheers from snowy Germany

     Björn
Received on Friday, 25 November 2005 19:19:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:48 UTC