Re: BobQL? Boxes of (related) boxes ...

Dan,

The general model for what you are trying to describe is practically the 
underlying model we propose in Explorator, which can be expressed in our 
proposed "SPO" operator (see 
http://events.linkeddata.org/ldow2009/papers/ldow2009_paper2.pdf).
There are a couple of potential "boxes" (thanks for the metaphor, sounds 
very much like Explorator's interface ;-) ) that you could add, which 
can mix "straight" navigation with set-based navigation (which is not 
the same as faceted navigation, btw) and "strict" faceted navigation:

Dan Brickley wrote:
> ...
> Box 2: A journey into info about hong kong skyscrapers, their 
> designers, and the buildings those designers have made
> box 2.1: All things that are skyscrapers in Hong Kong
> box 2.2: All things that are the architects of things in bag 2.1
2.2a - All things that are the architects of a subset of things in bag 2.1
> box 2.3: All things that are buildings designed by things that are in 
> bag 2.2 ...etc
2.3.1 - All things are buildings designed by one architect that is in bag 2.

and so on...
>
> Note: each sub-box is an RDFesque expression couched in terms of types 
> and relations, with a reference to the set of things handed along from 
> the previously box. In theory each of these could also evaluated with 
> different "according to..." criteria, which could map into SPARQL 
> GRAPH provenance, different databases, or various other ways of 
> indicating who-said-what. Also note that the class hierarchies beloved 
> of OWL enthusiasts is potentially useful here: if a trail goes cold, 
> eg. because you only find 3 or 4 things that are schools of kids of 
> presidents, you could explore higher up the class hierarchy in one of 
> these expression ("Not much found. Try Politician instead of US 
> President? Try Educational Institution instead of School?")...
In our experience, there are actually two sets of underlying SPARQL 
queries - those that are required to compute the desired information 
(call this the abstract browsing operation), and those that are required 
to RENDER these results in a user-friendly (meaningful) way.
We have found that this second set is actually a major hurdle for 
providing performing interfaces, especially over public SPARQL endpoints 
(some of these were well outlined in Andrea's earlier message).

In addition, as you seem to hint, these "voyages" could be 
parameterized, so that they can be "replayed" for different instances 
(coming up in the next version of Explorator, hopefully by the end of 
(northern hemisphere) summer.

I'm not sure that proposing a standard "higher level" model would be the 
best way to go, rather than making sure we can implement them in SPARQL 
in an efficient way. Again, Andreas already pointed at some important 
features, such as decent full text search... which is really not trivial 
to standardize in a truly "general" way (ie, not only to suit our needs).

Received on Sunday, 31 May 2009 22:17:46 UTC