On 8 Apr 2009, at 16:01, Axel Polleres wrote:
[snip]
> Let me add some explanations beyond the wiki page on these feature(s):
>
> 1) USING RULESET is closely related to the OWL inference discussed
> yesterday,
I don't see how it's related at all.
> but simpler.
Er.. there's some sort of type error. USING RULESET is a syntactic
extension. OWL semantics for BGPs is not.
> Instead of specifying an entailment regime for one of the OWL
> dialects, the idea is to allow a very pragmatic reference
> to a ruleset specifying a finite set of RDF inference rules being
> expected to be evaluated on the query.
This seems to confuse several things:
1) the semantics of the BGP (not your 1 I think.)
2) what gets into the BGP (your 2)
3) how one says what the semantics are (and what gets in) (not your 3)
WRT 1, with rules, one needs to specify the semantics of the BGP over
those rules. (Whether this task is easy or hard is rather irrelevant
to the syntactic issues at hand.)
For 2, I'm not quite sure how this differs from any other (named)
graph manipulation. Take two graphs (DATA and RULES). (I guess I'm
presuming an RDF syntax for the RULES in this example). The key
question is whether Answers(Query, DATA union RULES) is the same as
(Answers(Query, DATA) union Answers(Query, DATA)).
For the case of RDF encoded rules, under the standard sparql
entailment regime, I believe these will be equal. Under, say, a RIF
entailment regime, they probably wouldn't be.
(And they could be still different from Answers(Query, Data inlightof
RULES)..i.e., where no part of RULES would be returned).)
> The suggestion here is to be able to either refer to some fixed
> rulesets which we endorse with some public identifier, e.g.
Before going there, I'd like some disambiguation on these points.
> 2) USING ONTOLOGY
>
> Now, if I want to support inference, I also want to support
> ontologies (even if they are not explicitly imported in a graph via
> owl:imports), that e.g. I want to see that I want to use the foaf
> ontology for inferencing on queries over foaf files. Now, as soon
> as I stay in the default graph, all is fine, I can simply merge the
> foaf ontology into the def graph, e.g.
>
> FROM myfoaf.rdf
> FROM yourfoaf.rdf
> FROM foaf-ontology.rdf
>
> BUT, in connection with named graphs I cannot merge graphs
> expclicitly!
Ok.
> that is, if I specify
>
> FROM NAMED myfoaf.rdf
> FROM NAMED yourfoaf.rdf
> FROM foaf-ontology.rdf
> WHERE { ... GRAPH ?x { .HERE. } }
>
> HERE, the foaf ontology is not in part of the scoping graph and
> thus not relevant for (even if supported) inferences.
> That is why we suggest the keyword
> USING ONTOLOGY <IRI>
> which basically says that its argument "merges" into each named graph.
This seems to be parameterized merge, not parameterized inference.
(i.e., 2). It seems like you might want this even if you aren't
talking ontologies. That is, it seems a bit orthogonal to entailment
*except* in so far that it might be moot in the standard SPARQL
entailment regime (since algebraic union might suffice).
> The ability to construct named graphs as merge of other graphs, as
> also outlined in
> http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets
> would be an alternative path to achieve this, though mor cumbersome
> to write, but more flexible.
Right. Can we at least *conceptually* separate these?
So, minimally, for parameterized inference:
A) We need a way to name entailment regimes (either a fixed list, or
extensible)
B) We need to trigger entailment regimes in a query
(Lots of issues there, e.g., only for the whole query, or settable
on a graph by graph basis; or over sets of graphs, or their merge).
Is there anything else, conceptually speaking, in the idea of
Parameterized Inference per se?
Cheers,
Bijan.