BobQL? Boxes of (related) boxes ...

(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?

cheers,

Dan

Received on Sunday, 31 May 2009 21:03:05 UTC