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

Dan Brickley wrote:
> (I changed subject line again, sorry but to avoid misleaing further :)
>
> OK, you goaded me into writing up what I was thinking about...
>
> On 31/5/09 21:09, Andreas Harth wrote:
>> Hi,
>>
>> Dan Brickley wrote:
>>> Basic idea in a nutshell is that SPARQL is great for data access, but
>>> there may be additional query-oriented data structures worth spec'ing
>>> based around the set-oriented navigation very nicely articulated by
>>> David Huynh in the Parallax screencast. And that if such a structure
>>> could be exchanged between systems we could hope that the navigational
>>> paradigm it supports could be found in various concrete UIs, and that
>>> the results of exploring data this way could become useful and
>>> standard artifacts in the public Web, rather than just bookmarks
>>> within some specific system.
>>
>> there's at least two issues with using standard SPARQL endpoints
>> in a faceted browsing system (as far as I can see from my experiements
>> with SWSE and VisiNav):
>>
>> * A lot of end-user systems for RDF data navigation offer keyword
>> search, which is not in standard SPARQL. Emulating fulltext search
>> with SPARQL regex's seems suboptimal. Using endpoint-specific
>> FILTERs or magic predicates requires adaptations depending on
>> the RDF store used, and might be tricky when you want to mix
>> SPARQL endpoints from different vendors.
>>
>> * Ranking is essential for systems offering navigation over web data.
>> LIMIT is ok to improve performance by keeping the result size small,
>> but query processors will then return arbitrary results that wouldn't
>> satisfy end users who expect relevant (i.e. ranked) results.
>
> Oh, I quite agree. Actually I made a lot of these same points re what 
> to expect from SPARQL last friday at LIDA2009 - 
> http://www.slideshare.net/danbri/understanding-the-standards-gap ... 
> ...ie that SPARQL is good for what it's meant for, but people 
> expecting standards-supporting tools to do more will be in for a 
> dissapointment.
>
>
> What I was getting at instead in the conversation here is that we 
> could directly serialize the "box of box of related things" conceptual 
> model that we see in various SW toolsets. Am avoiding other container 
> words like (rdf:)Bag, Set, Class etc although the concepts are 
> obviously related. So for here it's "boxes".
>
> So to take David's example,
>
> Box 1: A journey exploring information about presidents, their kids 
> and their education...
> box 1.1: All things that are US presidents
> box 1.2: All things that are children of things in bag_1.1
> box 1.3: All things that are educational institutions, attended by 
> things in bag 1.2
> bag1.4: All things that are places that are locations of things in bag 
> 1.3...
>
> 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
> box 2.3: All things that are buildings designed by things that are in 
> bag 2.2 ...etc
>
> 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?")...
>
> Each of the outer boxes captures a journey into some data. In the 
> Freebase/Parallax articulation, the data is from the same 
> mega-database. Obviously Semwebby people are fascinated by distributed 
> systems and standards, which is what I'm getting at here. The 
> conceptual model above - navigating by groups of things, is pretty 
> basic and potentially universal. The restrictions in old style boolean 
> query against bibliographic databases, or the set machinery in OWL, 
> are closely related. What I'd like to see is something in this 
> direction that can be made separate of UI, separate from particular 
> database, and universal enough to be taught in schools.
>
> The sketch above is playing with a spec that could ultimately be 
> compiled down to SPARQL (though maybe not so simplistically, given the 
> need for counts etc), but which captures something a little closer to 
> UI and user intent too, so that the query could be usefully mutated if 
> it didn't throw up many results...
>
> Sorry this is so sketchy, but am I making any sense here?

This sounds pretty exciting! I'm glad you're thinking of doing something 
in this direction!

A while ago, I did think about formulating a query language to capture 
the browsing paradigm of Parallax, but I was afraid that the query 
language might restrict innovations, at least at that early stage of the 
game. But over the long term, however, once we've understood the 
conceptual model, and all of the nuances that are required for 
user-friendliness, then it's definitely worthwhile to have some 
standard, perhaps in the form of a query language, that lets different 
system work together, as you envision.

So I'd say that the best practical plan here is to develop a real 
working and usable system alongside with the query language (or protocol 
or whatever kind of abstraction), but make the system the primary 
artifact--fine-tuning it to make it usable--and keep the query language 
up to date with the system. Of course the elegance of the query language 
should also inform the design and implementation of the system.

It would be really neat if you can even set this up as an open source 
project that everyone here can work together on. (The worst case 
scenario is that it's just a paperware project that falls apart after 
the paper has been published.)

David

Received on Monday, 1 June 2009 04:14:48 UTC