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: Thu, 09 Apr 2009 13:18:39 +0100
Message-ID: <49DDE79F.2080708@deri.org>
To: Steve Harris <steve.harris@garlik.com>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Steve Harris wrote:
> On 8 Apr 2009, at 16:01, Axel Polleres wrote:
>> 1) USING RULESET is closely related to the OWL inference discussed 
>> yesterday, but simpler. 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. The suggestion here is to 
>> be able to either refer to some fixed rulesets which we endorse with 
>> some public identifier, e.g.
> I get very nervous whenever anyone (including me) says thing X is 
> simpler than thing Y. Simplicity is largely dependent on context and 
> background.

As already indicated in my reply to Bijan: I herewith withdraw the 
statement "but simpler".

>  From my p.o.v. the OWL inference thing discussed yesterday is a very 
> straightforward concept (though probably difficult to implement), 
> whereas this is significantly more complex.

I can't agree. We are talking about different entailment regimes here.
The OWL variations Bijan proposed plus other rule based inference 
regimes - at the very least a finite subset of RDFS, but also custom 
inference rulesets, as supported by several implementations are useful 
if such rulesets could be exchanged, and this is what RIF is doing and 
what it defines a semantics for. The spec (including a ruleset for RDFS) 
is there, we just need a hook for refereing to RIF rulesets. Please 
explain why you think that is more complex than the OWL entailments...
Anyways, I guess we are repeating here the same error that I did 
originally, I am fine with neither being "simpler" or "more complex".
Rule based entailments and OWL entailments (where actually OWL RL is in 
the intersection of the two) are just two examples of entailment regimes 
we should provide hooks for.

> The stuff around FROM NAMED is particularly concerning, and affects 
> general inference on the language. I think that's worth a separate 
> discussion on it's own.

Yes, I will try to separate the things on the wiki. But you agree that
the named graph issue affects rule based or OWL entailment regimes 
likewise, yes?

I think Bijan summarized it quite well in the end of his mail.

 >   A) We need a way to name entailment regimes (either a fixed list, 
or >      extensible)

seem to be on the table here, where <rifruleset> would allow a certain 
degree of extensibility by custom rulesets, but we could allow even 
more, i.e. referring to non-rule-encodable entailment regimes.

 >   B) We need to trigger entailment regimes in a query

Some ideas for keywords:


alternativelty a parameter in the protocol


are conceivable.

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

The main issue - let's maybe call it C) - seems that the current def of 
Entailment regime pretty much dets the limits:

"1 -- The scoping graph, SG, corresponding to any consistent active 
graph AG is uniquely specified and is E-equivalent to AG."

Since there is currently no way to extent named (data) graphs by 
ontologies, it seems worthwhile to think about this, USING ONTOLOGY and 
COMPOSITE GRAPHS are two alternative ways to tackle this, where 
composite graphs are more generic, but uning ontology is - for the 
particular use case of merging ontologies into all named graphs - more 


> - Steve

Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Thursday, 9 April 2009 12:19:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC