This is an archive of an inactive wiki and cannot be modified.

This page is superseded by the RDF and OWL Compatibility document.

This page first outlines barriers to RDF compatibility and then enumerates a number of possibilities to achieve interoperability between RIF and RDF.

There is a separate page on bNode Semantics, which attempts to clarify the issues which arise when combining the bNode semantics of RDF with rules languages.

Barriers to RDF Compatibility

RDF Expressivity

Although most ground RDF triples can be captured directly in Horn rules, as rules with empty bodies, translating from s p v. to p(s,v), some features of RDF go beyond the expressive power of Horn rules. Some features require modification of some semantic treatments of Horn rules, or expose differences between the semantic treatments.

Blank nodes as queries

Blank nodes on the right-hand side of entailment are probably the easiest to deal with. The blank node is just an existential, and any of the semantic methods provide the same intuitive results.

Blank nodes as assertions

Allowing blank nodes in facts changes some aspects of the minimal model semantics. First, there might be no single minimal model. If there is no appropriate binding for the blank node that is already in the extension of the predicate, then several minimal models may exist as in

The presence of several minimal models does not affect the minimal model semantics per se except, of course, that several minimal models may need to be investigated.

The only semantics that has problems with blank nodes is the replacement semantics. The problem here is that the existential may bind to different constants in different minimal models, so

does not entail

in this semantics.

Actually, if blank nodes are the only extension, then it is possible to treat the existential as a fresh constant, similar to Skolemization. This regains a single minimal model at the price of a certain fragility, as Skolemization has to be done with care. It also brings back the equivalence of the four semantics.

Infinite base theory for RDF

RDF has an infinite number of base triples. All triples of the form

are axioms in RDF.

This leads to potential problems with decidability of function-free Horn rules, as a rule like

would have an infinite number of matches. I believe that the result would still be decidable, but this remains to be proven.

Treatment of rdf:type, rdf:Property, rdf:XMLLiteral

The treatment of the internalized meta-model of RDF requires some care as well. There are two ways to treat triples of the form

either as above, namely,

treating rdf:type as just another predicate, or as

treating rdf:type specially. The first is probably more in keeping with RDF, but doesn't work well at all for OWL DL.

The treatment of rdf:Property requires a bit of care, as one probably should have

entailing

Technically, I suppose, one could defend a stance where the entailment happened if the rule fired, and otherwise might not follow, but this seems a bit perverse.

XML literals (and, for RDFS, other datatypes) also require a bit of care. The RDF model theory has been carefully crafted so as to only require the existence of the literals that appear in an RDF graph. This makes built-in relationships over literals problematic, for starters. It is probably necessary to admit the presence of all well-formed literals if built-in predicates over literals are allowed in rules. This in turn makes another source of an infinite Herbrand universe and thus an infinite base theory, possibly resulting in undecidability.

RDFS Expressivity

Much of the additional expressive power of RDFS is similar to that from RDF.

RDFS datatypes, in particular, are in the same situation as rdf:XMLLiteral. rdfs:Literal, as well, can be treated in the same manner.

RDFS adds an infinite set of axioms, which may cause undecidability, but this is not different in kind from the infinite base of RDF.

RDFS meta-modelling

The RDFS meta-modelling facilities make it even harder to construct a bridge to rules that treat s rdf:type c . as s(c). In particular, rdfs:Class is difficult to handle in this fashion.

Interaction of rules with RDFS classes and properties

The RDFS facilities that organize classes (rdfs:subClassOf) and properties (rdfs:subPropertyOf) and the domains and ranges of properties (rdfs:domain and rdfs:range) interact closely with rules. Each such RDFS statement has the same effect as a rule, e.g., p rdfs:domain c . would correspond to the rule

so there appears to be no added computational difficulties.

However, here is the first case where the first treatment of RDF meta-modelling becomes truely problematic. Consider, for example,

where the two uses of a (as a constant and as a property) are interrelated. It is possible to use a different treatment, employing a "holds" predicate, but this is not particularly appealing.

Approaches to Compatibility

As we can see from the discussion above, there are several issues when combining RDF(S) semantics directly with the semantics of a rules language. As with OWL Compatibility, there are several approaches for combining rules and RDF.

Extending RDF(S) Semantics

The discussion above discusses ways of extending RDF(S) and problems for such extensions. The major problems in extending RDF(S) directly arise from the blank nodes in RDF triples, since they are interpreted as existentials and rules systems typically cannot deal with existentials, and the use of the RDF(S) vocabulary in the heads of rules.

Thus, such a straightforward extension of RDF(S) would lead to a non-standard semantics which cannot be dealt with using current rule reasoners.

Viewing an RDF(S) graph as a fact base

After adding all RDF(S) axiomatic triples, applying all RDF(S) entailment rules and skolemizing all blank nodes, an RDF(S) graph can be seen as a set of ground facts. These facts could be "consumed" by rules, which means that they may occur in the body of rules. The rules are used to infer additional information from the RDF(S) facts.

Access to the RDF fact base could be provided by a SparQL query interface. One could imagine that [SparQL] queries may be included in the body of a rule. Notice that this approach is highly related to the Blackbox approach in OWL Compatibility; in fact, the exchange of ground facts, proposed in the Blackbox approach, could be achieved through SparQL interfaces.