Re: Name of a graph? and FROM and FROM NAMED

Hi folks,

I was browsing the recent DAWG archives and came across
your discussion about if/how to be clear which graph/s a given
query is evaluated against, and though to offer a few comments
and suggestions. Feel free to disregard...

It seems to me that, whether or not a given service includes local
knowledge or applies inference, the key is for it to be clear to
users what knowledge a given query expressed in SPARQL
will be relevant. I.e. whether either local knowledge or inferred
knowledge is added to graphs that are explicitly specified by
the query.

It may have already been noted, though I might have missed it,
that the graph identified by a given URI may in fact include
triples which are not explicitly expressed in its representation
(e.g. an RDF/XML instance). E.g. there are triples which, per
the closure rules defined in the RDF MT are fairly considered
to be part of the graph identified by a given URI, but which might
not be explicitly expressed in a given RDF/XML serialization
(representation) due to storage/bandwidth concerns, such that
the serialization only includes the minimal set of explicit triples
needed to capture the full set of triples of the graph, relying on
the closure rules of the RDF MT to provide the additional triples.

Thus, even if the URI of a FROM or FROM NAMED expression
is dereferenced to obtain a serialization of some graph, a given 
SPARQL service may nevertheless need to employ the RDF/RDFS 
closure rules to infer the full graph identified by the URI, and it
is arguable that no RDF application should presume that any given
RDF/XML serialization is necessarily exhaustively explicit.

Now, that's just one possible point of view, and it's not
necessarily my own. But it does illustrate the fact that
there may not be a 1:1 correspondence between a given
graph and its web accessible representation -- as it is a 
reasonable argument that the closure rules defined by the RDF 
model theory should be expected to always be in scope for 
all standard compliant RDF processors and one may 
consider such inferable triples to be part of a given graph,
even if only the minimal set of explicit triples are managed
or provided in representations.

One possible way to address the issues of inference vs. no 
inference and inclusion of local knowledge versus no local knowledge
would be to simply allow users to be clear about what
they want and expect, and make it clear in the SPARQL spec
what the default should be.

E.g. let's say, for the purpose of simplicity and economy, that
the least inclusive options requiring the smallest implementational
burden should be the defaults -- i.e. that unless otherwise 
specified/requested/supported, no local knowledge is
added to FROM/FROM NAMED queries, and no inference is 
employed (accepting that any representation of any resource
accessible via the web will not necessarily be exhaustive in
reflecting the state of the resource and agents operating on
representations of graphs may not always be working with 
the complete graph to whatever extent the representations
are incomplete or leave certain triples implicitly expressed).

Then, if the user so desires, they can request a broader focus
using a special operator such as

SELECT ...
USING INFERENCE
WHERE ...

where the "USING INFERENCE" is a qualifier which tells the 
SPARQL processor that it should, if it is able, apply whatever 
reasoning facilities it has to obtain a possibly broader graph 
(or in some cases a complete graph, where representations are 
not fully explicit) prior to evaluating the query.

If FROM is used, then by default, the SPARQL processor should 
only include the user specified graph(s), and not any local graph(s),
but the user could also  request/allow the inclusion of local knowledge 
e.g.

SELECT ...
FROM ...
FROM NAMED ...
FROM LOCAL
WHERE ...

where the "FROM LOCAL" tells the SPARQL processor that it
may/should include whatever local knowledge it posseses
when evaluating the query, in addition to the user specified
graph(s).

These options could also be combined, e.g.

SELECT ...
FROM ...
FROM NAMED ...
FROM LOCAL
USING INFERENCE
WHERE ...

etc.

If a given SPARQL processor does not provide any reasoning
functionality, it can either disregard a "USING INFERENCE" request
or issue an error.

We have found with our solutions employing URIQA, that being
able to query the same persistently managed body of knowledge
by different applications where applications are able to specify
for each particular query whether inference is utilized or not has been 
of significant value.

Anyway, just an idea...

Cheers,

Patrick

Received on Sunday, 5 June 2005 08:18:09 UTC