(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
