- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 19 Apr 2002 15:30:20 +0100
- 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. Dave
Received on Friday, 19 April 2002 11:11:40 UTC