Enhanced megasac
Linde, A.E.
T.
Norman Gray
Tony,
I gave a talk at the VOTech DSRP meeting today (added to the
repository), in which I was saying that, although essentially all the
semantic/reasoning functionality we'll need is already present in the
SACs, the hard bit is to work out how to make that functionality easy
to use. There was some brief discussion of this, and I expect more
this evening. An extra issue is exactly as you suggest, what easy-to-
use added value should we provide?
At one level, the answer is easy -- let the users do it. If you
upload an ontology to your SAC, which enhances its query responses,
then if I delegate to your SAC, I immediately and automatically get
the benefit of those enhanced responses, without even knowing they're
there. But that's not much of an answer, since the point of SKUA is
to make this easy for users, without them knowing all about RDF and
ontologies.
I'm still trying to get Noel interested in using SKUA within
VOExplorer, enough that he asks 'why can't I do X?', and I say 'Hah --
a user story!', and do it.
As regards having the RDF registry at the top of the tree, we could
have that, without it having to be a SAC. Since delegation simply
consists of passing a SPARQL query along to a delegate, that delegate
only has to be able to respond to SPARQL queries, and doesn't have to
implement any more of the SAC interface than that. So if I were to
resurrect my RDF registry, we could delegate freely to that immediately.
See you,
Norman
--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester
Linde, A.E.
Since delegation simply
consists of passing a SPARQL query along to a delegate, that delegate
only has to be able to respond to SPARQL queries, and doesn't have to
implement any more of the SAC interface than that. So if I were to
resurrect my RDF registry, we could delegate freely to that immediately.
I was thinking more that terms in the ontology and assertions in the registry might be incorporated into queries mixed with the SACs within the megasac. Ie, the evaluation is across the ontologies, registry assertions and the user SAC as a whole unit rather than each individually with the results combined, so every query performed by the user is done over their own SAC combined with the megasac-hosted special assertions (such as ontologies and registry). I assumed this would yield a richer result set than the simple union of the individual queries.
T.
Norman Gray
Tony, hello.
On 2008 Sep 30, at 18:47, Linde, A.E. wrote:
> Ie, the evaluation is across the ontologies, registry assertions and
> the user SAC as a whole unit rather than each individually with the
> results combined,
That would be ideal, but I understand that that is very hard (possibly
even a Hard Problem) -- it's what Greg Williams was talking about at
ESWC back in June. The only really reliable way of doing that is to
copy all the triple stores into one, and do the query there, but of
course that's infeasible if they're any significant size. Breaking up
the query so that you only retrieve from one of the stores those
triples which are relevant to the eventual answer apparently involves
knowing the answer before you make the query.
Hence the dumbed-down version in our case: perform the same query in
multiple places, and then combine the results. There's some things we
can't do, but I suspect that we can do most of what we want, largely
because we expect the nature of the claims in each SAC will be rather
similar.
Linde, A.E.
The only really reliable way of doing that is to
copy all the triple stores into one, and do the query there
But that is what I am suggesting. A megasac is a single triplestore. If it includes ontologies and the registry in RDF form then any query a user performs over their own SAC can be done over the ontologies and registry incombination with that SAC, so enhancing the results.
Ah, I see what you mean – the federated queries cannot be performed because the query contains terms (from the ontologies and registry) that the federated SACs will not know about.
Perhaps the megasac can offer a two-stage query: one which is federated and only operates on SAC contents and a second stage which operates over the union of the federated query results with the user’s SAC and the embedded ontologies and registry???
Or the two stages could be manually performed: user queries their own SAC in union with the local ontologies and registry and the results of that make up a sort of cross-match input to the federated query being sent out???
Or maybe I’m just getting too fanciful!
T.
--
Tony Linde
Project Manager
Department of Physics & Astronomy
University of Leicester