Re: RDF and OWL compatibility

On Tue, 2006-01-03 at 18:21 +0000, Dave Reynolds wrote:
> Michael Sintek wrote:
> 
> > Happy New Year!
> > 
> > To stimulate some discussion on RDF and OWL
> > compatibility (which, I assume, should take
> > place on the mailing list and not in the wiki),
> > here a first question:
> > 
> > "Will RIF prescribe how to map RDF/OWL ontologies/knowledge
> > bases to Horn logic, or will RIF just define
> > a general rule language for which several
> > mappings are supported?"
> 
> My take is that RIF should define one such mapping.
> 
> The charter requirement for RDF compatibility means that we have to define 
> at least one. If RIF defines lots of different mappings then rule 
> interchange is weakened because we now also need to know what data mapping 
> the rules are intended to be used on. Such ruleset metadata is perfectly 
> possible (we seem destined to have other metadata such as various semantic 
> flags discussed at the f2f). However, it seems preferable to keep things 
> simple where possible - too many choices inhibits uptake of a standard IMHO.

I'm not sure whether one mapping would suffice. Different use cases
might require different kinds of interaction between rule bases and RDF
graphs.

I think it is important to distinguish here between (a) rules with RDF
in the antecedent (body) and (b) rules with RDF in the consequent
(head). 

Rules of type (a) are relatively easy to deal with, both in a classical
setting and an LP setting.

Rules of type (b) could become a bit tricky, if we were to allow bnodes
and RDF vocabulary (as pointed out in the wiki).
A possible solution to this problem would be to limit the types of RDF
triples allowed in the head of a rule. 

Additionally, as became apparent during the discussion on OWL
compatibility in San Francisco, we will most likely need two different
semantics for our language in phase 1. One semantics based on (1)
classical models and one semantics (2) based on minimal models.
This might require two different (but I guess similar) RDF mappings.

> 
> > E.g., the straightforward mapping of RDF triples
> > <s,p,o> to Horn facts p(s,o), as mentioned
> > on http://www.w3.org/2005/rules/wg/wiki/RDF_Compatibility
> > at the beginning, would break "plain" RDF
> > compatibility as simple queries which are supported
> > by most (all?) RDF APIs and query langauages
> > will not work: query patterns of the form
> > <s,?p,o> (i.e., where at least the predicate
> > is a variable) cannot be mapped to first order
> > queries (and thus not to Horn logic).
> 
> I agree that RDF compatibility requires support for quantification over RDF 
> properties. Whether this translates into a requirement for a higher-order 
> syntax for the rule language or into a requirement that the RDF mapping 
> should use some more straightforward "triple(s,p,o)" convention is a 
> separate decision.

I'm not sure whether support for quantification over RDF properties is
required, but I can imagine it could be.
I think the syntax "triple(s,p,o)" would in this case be the more
feasible, since we decided to stay syntactically in function-free Horn
(with rule safety) for phase 1. Higher-order syntax would be a possible
extension to be considered for phase 2.

> 
> I'd like to see this reflected in the RDF compatibility pages somehow but 
> was at a loss for how to do so via the Wiki. Thanks for starting the email 
> thread!
> 
> > For applications in need of plain RDF support,
> > a much simpler mapping can be used, e.g., with
> > the well-known "true" predicate: true(s,p,o), 
> 
> Agreed.
> 
> > or, if
> > named graphs are also to be supported,
> > true(s,p,o,g) or true(triple(s,p,o),g)
> > (the latter form has been used in the
> > Semantic Web rule language TRIPLE [1], where
> > this mapping also covered substantial parts of
> > RDFS semantics).
> 
> This is clearly a separate question.
> 
> The possible need for named graph support does arise in the charter through 
> the requirement for SPARQL compatibility. Again we should separate the 
> putative SPARQL compatibility requirement (ability to match against triples 
> in named graphs) from possible solutions (quads as you suggest, or a 
> function which issues a SPARQL query, or an explicit notion of multiple KBs 
> in the rule language itself).

I think we should be careful when it comes to SPARQL compatibility. I
think we should certainly not try to extend the SPARQL semantics. 


Best, Jos

> 
> Dave
> 
> 
> 
--
Jos de Bruijn,        http://www.debruijn.net/
+43 512 507 6475         jos.debruijn@deri.org

DERI                      http://www.deri.org/
----------------------------------------------
I respect faith, but doubt is what gets you an education.
  -- Wilson Mizner