- From: Giovanni Tummarello <g.tummarello@gmail.com>
- Date: Mon, 1 Jun 2009 00:18:05 +0100
- To: Dan Brickley <danbri@danbri.org>
- Cc: Andreas Harth <andreas@harth.org>, Kingsley Idehen <kidehen@openlinksw.com>, Daniel Schwabe <dschwabe@inf.puc-rio.br>, David Huynh <dfhuynh@alum.mit.edu>, Linked Data community <public-lod@w3.org>, semantic-web@w3.org
Hi Dan, storing (and being able to re-execute) this journey reminds me of the driving inspiration behind DERI Pipes. Pipes have an underlying XML representation language which stores the "recipie" for processing one or more RDFs. arbitrary operators can select data out of it, returns another RDF (e.g. a set of resource) and can be reexecuted to auomatically update the set when inputs change. XML scripts can be interpreted also via command line as well as simply by doing an HTTP fetch. Giovanni On Sun, May 31, 2009 at 10:01 PM, Dan Brickley <danbri@danbri.org> 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? > > cheers, > > Dan > >
Received on Sunday, 31 May 2009 23:18:59 UTC