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
