W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2002

Re: Google API -> Jena

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Fri, 19 Apr 2002 15:30:20 +0100
Message-ID: <3CC029FC.1AD472C2@hplb.hpl.hp.com>
To: Dan Brickley <danbri@w3.org>
CC: Jeremy Carroll <jjc@hplb.hpl.hp.com>, www-rdf-interest@w3.org
[Very interesting experiment description snipped]

> ie. if I am a query engine that does the job of implementing rdf query
> against a plain 'match these possibly blanked-out triples', I can't be
> entirely agnostic about what's going on behind the RDF API. Or I can, but
> if I ask the triple questions in thr wrong order, I'll miss out on answers.
> We need to know that the backend will only be able to answer
> 'bound goo:backlinks unbound' or 'bound goo:backlinks bound' but not
> 'unbound goo:backlinks unbound'.

Exactly. We have they same issue.

We have an internal experimental system in which a set of knowledge sources can
be accessed collectively or individually by some client tools. Some sources are
modest scale RDF models (e.g. personal workspaces), some are very big but still
full graphs and some are wrappers on sources which can only resolve restricted
link directions. We currently use a query-by-example approach to request data -
gives us more control than simple triple patterns but less than RDQL/squish -
which seems to work fairly nicely for us.

However, we need a standard declarative way for sources to describe the sorts of
query patterns that they are good at so that future "intelligent" clients could
partition a query appropriately. We currently get knowledge sources to
self-describe their names, addresses and supported operations but don't yet have
a handle on query capability description.

Received on Friday, 19 April 2002 11:11:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:35 UTC