W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Re: Parameterized Inference - starting mail discussion

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 08 Apr 2009 19:04:15 +0100
Message-ID: <49DCE71F.6060101@deri.org>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Bijan Parsia wrote:
> 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.

Interesting. Let me try to explain then...

>> but simpler.
> 
> Er.. there's some sort of type error. USING RULESET is a syntactic 
> extension. OWL semantics for BGPs is not.

Maybe I should have called it USING ENTAILMENT or USING INFERENCE then, 
which was fair enough. Do you see the parallel then?

  If it was called like that, I could imagine for what you suggested 
yesterday, e.g.

  USING ENTAILMENT OWLQL
  USING ENTAILMENT RDFS
  USING ENTAILMENT OWLRL
  (we are actually discussing in RIF how to write this as a RIF ruleset, 
cf. http://www.w3.org/2005/rules/wiki/OWLRL)
  USING ENTAILMENT <someRIFRuleSet>

>> Instead 

I should maybe not have started the sentence with "Instead", I mean this 
to be complementary.

>> 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 

  yes.

 > (not your 1 I think.)

  why?

> 2) what gets into the BGP (your 2)

  Rather, what is the dataset/scoping graph.

> 3) how one says what the semantics are (and what gets in) (not your 3)

  right, doesn't have anything todo with my 3), rather that would be my
  1), i.e. yhow to specify/request "your 1)".

> 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.)

  What a RIF ruleset on top of an RDF graph means is specified in
  http://www.w3.org/2005/rules/wiki/SWC

> 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)).

You mean union Answers(Query, RULES)) here, I presume.
The answer is:  Yes, I didn't claim that it is different and pointed out 
the parallel to
http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets
whatever the syntax is, we think that such a feature is necessary.
USING ONTOLOGY was only in that sense specific, that it was a shortcut 
to merge a graph (ONT) into *any* named graph.

> For the case of RDF encoded rules,  under the standard sparql entailment
> regime, I believe these will be equal. 

under simple entailment, yes.

> Under, say, a RIF entailment regime,

...or one of your proposed OWL entailment ...

>  they probably wouldn't be.

indeed.

> (And they could be still different from Answers(Query, Data inlightof 
> RULES)..i.e., where no part of RULES would be returned).)

which is why at the moment, I would prefer a RIF syntax for Rules, to 
keep that separate, but we can discuss this certainly.

>> 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.

hmmm, did that help?

>> 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). 

Yes, this is closer to Composite GRAPHS, but as mentioned above in 
connection with RIF or OWL entailments, a proposed convenient shortcut, 
instead of having to define a new composite graph for each named graph.

> It seems like you might want this even if you aren't talking 
> ontologies.

Composite graphs? yes!
I proposed the following simpler syntax

FROM NAMED <new> { <http://xmlns.com/foaf/spec/index.rdf>
                    <http://www.polleres.net/foaf.rdf> }

for composite graphs which I personally find more intuitive, but

>  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).

not sure whether I understand that point.

>> 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)

  +1 for fixed set, extensible by explicit RIF rulesets (which makes 
sense to model what existing engines that allow custom ruleset support do)

>     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).

  yes, my point was that there are issues w.r.t. entailment and named 
graphs it seems.

> Is there anything else, conceptually speaking, in the idea of 
> Parameterized Inference per se?

  not quite... that summarizes it well enough.

cheers,
Axel

> Cheers,
> Bijan.
> 
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Wednesday, 8 April 2009 18:04:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT