Logical Interpretations of RDFS - A Compatibility Guide

Wolfram Conen
XONAR GMBH, Velbert, Germany
Conen@gmx.de

Reinhold Klapsing
Wirtschaftsinformatik und Softwaretechnik
Universität Essen, D-45117 Essen, Germany
Reinhold.Klapsing@uni-essen.de

Working Paper - Version 1.0

Abstract:

This paper compares the semantics (or stated more precise: an interpretation of the intended semantics) of RDF [11] and RDFS [4] (as previously captured in [5]) with the semantics defined by the new upcoming RDF Model Theory [9]. While the RDF Model Theory Draft (MT) relies on set theory, we interpret the MT utilizing a horn subset of first order logic. On one hand, this may facilitate comprehensibility, on the other hand it may lead more directly to verifiable implementations. The comparison clearly demonstrates the differences between both interpretations and discusses some consequence of the non-backward compatible treatment of range/domain properties. It may thus help active developers to understand the consequences of the changes for existing RDF schemata and to adapt their RDF/RDFS applications accordingly where possible.

Keywords: RDF Model Theory, First Order Logic, Comparison of RDFS Semantics

1 Two Interpretations of RDFS

The paper ``A logical interpretation of RDF'' [5] was a quite intensively discussed [3] attempt to give a horn-rule based interpretation of the concepts and constraints embodied in RDFS [4]. The resulting rule set has been implemented and is accessible on-line [14]. The results of the formalization have been taken up, for example in the development of O-Telos-RDF [12], and had been the base for an RDF-extension mechanism which allows to add rules and constraints to RDF Schema documents to specify the semantics of extended RDF vocabularies [7]. This has also been implemented with Prolog as an example of a host formalism implementation (see [14]) and has been used in developing (extended) RDF applications [6,10].

Recent results of the work of the RDF Core Group¹ give reason to point out the differences between our interpretation [5] (further: old interpretation) and the now forwarded view of RDFS, as expressed in the recent draft of an RDF Model Theory (MT) [9]. To ease the comparison, we will first re-cast relevant parts of the MT in the style already known from the old interpretation (to establish a new interpretation) and move forward to a concise presentation of the key differences between old and new interpretation, being mainly the treatment of the ``constraint'' properties range/domain and the (now obsolete) circularity restrictions. We include some thoughts on the comparative merits of both interpretations in application scenarios. The main claim will be that the new interpretation of RDFS gets rid of virtually all integrity constraints and thus, the focus of RDFS shifts from a schema language (allowing the checking of integrity constraints) to a typing language (now interpreting range/domain ``constraints'' as another way to define the type of objects/subjects).

We hope that this comparison may help the developer of RDF schematas and RDFS-based applications to get an overview of the intended meaning of the concepts embodied in RDFS. It may also help to better comprehend some of the intricacies related to interpreting RDF(S) specs [11,4] and related drafts [9].²

We will organize the presentation as follows: first, we will review the core parts of the old interpretation as presented in [5].³ We will categorize the horn rules into facts, deductive rules and integrity constraints. We will then develop our interpretation of the RDF Model Theory [9] along the same categorization and will, finally, compare and discuss the two interpretations.

1.1 Remark: On Facts, Deductive Rules and Integrity Constraints

We will categorize the horn rules given below into facts, deductive rules, and integrity constraints. To digest this distinction, compare, for example, the discussion of the design of RuleML in [2], or the basic concepts of IDEA [1] or O-Telos [12].

The key concepts can be outlined as follows: Below, sets of facts and deductive rules (knowledge) will be presented that capture RDFS concepts and constraints. The knowledge will be interpreted within the Datalog + Stratifiable Negation framework, that is with minimal fixpoint semantics. An RDF graph will be encoded as a 3-ary predicate $statement$, whose instances will be added to the fact base. A model for the rule set is a minimal fixpoint of the fact and rule set. Note that such a model always exist. The integrity constraints could be added to the rule set, which would make it considerably harder to find a model. This is not done directly because we do not only want to know whether a model can be found or not, but are also interested in the cause of the problems. Therefore, we encoded the integrity constraints as additional deductive (meta-)rules that allow to infer instances of a predicate $violation$ which captures the causes of integrity violations. Again, there is always a (meta-)model for the complete set of rules though, if violations are present, the initial rule set plus a naive formulation of the integrity constraints, would not have a model.

Figure 1: The Knowledge Base has a fixed part (factual knowledge, deductive rules, integrity checking rules) and a volatile part (the actual RDF graph, whose inferential consequences and potential integrity constraint violations are to be checked).

2 The ``Old'' Interpretation of RDFS

Below, first RDF graphs are transformed into the extension of a logical predicate, statement. Then, horn rules ⁴ are presented that aim at capturing the concepts and constraints presented in the RDFS candidate recommendation [4]. This will result in three categories of horn rules, namely facts, deductive rules and integrity constraints (presented as deductive rules on top of the basic knowledge-level predicates that capture the basic set of deductive rules mentioned before). We will generally be concise in the presentation, for details on the justification of specific horn rules, please refer to [5] which usually gives detailed references to [4] to justify the choice. Some more details will be presented where this seems necessary to make the discussion in the last section of the paper more self-contained - this is primarily necessary for the constraint properties range and domain. We start with the deductive rules⁵, then move to facts and finally give the integrity constraints.

2.1 RDF graphs

In [5], we considered RDF graphs to be the following: An RDF graph consists of nodes and arcs. Nodes are labeled either with an URI (concept Resource) or an atomic value (concept Literal). We will assume the following definitions for an RDF graph, which are adapted and extended from the definitions stated in [13] for semantic networks. (1) In an RDF graph two nodes with different labels are considered to be different. (2) Two nodes with the same label are not allowed. (3) A Literal node is represented by a rectangle. (4) A Resource (concept) node is represented by an oval. (5) The representation of a Resource node or a Literal node implicitly states its existence. (6) An arc links a Resource node either with a Literal node or another Resource node and is labeled with an URI⁶. Two nodes linked with an arc are called a statement. (7) All statements in an RDF Graph are considered to be implicitly and conjunctively concatenated.

Assume that an RDF model is given as a semantic network obeying the above constraints. We will straightforwardly map this to a logical predicate: The predicate statement(s,p,o) be true iff there is a directed arc from node s to node o and the arc is labeled with p. The extension of the predicate $statement$ represents an RDF graph in the following formalization. Note that below, TYPE, STATEMENT etc. are used as shorthand for complete URIs.⁷

2.2 Rules

2.2.1 Resource, Literals

$$statement(s,p,o) \Rightarrow res(s) \wedge uri(p) \wedge obj(o)$$ (2.1)

$$uri(r) \Rightarrow res(r)$$ (2.2)

$$obj(o) \wedge \neg res(o) \Rightarrow lit(o)$$ (2.3)

$$lit(o) \Rightarrow instanceOf(o,LITERAL)$$ (2.4)

Note that the implementation of the above rules in the RDF Schema Explorer in its current version is slightly different.⁸

2.2.2 Reification

$$res(s) \wedge uri(p) \wedge statement(s',TYPE,STATEMENT) \wedge \; statement(s', SUBJECT,s)$$

$$\wedge \; statement(s', PREDICATE,p) \wedge \; statement(s',OBJECT,o) \Rightarrow reifies(s',s,p,o)$$ (2.5)

$$reifies(s',s,p,o) \Rightarrow reifyingStatement(s')$$ (2.6)

$$reifies(s',s,p,o) \wedge statement(s,p,o) \Rightarrow reifies\_fact(s',s,p,o)$$ (2.7)

2.2.3 Instances, Sub Classes

$$statement(i,TYPE,c) \Rightarrow instanceOf(i,c)$$ (2.8)

$$statement(c1,SUBCLASSOF,c2) \Rightarrow subClassOf(c1,c2)$$ (2.9)

$$subClassOf(c1,c2) \wedge subClassOf(c2,c3) \Rightarrow subClassOf(c1,c3)$$ (2.10)

$$instanceOf(i,c1) \wedge subClassOf(c1,c2) \Rightarrow instanceOf(i,c2)$$ (2.11)

2.2.4 Sub Properties

$$statement(p1,SUBPROPERTYOF,p2) \Rightarrow subPropertyOf(p1,p2)$$ (2.12)

$$subPropertyOf(p1,p2) \wedge subPropertyOf(p2,p3) \Rightarrow subPropertyOf(p1,p3)$$ (2.13)

$$statement(s,p1,o) \wedge subPropertyOf(p1,p2) \Rightarrow statement(s,p2,o)$$ (2.14)

2.3 Facts

2.3.1 Type/SubClass Facts

(1) statement(LITERAL,TYPE,CLASS).
(2) statement(CLASS,TYPE,CLASS).
(3) statement(RESOURCE,TYPE,CLASS).
(4) statement(PROPERTY,TYPE,CLASS).
(5) statement(CONSTRAINTRESOURCE,TYPE,CLASS).
(6) statement(CONSTRAINTPROPERTY,TYPE,CLASS).
(7) statement(RANGE,TYPE,CONSTRAINTPROPERTY).
(8) statement(DOMAIN,TYPE,CONSTRAINTPROPERTY).
(9) statement(TYPE,TYPE,PROPERTY).
(10) statement(SUBPROPERTY,TYPE,PROPERTY).
(11) statement(SUBCLASSOF,TYPE,PROPERTY).
(12) statement(SUBJECT,TYPE,PROPERTY).
(13) statement(PREDICATE,TYPE,PROPERTY).
(14) statement(OBJECT,TYPE,PROPERTY).
(15) statement(STATEMENT,TYPE,CLASS).
(16) statement(CLASS,SUBCLASSOF,RESOURCE).
(17) statement(CONSTRAINTRESOURCE,SUBCLASSOF,RESOURCE).
(18) statement(PROPERTY,SUBCLASSOF,RESOURCE).
(19) statement(CONSTRAINTPROPERTY,SUBCLASSOF,PROPERTY).
(20) statement(CONSTRAINTPROPERTY,SUBCLASSOF, CONSTRAINTRESOURCE).

2.3.2 Range/Domain Facts

(21) statement(RANGE,RANGE,CLASS).
(22) statement(TYPE,RANGE,CLASS).
(23) statement(SUBCLASSOF,RANGE,CLASS).
(24) statement(DOMAIN,RANGE,CLASS).
(25) statement(SUBJECT,RANGE,RESOURCE).
(26) statement(PREDICATE,RANGE,PROPERTY).
(27) statement(SUBPROPERTY,RANGE,PROPERTY).
(28) statement(SUBPROPERTY,DOMAIN,PROPERTY).
(29) statement(RANGE,DOMAIN,PROPERTY).
(30) statement(DOMAIN,DOMAIN,PROPERTY).
(31) statement(SUBJECT,DOMAIN,STATEMENT).
(32) statement(PREDICATE,DOMAIN,STATEMENT).
(33) statement(OBJECT,DOMAIN,STATEMENT).
(34) statement(TYPE,DOMAIN,RESOURCE).
(35) statement(SUBCLASSOF,DOMAIN,CLASS).

2.4 Integrity Constraints

2.4.1 Cycles

RDFS-Definition:

⁹A class can never be declared to be a subclass of itself, nor of any of its own subclasses.

$$subClassOf(c1,c2) \wedge c1 = c2 \Rightarrow subclass\_cycle\_violation(c1)$$ (2.15)

RDFS-Definition:

A property can never be declared to be a subproperty of itself, nor of any of its own subproperties.

$$subPropertyOf(p1,p2) \wedge p1 = p2 \Rightarrow subproperty\_cycle\_violation(p1)$$ (2.16)

2.4.2 Domain and Range

RDFS-Definition:

An instance of ConstraintProperty that is used to indicate the class(es) on whose members a property can be used. A property may have zero, one, or more than one class as its domain. If there is no domain property, it may be used with any resource. If there is exactly one domain property, it may only be used on instances of that class (which is the value of the domain property). If there is more than one domain property, the constrained property can be used with instances of any of the classes (that are values of those domain properties). ...The rdfs:domain of rdfs:domain is the class rdf:Property. This indicates that the domain property is used on resources that are properties. ...Note: This specification does not constraint the number of rdfs:domain properties that a property may have. If there is no domain property, we know nothing about the classes with which the property is used. If there is more than one rdfs:domain property, the constrained property can be used with resources that are members of any of the indicated classes. Note that unlike range this is a very weak constraint.

$$statement(p,DOMAIN,c) \wedge instanceOf(i,c) \Rightarrow domain(i,p)$$ (2.17)

$$statement(p,DOMAIN,c) \Rightarrow domain\_constrained\_prop(p)$$ (2.18)

$$statement(s,p,o) \wedge domain\_constrained\_prop(p) {}$$

$$\wedge \neg domain(s,p) \Rightarrow domain\_violation(s,p,o)$$ (2.19)

RDFS-Definition:

An instance of ConstraintProperty that is used to indicate the class(es) that the values of a property must be members of. The value of a range property is always a Class. Range constraints are only applied to properties. A property can have at most one range property. It is possible for it to have no range, in which case the class of the property value is unconstrained....The rdfs:domain of rdfs:range is the class rdf:Property. This indicates that the range property applies to resources that are themselves properties. The rdfs:range of rdfs:range is the class rdfs:Class. This indicates that any resource that is the value of a range property will be a class.

Rules for determining if at most one range constraint is present:

$$statement(p,RANGE,o) \Rightarrow is\_range(o,p)$$ (2.20)

$$is\_range(r1,p) \wedge is\_range(r2,p) \wedge (r1 \not= r2) \Rightarrow range\_cardinality\_violation(p)$$ (2.21)

Rules for determining range violations:

$$is\_range(r,p) \Rightarrow has\_range(p)$$ (2.22)

$$statement(s,p,o) \wedge instanceOf(o,c) \wedge \; is\_range(c,p) \Rightarrow range(o,p)$$ (2.23)

$$statement(s,p,o) \wedge has\_range(p) \wedge \; \neg range(o,p) \Rightarrow range\_violation(s,p,o)$$ (2.24)

3 Interpreting the Model Theory: the ``New'' Interpretation of RDFS

We will first review the basic notions of the MT draft [9] and later set out to capture its essence as rules and facts formulated in Datalog. This will help to study a central lemma of the MT, the RDFS entailment lemma, based on the notion of least fixpoint models. This will set the stage for the comparison of the rule and fact sets in the final Section 4.

3.1 RDF Graphs

MT, Sec. 0.2:

¹⁰An RDF graph is a collection of nodes linked by directed arcs, with labels satisfying the following conditions: arcs are labelled with URI references (in the sense of [RFC 2396], which we will call urirefs); nodes from which arcs emerge are either unlabelled, or labelled with urirefs; all other nodes are either unlabelled, or labelled with urirefs or literals; and distinct labeled nodes have different labels. ...

An RDF graph will be said to be ground if every node in the graph is labeled. The vocabulary of a graph is the set of urirefs that it contains. A graph which is like an RDF graph except that it has two or more nodes with the same label will be called an untidy graph.

We will considered tidy graphs only. We will make use of the following correspondence to N-triples, which allows to give unique identity (via bNode labels) to ``unlabeled'' nodes, supporting the mapping of RDF Graphs to the predicate statement below.

MT, Sec. 0.2:

A graph can be viewed as a set of triples corresponding to its edges; the correspondence between an ntripleDoc and an RDF graph is that the graph has one node for each uriref, bNode or literal identifier in the document, and one edge for each triple, directed from the node corresponding to the subject to the node corresponding to the object. Nodes corresponding to urirefs and literals are labeled with the corresponding uriref or literal, and arcs are labeled with the property uriref from the corresponding triple. Notice that this requires that all occurrences of a particular uriref or bNode identifier in an N-triples document be mapped to a single node in the corresponding graph.

Assume that we have a set T of N-triples, corresponding to a tidy RDF graph and conforming to the above mapping condition. To start the horn formalization, let the predicate statement(s,p,o) be true if and only if there is a triple [s, p, o] in T.

Note that throughout the rest of this interpretation, we will ignore the suggested interpretation of anonymous nodes as quantified variables.¹¹

The MT makes the notion of interpretations explicit:

MT, Sec. 1.3

A simple interpretation I on the vocabulary V is defined by:

1. A non-empty set IR of resources, called the domain or universe of I.
2. A subset IP of IR corresponding to properties
3. A mapping IEXT from IP into the powerset of IRx(IR union LV) (i.e. the set of sets of pairs $<$x,y$>$ with x in IR and y in IR or LV)
4. A mapping IS from V into IR

Further, note that we will restrict ourselves to a Herbrand-Interpretation to obtain results later on. We also assume that there are only asserted triples.¹²

With this assumptions, the denotation rules¹³ are immediately fulfilled and do not require any representation as horn rules.

The MT also introduces the notion of reserved vocabularies. The first such vocabulary that is studied is called rdfV. It contains the members rdf:type and rdf:Property.

MT, Sec. 3:

An rdf-interpretation of a vocabulary V is an interpretation I on (V union rdfV) which satisfies the following extra conditions:

• IP contains I(rdf:type)

• IEXT(I(rdf:type)) contains $<$x, I(rdf:Property)$>$ iff x is in IP

The MT defines the notion of closure of RDF graphs that contain elements of reserved vocabularies. This allows to study entailment of such ``augmented'' graphs based on simple entailment.

MT, Sec. 4:

The rdf-closure of an RDF graph E is the graph gotten by adding triples to E according to the following (very simple) rules:

1. Add the following triple (which is true in any rdf-interpretation): rdf:type rdf:type rdf:Property.

2. Apply the following rule recursively to generate all legal RDF triples (i.e. until none of the rules apply or the graph is unchanged.) Here xxx and yyy stand for any uriref, bNode or literal expression, aaa for any uriref.

   if E contains xxx aaa yyy then add aaa rdf:type rdf:Property.

What we will do to allow for comparisons is to map the basic notions of graphs,interpretations, denotation rules and closure rules to the framework outlined above and use Datalog to reason about it.

Facts:

A tidy RDF graph as given by NTriples is mapped to a 3-ary predicate $statement$. As before, some elementary facts about the RDFS vocabulary are mapped to $statement$ as well.

Deductive Rules

The closure rules are captured as Datalog rules. This allows to identify the closure of an RDF graph with a (minimal) fixpoint model [15] of the Datalog rules and facts.

Integrity Constraints

The denotation rules are captured as horn formulas, using the previously defined Datalog rules and facts. The question to answer is then, for a given lemma, whether all fixpoint models for the given set of facts and deductive rules also satisfy the integrity constraints (ie., are the integrity constraints logical consequences of the Datalog rules and facts).

This machinery will be used later to show the RDFS Entailment Lemma. We will now start to give the Datalog rules and facts for the RDFS vocabulary.

3.2 Deductive Rules

The following rules capture the so-called closure rules of Section 5 of the MT. Computing the so-called schema-closure of RDFS graphs may be thought of corresponding to computing a minimal model of the datalog rules and facts to be given below. It can be shown that the integrity constraints given later are logical consequences of the following rule set, which is a straightforward way to show the RDFS entailment lemma of the MT by evoking results from fixpoint semantics of Datalog (for details, refer to the subsection on Integrity Constraints).

We will generally follow the route chosen in [5], that is, we will introduce so-called knowledge-level predicates for the core concepts of RDFS, for example instanceOf to capture typing information.

Note that in the following

MT, Sec. 5:

...xxx, yyy and zzz stand for any uriref, bNode or literal expression, aaa for any uriref, and uuu for any uriref or bNode (but not a literal).

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdf1	xxx aaa yyy	aaa rdf:type rdf:Property .

$$statement(s,p,o) \Rightarrow instanceOf(p,PROPERTY).$$ (3.1)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs2	xxx aaa yyy
	aaa rdf:domain zzz	xxx rdf:type zzz.

First, we introduce the predicate $domain$:

$$statement(p,DOMAIN,c) \Rightarrow domain(c,p)$$ (3.2)

The following captures rule rdfs2:

$$statement(s,p,o) \wedge domain(c,p) \Rightarrow instanceOf(s,c)$$ (3.3)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs3	xxx aaa uuu
	aaa rdf:range zzz	uuu rdf:type zzz .

We introduce a predicate $range$.

$$statement(p,RANGE,c) \Rightarrow range(c,p).$$ (3.4)

The following captures rule rdfs3:¹⁴

$$statement(s,p,o) \wedge \neg lit(o)\wedge range(c,p) \Rightarrow instanceOf(o,c).$$ (3.5)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs4a	xxx aaa yyy	xxx rdf:type rdfs:Resource

$$statement(s,p,o) \Rightarrow instanceOf(s,RESOURCE).$$ (3.6)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs4b	xxx aaa uuu	uuu rdf:type rdfs:Resource .

$$statement(s,p,o) \wedge \neg lit(o) \Rightarrow statement(o,TYPE,RESOURCE).$$ (3.7)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs5	aaa rdfs:subPropertyOf bbb
	bbb rdfs:subPropertyOf ccc	aaa rdfs:subPropertyOf ccc .

First, we introduce the predicate $subProperty$:

$$statement(p1,SUBPROPERTYOF,p2) \Rightarrow subPropertyOf(p1,p2)$$ (3.8)

We now capture the closure rule¹⁵ as:

$$subPropertyOf(p1,p2) \wedge subPropertyOf(p2,p3) \Rightarrow subPropertyOf(p1,p3)$$ (3.9)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs6	xxx aaa yyy
	aaa rdfs:subPropertyOf bbb	xxx bbb yyy .

$$statement(s,p1,o) \wedge subPropertyOf(p1,p2) \Rightarrow statement(s,p2,o)$$ (3.10)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs7	xxx rdf:type rdfs:Class	xxx rdfs:subClassOf rdfs:Resource .

This will be captured in the following rule, though note that, with rdfs:Literal being an instance of rdfs:Class, it would follow that every instance of rdfs:Literal would be an instance of rdfs:Resource. The treatment of Literals seems to require some clarification.

$$instanceOf(x,CLASS) \Rightarrow subclassOf(x,RESOURCE).$$ (3.11)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs8	xxx rdfs:subClassOf yyy
	yyy rdfs:subClassOf zzz	xxx rdfs:subClassOf zzz .

First, the predicate $subClassOf$ is introduced:

$$statement(c1,SUBCLASSOF,c2) \Rightarrow subClassOf(c1,c2)$$ (3.12)

Then, the rule rdfs8 is captured as follows:

$$subClassOf(c1,c2) \wedge subClassOf(c2,c3) \Rightarrow subClassOf(c1,c3)$$ (3.13)

MT, Sec. 5:

$\;$

	if E contains:	then add:
rdfs9	xxx rdfs:subClassOf yyy
	aaa rdf:type xxx	aaa rdf:type yyy .

First, the predicate $instanceOf$ is used:

$$statement(i,TYPE,c) \Rightarrow instanceOf(i,c)$$ (3.14)

Then, the rule rdfs9 is captured as follows:

$$instanceOf(i,c1) \wedge subClassOf(c1,c2) \Rightarrow instanceOf(i,c2)$$ (3.15)

Note that we have left out the rule rdfs10¹⁶ of the MT draft as the RDF core WG has decided to remove rdfs:ConstraintResource and rdfs:ConstraintProperty. We also removed the related interpretation condition and several facts.

Note that above, we have introduced specific predicates to capture the extensions of the properties rdfs:type, rdfs:subProperty and rdfs:subClassOf with the consequence that most of the inferred information is not part of the $statement$ relation (which corresponds to an graph). This has been done to keep the rules comprehensible (as it may seem comparatively easier to read a notation that makes the relevant predicate extension explicit) and comparable to the rules of the old interpretation. To complete the closure with respect to $statement$ and to enable the evaluation of models conforming to the above rules and the following factual knowledge with respect to the interpretation rules of Section 5 of the MT, the following rules have to be added:

$$instanceOf(x,y) \Rightarrow statement(x,TYPE,y).$$ (3.16)

$$subClassOf(x,y) \Rightarrow statement(x,SUBCLASSOF,y).$$ (3.17)

$$subPropertyOf(x,y) \Rightarrow statement(x,SUBPROPERTYOF,y).$$ (3.18)

3.3 Facts

The MT draft gives the following facts to be added to the facts drawn from the RDF graph to form the input to the closure computation. We give a reformulation of the triples as instances of $statement$.

1	rdfs:Resource rdf:type rdfs:Class	statement(RESOURCE,TYPE,CLASS).
2	rdfs:Literal rdf:type rdfs:Class	statement(LITERAL,TYPE,CLASS).
3	rdfs:Class rdf:type rdfs:Class	statement(CLASS,TYPE,CLASS).
4	rdf:Property rdf:type rdfs:Class	statement(PROPERTY,TYPE,CLASS).
5	rdf:type rdf:type rdf:Property	statement(TYPE,TYPE,PROPERTY).
6	rdf:type rdfs:domain rdfs:Resource	statement(TYPE,DOMAIN,RESOURCE).
7	rdf:type rdfs:range rdfs:Class	statement(TYPE,RANGE,CLASS).
8	rdfs:domain rdf:type rdf:Property	statement(DOMAIN,TYPE,PROPERTY).
9	rdfs:domain rdfs:domain rdf:Property	statement(DOMAIN,DOMAIN,PROPERTY).
10	rdfs:domain rdfs:range rdfs:Class	statement(DOMAIN,RANGE,CLASS).
11	rdfs:range rdf:type rdf:Property	statement(RANGE,TYPE,PROPERTY).
12	rdfs:range rdfs:domain rdf:Property	statement(RANGE,DOMAIN,PROPERTY).
13	rdfs:range rdfs:range rdfs:Class	statement(RANGE,RANGE,CLASS).
14	rdfs:subPropertyOf rdf:type rdf:Property	statement(SUBPROPERTY,TYPE,PROPERTY).
15	rdfs:subPropertyOf rdfs:domain rdf:Property	statement(SUBPROPERTY,DOMAIN,PROPERTY).
16	rdfs:subPropertyOf rdfs:range rdf:Property	statement(SUBPROPERTY,RANGE,PROPERTY).
17	rdfs:subClassOf rdf:type rdf:Property	statement(SUBCLASSOF,TYPE,PROPERTY).
18	rdfs:subClassOf rdfs:domain rdfs:Class	statement(SUBCLASSOF,DOMAIN,CLASS).
19	rdfs:subClassOf rdfs:range rdfs:Class	statement(SUBCLASSOF,RANGE,CLASS).

Note that, with the closure rule rdf1 and, for example, the fact 1, the fact 5 is redundant. Furthermore, with the closure rule rdf1 and, for example, the facts 6 resp. 7, the facts 8 resp. 11 are redundant too.

3.4 Integrity Constraints

We will demonstrate below that the RDFS entailment Lemma (with the restriction that follow from our assumption outlined above) follows from the rules and facts given above. This will enable us to further neglect the explicit consideration of the RDFS interpretation conditions given in Section 5 of the MT.

For comparability, we introduce the following predicates:

$$iext(s,o,p) \Leftrightarrow statement(s,p,o)$$ (3.19)

$iext(s,o,p)$ can be read as: $<$s,o$>$ are in the Extension of P (keep in mind that with our assumption that the interpretation is fixed to identity, there is no point anymore in distinguishing between p and I(p), or between an extension defined on symbols for p or an extension defined on the interpretation for the interpretation of p).

$$icext(y,x) \Leftrightarrow iext(x,y,TYPE)$$ (3.20)

$icext(y,x)$ can be read as: y is in the class extension of x.

We will now study the conditions given in Sec. 5 of the MT for RDFS interpretations. Our claim is that the conditions will all be logical consequences¹⁷ of the rules and facts that were given above for any RDF graph. Note the relation of this claim to the Entailment Lemma:

MT:

RDFS Entailment Lemma. S rdfs-entails E iff the rdfs-closure of the merge of S simply entails E.

This lemma builds on the following:

MT, Sec. 2:

Suppose S is a set of RDF graphs, then their merge is the graph obtained by taking the union of the sets of all their triples and tidying the resulting set, i.e. identifying nodes labeled with the same uriref or literal.

MT, Sec. 2

Interpolation Lemma. S entails¹⁸ E iff a subgraph of the merge of S is an instance of E.

MT, Sec. 2:

We say that I satisfies E if I(E)=true, and that a set S of expressions (simply) entails E if every interpretation which satisfies every member of S also satisfies E. If $\{$E$\}$ entails E' we will say that E entails E'.

We will no show that all conditions follow as logical consequence from the rules, facts and assumptions given above.

MT:

x is in ICEXT(y) iff $<$x,y$>$ is in IEXT(I(rdf:type))

This definition is captured already in the above rule.

MT:

IC = ICEXT(I(rdfs:Class))

This definition requires no further treatment. It will be used to substitute ICEXT(I(rdfs:Class)) for IC when necessary.

MT:

ICEXT(I(rdfs:Resource)) = IR

We assumed tidy RDF graphs. We will also assume that the MT aims at reasonably-sized interpretations (ie, IS is surjective)¹⁹ Then, the above condition essentially says that every subject, predicate or object of a triple that is mapped by an interpretation to an element of IR should also have the type rdfs:Resource. Before this will be discussed, let us briefly review the next condition:

MT:

ICEXT(I(rdf:Property)) = IP

With the correspondence between the predicate $statement$ and RDF graphs, and an appropriate assumption regarding the size of IP, IP is the projection of the second argument $statement$, captured in the following additional rule.

$$statement(s,p,o) \Leftrightarrow ip(p)$$ (3.21)

Now, the condition can be formulated²⁰ as

$$icext(x,PROPERTY) \Leftrightarrow ip(x).$$ (3.22)

This constraints is an immediate logical consequence of rule (3.1).

Now, let us return to the condition ICEXT(I(rdfs:Resource)) = IR. First, note that from the above, from the fact statement(PROPERTY,SUBCLASSOF,RESOURCE) and from the rules (3.12), (3.13), (3.14), (3.15), (3.16) follows that each predicate of a triple is in the class extension of rdfs:Resource. For subjects of triples (ie., the projection of the first argument of $statement$), reasoning analogous to the Property case applies. With (3.6) follows immediately that

$$statement(s,p,o) \Rightarrow icext(s,RESOURCE)$$ (3.23)

From (3.7) follows

$$statement(s,p,o) \wedge \neg lit(o) \Rightarrow icext(s,RESOURCE)$$ (3.24)

and, therefore, every non-literal that is used in the closure graph is in the class extension of rdfs:Resource. (The other direction follows from the reasonable-size assumption).

MT:

ICEXT(I(rdfs:Literal)) is a subset of LV

We assume this condition to be true.²¹

MT:

IC contains: I(rdfs:Resource), I(rdf:Property), I(rdfs:Class),
I(rdfs:Literal)

This follows immediately from the facts 1-4, rule (3.14) and the above definitions.

MT:

IP contains: I(rdf:type), I(rdfs:domain), I(rdfs:range),
I(rdfs:subPropertyOf), I(rdfs:subClassOf)

This follows immediately from the facts 5,8,11,14,17, rule (3.14) and the above definitions.

MT:

IEXT(I(rdfs:domain)) contains $<$I(rdfs:domain), I(rdf:Property)$>$,
$<$I(rdfs:range), I(rdf:Property)$>$

This follows immediately from the facts 9 and 12 and definition (3.19).

MT:

IEXT(I(rdfs:range)) contains $<$I(rdfs:domain), I(rdfs:Class)$>$,
$<$I(rdfs:range), I(rdfs:Class)$>$

This follows immediately from the facts 10 and 13 and definition (3.19).

MT:

If $<$x,y$>$ is in IEXT(I(rdfs:range)) and $<$u,v$>$ is in IEXT(x) then v is in ICEXT(y)

$$iext(x,y,RANGE) \wedge iext(u,v,x) \Rightarrow instanceOf(v,y).$$ (3.25)

From the definition of $iext$ and the rules that relate $instanceOf$ and $statement$ follows that this conditions can be re-written as:

$$statement(x,RANGE,y) \wedge statement(u,x,v) \Rightarrow statement(v,TYPE,y).$$

This is a re-statement of the closure rule (3.5), and thus its most straightforward logical consequence.

MT:

If $<$x,y$>$ is in IEXT(I(rdfs:domain)) and $<$u,v$>$ is in IEXT(x) then u is in ICEXT(y)

$$iext(x,y,DOMAIN) \wedge iext(u,v,x) \Rightarrow instanceOf(u,y).$$ (3.26)

A reasoning analogous to the range case applies, refering to closure rule (3.3) instead.

MT:

If $<$x,y$>$ is in IEXT(I(rdfs:subClassOf)) then ICEXT(x) is a subset of ICEXT(y)

For ICEXT(x) to be a subset of ICEXT(y), every member of ICEXT(x) must also be a member of ICEXT(y), which can be captured as $\forall z: icext(z,x) \Rightarrow icext(z,y)$, or, with the definition (3.20) of $icext$ above, as: $iext(z,x,TYPE) \Rightarrow iext(z,y,TYPE)$. This is, with (3.19), equivalent to $statement(z,TYPE,x) \Rightarrow statement(z,TYPE,y)$. With the rules (3.14) and (3.16) this is equivalent to $instanceOf(z,x) \Rightarrow instanceOf(z,y)$. A similar transformation for IEXT(I(rdfs:subClassOf)) results in the condition

$$instance(z,x) \wedge subClassOf(x,y) \Rightarrow instanceOf(z,y).$$ (3.27)

This is a duplicate of the closure rule (3.15).

MT:

If $<$x,y$>$ is in IEXT(I(rdfs:subPropertyOf)) then IEXT(x) is a subset of IEXT(y)

$$iext(u,v,x) \wedge subPropertyOf(x,y) \Rightarrow iext(u,v,y).$$ (3.28)

This is a re-write of the closure rule (3.10).

This suffices to show that all LFP models of the basic facts, the deductive rules and any set of $statement$s (which encodes an arbitrary, tidy RDF graph with or without RDFS vocabulary) are also models for the semantic constraints given above. Note that there are some consequences of this: first, whenever the closure of an RDF graph is computed, applying the closure rules suffice to make sure that the semantic constraints are satisfied. Second, there are no integrity constraints in the second interpretation (ie., there are no constraints that can ever be violated from any graph and the facts and deductive rules given above). The latter will be discussed more thoroughly in the next section.

4 Comparing and Discussing the Interpretations

4.1 Comparing the Rules

As has already been demonstrated, the new interpretation does not have any more integrity constraints that could be used to define a notion of validity for RDFS graphs and their closure with respect to such constraints. Namely, range/domains are not interpreted as constraints anymore, but as another means to introduce typing information. Furthermore, the no-cycle constraints for subclass and subproperty relations have been removed, as has been the cardinality restriction on range constraints.

We will now study the similarities and differences in some detail.

4.1.1 Directly corresponding rules

$$\quad statement(p1,SUBPROPERTYOF,p2) \Rightarrow subPropertyOf(p1,p2).$$ (3.8)    equiv. (2.12)

$$\quad subPropertyOf(p1,p2) \wedge subPropertyOf(p2,p3) \Rightarrow subPropertyOf(p1,p3).$$ (3.9)    equiv. (2.13)

$$\quad statement(s,p1,o) \wedge subPropertyOf(p1,p2) \Rightarrow statement(s,p2,o).$$ (3.10)    equiv. (2.14)

$$\quad statement(c1,SUBCLASSOF,c2) \Rightarrow subClassOf(c1,c2).$$ (3.12)    equiv. (2.9)

$$\quad subClassOf(c1,c2) \wedge subClassOf(c2,c3) \Rightarrow subClassOf(c1,c3).$$ (3.13)    equiv. (2.10)

$$\quad statement(i,TYPE,c) \Rightarrow instanceOf(i,c).$$ (3.14)    equiv. (2.8)

$$\quad instanceOf(i,c1) \wedge subClassOf(c1,c2) \Rightarrow instanceOf(i,c2).$$ (3.15)    equiv. (2.11)

4.1.2 Differences: Treating Literals

The new rules with a specific treatment of literals are:

$$\quad\quad statement(s,p,o) \wedge \neg lit(o) \wedge range(c,p) \Rightarrow instanceOf(o,c).$$ (3.5)

$$\quad\quad statement(s,p,o) \wedge \neg lit(o) \Rightarrow statement(o,TYPE,RESOURCE).$$ (3.7)

As noted before, the closure rules as given in the MT draft depend on the ability to recognize literals (this is reflected in the use of the extra-logical predicate $lit$ above). Furthermore, it is not possible to express that literal values are instances of rdfs:Literal without producing triples in the closure that can either be seen as violating the interpretation condition on the interpretation of the extension of predicates (ie, IP $\subseteq$ IR $\times$ (IR $\cup$ LV)) or as implying that every literal value is an element of IR (which is not ruled out by the MT and could be thought of as a consequence of the condition on IP). From inspecting the MT draft, it is not completely clear to us if we haven't noticed an appropriate explanation or if the MT is imprecise here. However, the rule

$$\quad instanceOf(x,CLASS) \Rightarrow subclassOf(x,RESOURCE).$$ (3.11)

together with the new fact 2 seems to be problematic no matter how this is clarified. This rule is not part of the old interpretation because the fact that rdfs:Literal is an instance of rdfs:Class is part of both interpretations and this rule would therefore imply that every literal is resource.

In the old interpretation, assigning a type to a literal is not problematic, because there is no rule that enforces to deduce from the presence of an instance of the knowledge-level predicate $instanceOf$ an instance of the graph level predicate $statement$.²² With respect to literals, the old rules take a rather pragmatic view: something that is used in object position and is not used somewhere else in subject or predicate position is considered to be a literal.²³ The rules that capture this notion of literals in the old interpretation are:

$${\text (2.1) } \quad statement(s,p,o) \Rightarrow res(s) \wedge uri(p) \wedge obj(o)$$

$${\text (2.2) } \quad uri(r) \Rightarrow res(r)$$

$${\text (2.3) } \quad obj(o) \wedge \neg res(o) \Rightarrow lit(o)$$

$${\text (2.4) } \quad lit(o) \Rightarrow instanceOf(o,rdfs\_Literal)$$

4.1.3 Differences: Domain/Range Constraints

The treatment of rdfs:range and rdfs:domain differs significantly. As has been pointed out earlier, these two properties give now an additional alternative to specify the type of objects/subjects instead of allowing to introduce a notion of graph validity. The new rules are captured as follows:

$$\quad statement(p,DOMAIN,c) \Rightarrow domain(c,p).$$ (3.2)

$$\quad statement(s,p,o) \wedge domain(c,p) \Rightarrow instanceOf(s,c).$$ (3.3)

$$\quad statement(p,RANGE,c) \Rightarrow range(c,p).$$ (3.4)

$$\quad statement(s,p,o) \wedge \neg lit(o) \wedge range(c,p) \Rightarrow instanceOf(o,c).$$ (3.5)

In the old version, as described in detail in Subsection 2.4.2, integrity-checking meta-rules have been formulated explicitly to catch violation of the domain/range constraints, which can be boiled down to²⁴

$$(1)\quad\quad statement(s,p,o) \wedge domain(c,p) \Rightarrow instanceOf(s,c).$$

$$(2)\quad\quad statement(s,p,o) \wedge \neg lit(o) \wedge range(c,p) \Rightarrow instanceOf(o,c).$$

- only that in the old interpretation, the consequences of facts and deductive rules are checked against this integrity constraints, while in the new interpretation these rules are part of the set of deductive rules adding additional type information. Consequences of this difference with respect to applications of RDFS are discussed in the final subsection.

4.1.4 Differences: Cycle constraints, range cardinality constraint.

These constraints (2.15, 2.16, 2.20, 2.21) from the old interpretation are not part of the MT and will be removed from the RDFS spec according to recent decisions of the RDF core working group.

4.1.5 Differences: SubProperty Completeness

$$\quad instanceOf(x,y) \Rightarrow statement(x,TYPE,y).$$ (3.16)

$$\quad subClassOf(x,y) \Rightarrow statement(x,SUBCLASSOF,y).$$ (3.17)

$$\quad subPropertyOf(x,y) \Rightarrow statement(x,SUBPROPERTYOF,y).$$ (3.18)

These rules have been added to the set of deductive rules in the new interpretation to reflect the instances of knowledge-level predicates at the graph level. These rules are not part of the old interpretation. This has a rather subtile consequence: if super properties of TYPE, SUBCLASSOF or SUBPROPERTYOF would be defined and if instances of $instanceOf$, $subClassOf$ or $subPropertyOf$ would be transitively infered, no additional statements with the super property as a predicate would be added and, thus, could not be used in further subproperty inferences. To fill this gap and to allow to maintain the difference between $instanceOf(x,y)$ and $statement(x,TYPE,y)$ for a correct treatment of literals, the following rules could be added to the old interpretation:

$$instanceOf(x,y), subPropertyOf(TYPE,p) \Rightarrow statement(x,p,y).$$ (4.1)

$$subClassOf(x,y), subPropertyOf(SUBCLASSOF,p) \Rightarrow statement(x,p,y).$$ (4.2)

$$subProperty(x,y), subPropertyOf(SUBPROPERTYOF,p) \Rightarrow statement(x,p,y).$$ (4.3)

There seem to be no other consequences of this omission.

4.2 Comparing the Facts

Setting aside the fact, that the MT draft does not contain reification, the differences between the two sets of factual RDF/RDFS knowledge is restricted to the following:

The new interpretation contains the following facts which are not part of the old interpretation.

(8) statement(DOMAIN,TYPE,PROPERTY).
(11) statement(RANGE,TYPE,PROPERTY).

To deal with range/domain, the old interpretation contains the following set of facts instead:

statement(RANGE,TYPE,CONSTRAINTPROPERTY).
statement(DOMAIN,TYPE,CONSTRAINTPROPERTY).
statement(CONSTRAINTRESOURCE,TYPE,CLASS).
statement(CONSTRAINTPROPERTY,TYPE,CLASS).
statement(CONSTRAINTPROPERTY,SUBCLASSOF,PROPERTY).
statement(CONSTRAINTPROPERTY,SUBCLASSOF,CONSTRAINTRESOURCE).

which allows to infer the above facts with the $instanceOf$ and $subClassOf$ rules.²⁵ Additionally, the old facts

statement(CLASS,SUBCLASSOF,RESOURCE).
statement(PROPERTY,SUBCLASSOF,RESOURCE).

are not part of the set of new facts, but follow from rule rdfs7 immediately.

With the exception of the facts that are consequences of the different interpretation of the concepts ConstraintResource/ConstraintProperty, no fact of the new interpretation is missing from the old interpretation.

4.3 Consequences

The most notable difference between the two interpretations is due to the different interpretation of the role of rdfs:range and rdfs:domain. In the new interpretation they are a device to infer type information. Note that the resulting $instanceOf$ information can also be expressed (from an extensional point of view) in both interpretations by means of rdf:type, rdfs:subclassOf or subproperties of the former. Expressing the integrity constraint interpretation of both properties in the new interpretation is not possible, though. From an extensional point of view, expressivity has been lost. Does this matter? We would tend to say ``Yes'', due to the following reasons:

(1) For example, the integrity constraint checking of the RDF Schema Explorer has been used beneficially in developing a vocabulary for role-based access control whose applications heavily rely on the detection of constraint violations (for some example of the RDFSec vocabulary, see [7,14]). Detecting the violation of range/domain constraints has also been an issue in the development of the validating RDF parser VRP (developed at ICS-Forth). It may be reasonable to assume that schema developers have frequently used rdfs:range and rdfs:domain to constrain the usage of properties.

(2) It has been argued that the disjunctive interpretation of multiple domain/range constraints²⁶may lead to non-monotonicities. While this is certainly true if the risk is not properly mitigated by knowledge base versioning, possible world considerations etc., it is also a risk for applications of the new interpretation. It seems as if ultimately, the type information resulting from computing a schema closure will be used to drive decisions in applications (otherwise the type/subclass hierarchy would be at a risk to be considered as an end in itself). Now, a typical question for such decisions will be: ``can resource x be used in function f?'', which boils down to do some type checking, ie to check whether x has an appropriate type, say, C. Now, the issue is twofold. First, this is exactly the type of question that could have been addressed in the old interpretation of RDFS directly with integrity constraints checking of range/domain constraints (a now lost opportunity). Second, answering this question may risk non-monotonicities (if the decision is based on positive information like [x TYPE C] then this decision may turn out to be wrong due to a subsequent correction of the underlying RDFS graph; if the decision is based on negative information like ``[x TYPE C] is not known'', this may turn out to be wrong once a more complete set of knowledge is rendered).

To summarize: the benefit of fixing the interpretation of rdfs:range and rdfs:domain as forwarded by the MT draft and the RDF core decisions seems questionable to us. At least, it violates backward combatibility²⁷.

4.4 Conclusion

Above, we have demonstrated that the core difference between the old and the new interpretation is the treatment of the rdfs:range and rdfs:domain properties. We have also shown that a horn interpretation of the RDF model theory allows to transform the conditions given there into a set of straightforwardly implementable rules. Additionally, this formalization can be used to proof, for example, the RDFS entailment lemma with means of fixpoint semantics for Datalog. The result of the paper will be incorporated into the RDF Schema Explorer (available online) to allow for a comparison of the effects of the different interpretation of RDFS-based vocabularies. This will allow developers to explore the consequences of the different rule sets resp. the different RDFS versions (ie, the candidate recommendation captured in the old interpretation and the upcoming new version of RDFS as captured in the new interpretation²⁸) and will help to adapt their RDF-based applications to the differences whenever possible. In this respect, the paper may help to keep the potentially negative effect of non-downwards compatible changes on the active RDF community as small as possible.

Bibliography

1

Intelligent Database Environment for Advanced Applications.
http://www.elet.polimi.it/idea/ methodology/design.htm.

2

Rule Markup Language.
http://www.dfki.uni-kl.de/ruleml/.

3

Discussions about the Logical Interpretation of RDF.
http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation/discussion.html, October 2000.

4

Dan Brickley and R.V. Guha.
Resource Description Framework (RDF) Schema Specification 1.0.
Candidate Recommendation, W3C, March 2000.
http://www.w3.org/TR/2000/CR-rdf-schema-20000327.

5

Wolfram Conen and Reinhold Klapsing.
A Logical Interpretation of RDF.
Linköping Electronic Articles in Computer and Information Science, ISSN 1401-9841, 5(13), December 2000.
http://www.ep.liu.se/ea/cis/2000/013/.

6

Wolfram Conen and Reinhold Klapsing.
Exchanging Semantics with RDF.
In 5. Internationale Tagung Wirtschaftsinformatik 2001, September 2001.

7

Wolfram Conen and Reinhold Klapsing.
Utilizing Host Formalisms to Extend RDF Semantics.
In Proceedings of the Semantic Web Working Symposium (SWWS), Stanford, August 2001.
http://www.semanticweb.org/SWWS/program/full/paper24.pdf.

8

Wolfram Conen, Reinhold Klapsing, and Eckhart Köppen.
RDF M&S revisited: From Reification to Nesting, from Containers to Lists, from Dialect to pure XML.
In Proceedings of the Semantic Web Working Symposium (SWWS), Stanford, August 2001.
http://www.semanticweb.org/SWWS/program/full/paper27.pdf.

9

Patrick Hayes.
RDF Model Theory.
Editor's Working Draft (updates W3C Public Working Draft - 20010925), November 2001.
http://nestroy.wi-inf.uni-essen.de/rdf/working-draft-mt-retrived-05-11-2001-12:00-GMT.ps.

10

Reinhold Klapsing, Gustaf Neumann, and Wolfram Conen.
Semantics in Web Engineering: Applying the Resource Description Framework.
IEEE MultiMedia, 8(2):62-68, April-June 2001.

11

Ora Lassila and Ralph R. Swick.
Resource Description Framework (RDF) Model and Syntax Specification.
Recommendation, W3C, February 1999.
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.

12

W. Nejdl, H. Dhraief, and M. Wolpers.
O-Telos-RDF: A Resource Description Format with Enhanced Meta-Modeling Functionalities based on O-Telos.
In Proceedings of the Workshop on Knowledge Markup and Semantic Annotation at the First International Conference on Knowledge Capture (K-CAP'2001), Canada, October 2001.
http://www.kbs.uni-hannover.de/Arbeiten/Publikationen/2001/kcap01_final.pdf.

13

Ulrich Reimer.
Einführung in die Wissensrepräsentation.
Leitfäden der angewandten Informatik. Teubner, 1991.

14

Web-based RDF Schema Explorer.
http://wonkituck.wi-inf.uni-essen.de/rdfs.html.

15

Jeffrey D. Ullman.
Principles of Database & Knowledge-Base Systems.
W.H. Freeman & Company, March 1988.

Appendix

Rule set for the new interpretation:

$$\quad statement(s,p,o) \Rightarrow instanceOf(p,PROPERTY).$$ (3.1)

$$\quad statement(p,DOMAIN,c) \Rightarrow domain(c,p).$$ (3.2)

$$\quad statement(s,p,o) \wedge domain(c,p) \Rightarrow instanceOf(s,c).$$ (3.3)

$$\quad statement(p,RANGE,c) \Rightarrow range(c,p).$$ (3.4)

$$\quad statement(s,p,o) \wedge \neg lit(o) \wedge range(c,p) \Rightarrow instanceOf(o,c).$$ (3.5)

$$\quad statement(s,p,o) \Rightarrow instanceOf(s,RESOURCE).$$ (3.6)

$$\quad statement(s,p,o) \wedge \neg lit(o) \Rightarrow statement(o,TYPE,RESOURCE).$$ (3.7)

$$\quad statement(p1,SUBPROPERTYOF,p2) \Rightarrow subPropertyOf(p1,p2).$$ (3.8)

$$\quad subPropertyOf(p1,p2) \wedge subPropertyOf(p2,p3) \Rightarrow subPropertyOf(p1,p3).$$ (3.9)

$$\quad statement(s,p1,o) \wedge subPropertyOf(p1,p2) \Rightarrow statement(s,p2,o).$$ (3.10)

$$\quad instanceOf(x,CLASS) \Rightarrow subclassOf(x,RESOURCE).$$ (3.11)

$$\quad statement(c1,SUBCLASSOF,c2) \Rightarrow subClassOf(c1,c2).$$ (3.12)

$$\quad subClassOf(c1,c2) \wedge subClassOf(c2,c3) \Rightarrow subClassOf(c1,c3).$$ (3.13)

$$\quad statement(i,TYPE,c) \Rightarrow instanceOf(i,c).$$ (3.14)

$$\quad instanceOf(i,c1) \wedge subClassOf(c1,c2) \Rightarrow instanceOf(i,c2).$$ (3.15)

$$\quad instanceOf(x,y) \Rightarrow statement(x,TYPE,y).$$ (3.16)

$$\quad subClassOf(x,y) \Rightarrow statement(x,SUBCLASSOF,y).$$ (3.17)

$$\quad subPropertyOf(x,y) \Rightarrow statement(x,SUBPROPERTYOF,y).$$ (3.18)

Rule set for the old interpretation:

$${\text (2.1) } \quad statement(s,p,o) \Rightarrow res(s) \wedge uri(p) \wedge obj(o)$$

$${\text (2.2) } \quad uri(r) \Rightarrow res(r)$$

$${\text (2.3) } \quad obj(o) \wedge \neg res(o) \Rightarrow lit(o)$$

$${\text (2.4) } \quad lit(o) \Rightarrow instanceOf(o,LITERAL)$$

$${\text (2.5) } \quad res(s) \wedge uri(p) \wedge statement(s',TYPE,STATEMENT) \wedge \; statement(s',SUBJECT,s)$$

$$\quad\quad\quad \wedge \; statement(s', PREDICATE,p) \wedge \; statement(s',OBJECT,o)$$

$$\quad\quad\quad \quad \quad \quad \Rightarrow reifies(s',s,p,o)$$

$${\text (2.6) } \quad reifies(s',s,p,o) \Rightarrow reifyingStatement(s')$$

$${\text (2.7) } \quad reifies(s',s,p,o) \wedge statement(s,p,o) \Rightarrow reifies\_fact(s',s,p,o)$$

$${\text (2.8) } \quad statement(i,TYPE,c) \Rightarrow instanceOf(i,c)$$

$${\text (2.9) } \quad statement(c1,SUBCLASSOF,c2) \Rightarrow subClassOf(c1,c2)$$

$${\text (2.10) } \quad subClassOf(c1,c2) \wedge subClassOf(c2,c3) \Rightarrow subClassOf(c1,c3)$$

$${\text (2.11) } \quad instanceOf(i,c1) \wedge subClassOf(c1,c2) \Rightarrow instanceOf(i,c2)$$

$${\text (2.12) } \quad statement(p1,SUBPROPERTYOF,p2) \Rightarrow subPropertyOf(p1,p2)$$

$${\text (2.13) } \quad subPropertyOf(p1,p2) \wedge subPropertyOf(p2,p3) \Rightarrow subPropertyOf(p1,p3)$$

$${\text (2.14) } \quad statement(s,p1,o) \wedge subPropertyOf(p1,p2) \Rightarrow statement(s,p2,o)$$

$${\text (2.15) } \quad subClassOf(c1,c2) \wedge c1 = c2 \Rightarrow subclass\_cycle\_violation(c1)$$

$${\text (2.16) } \quad subPropertyOf(p1,p2) \wedge p1 = p2 \Rightarrow subproperty\_cycle\_violation(p1)$$

$${\text (2.17) } \quad statement(p,DOMAIN,c) \wedge instanceOf(i,c) \Rightarrow domain(i,p)$$

$${\text (2.18) } \quad statement(p,DOMAIN,c) \Rightarrow domain\_constrained\_prop(p)$$

$${\text (2.19) } \quad statement(s,p,o) \wedge domain\_constrained\_prop(p) \wedge \neg domain(s,p)$$

$$\quad \quad\quad\quad \Rightarrow domain\_violation(s,p,o)$$

$${\text (2.20) } \quad statement(p,RANGE,o) \Rightarrow is\_range(o,p)$$

$${\text (2.21) } \quad is\_range(r1,p) \wedge is\_range(r2,p) \wedge (r1 \not= r2) \Rightarrow range\_cardinality\_violation(p)$$

$${\text (2.22) } \quad is\_range(r,p) \Rightarrow has\_range(p)$$

$${\text (2.23) } \quad statement(s,p,o) \wedge instanceOf(o,c) \wedge \; is\_range(c,p) \Rightarrow range(o,p)$$

$${\text (2.24) } \quad statement(s,p,o) \wedge has\_range(p) \wedge \; \neg range(o,p) \Rightarrow range\_violation(s,p,o)$$

About this document ...

Logical Interpretations of RDFS - A Compatibility Guide

This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.42)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -debug -split 0 -no_navigation -show_section_numbers -dir ./html paper.tex

The translation was initiated by Reinhold Klapsing on 2001-11-15

Footnotes

... Group¹

Which none of us is a member of.

...Model_Theory.²

We will also update the RDF Schema Explorer to allow to choose/mix the interpretations when developing schemata.

...CONKLA2000a.³

Readers who are already familiar with the old interpretation may pretty safely skip Section 2.

... rules⁴

Two additional remarks: We will make very limited use of (stratifiable) negation and we will leave out the all-quantifications for readability.

... rules⁵

Note that containers will not be treated in the following. We will also not truely consider anonymous resources.

... URI⁶

In [5], we introduced a predicate rfc2396_conform to be able to check, if a graph conforms to condition (6). We also discuss in [5] why requiring URI labels on resource nodes is not really a good idea. We leave this out here to keep the presentation simple. For details, please have a look at [5].

... URIs.⁷

Abbreviations shall be expanded using either the rdf- (for TYPE, PROPERTY, STATEMENT, SUBJECT, PREDICATE, OBJECT) or rdfs-namespaces, compare [5].

... different.⁸

For the Schema Explorer, the rules $res(s) \Rightarrow instanceOf(s,RESOURCE)$ and $statement(s,p,o) \Rightarrow instanceOf(p,PROPERTY)$ have been added to avoid the frequent violation of the domain constraint for ranges and domains due to potentially incomplete knowledge about the schemata which define constrained properties.

... [RDFS-Definition:]⁹

When be speak of RDFS-Definitions, we cite directly the RDFS candidate recommendation [4].

... 0.2:]¹⁰

When be use such MT labels, we cite directly an editor's version of the RDF Model Theory draft [9] from early November 2001.

... variables.¹¹

Though this would be a nice feature from a logical perspective, it does not seem to correspond to the usage of anonymous nodes in the examples with reification of descriptions (Section 4.1 of [11]) and the examples of the usage of rdf:value (Section 7.3 of [11]), where the anonymous node are essentially a means to express structural information and could easily be eliminated in an ``extended model'' perception of RDF (viewing descriptions as lists of, potentially nested, statements - [8], and certain rdf:value constructs as structures with named, nested properties). We will not discuss this further in this document. Those readers who like this aspect of the model theory,may think of the following as being restricted to ground RDF graphs (however, this is not an entirely correct assumption).

... triples.¹²

Without introducing a suitable mechanism (in RDF) for recognizing asserted triples, introducing asserted triples seems to be a little bit too speculative. Such a mechanism could rely on a suitable interpretation of reification and the definition of the semantics of properties that control the scope of statements embedded into their extension, as has been briefly discussed in [8]. This interprets RDF as being a way to encode with flat triples an extended ``data model'', with nesting (reification) and lists (containers) and possibly structures (rdf:value) and differs in this respect fundamentally from the assumptions of [9]. While this discussion is, from our point of view, interesting and necessary, it is not the scope of this paper.

... rules¹³

MT, Sec. 1.3:

• if E is a literal then I(E) = XL(E)
• if E is a URI then I(E) = IS(E)
• if E is an asserted triple s p o . then I(E) = true if $<$I(s),I(o)$>$ is in IEXT(I(p)), otherwise I(E)= false.
• if E is a ground RDF graph then I(E) = false if I(E') = false for some asserted triple E' in E, otherwise I(E) =true

- Note that with the above assumption, every triple in E is an asserted triple.

... rdfs3:¹⁴

Remark: $lit(o)$ encodes the above note from the MT about the nature of uuu. Note that this predicate requires essentially that some extra-logical functionality is available to distinguish ``real'' URI labels from other labels (including literals that look like URIs). See the discussion in the comparison (Sec. 4) for further details.

... rule¹⁵

Note that rule rdfs5 is not necessary to capture the consequences of transitive subproperty relations - iterating rdfs6 does suffice. It is only useful to make such transitive subproperty relations explicit. Though, as the MT does not require an equivalence between the predicate extension of the interpretation of rdfs:subPropertyOf and the subset relations between predicate extension, leaving the rule aside would do no harm with respect to the conditions on RDFS interpretations. An analogous reasoning could be applied to rule rdfs8.

...rdfs10¹⁶

The rule was problematic anyway. It should have been an equivalence to fulfill the interpretation condition on ConstraintResources in the MT draft. Furthermore, two subClass facts did not follow (e.g. rfds:ConstraintProperty rdfs:SubClass rdfs:Property) and the semantic content was questionable (why should every resource that is a constraint resource and that is also used as a property be a constraint property). However, this considerations will be obsoleted once the decisions of the RDF core working group are captured in the RDFS spec and in the MT.

... consequences¹⁷

In the sense that every least fixpoint model for the above rules and facts satisfies the following conditions

... entails¹⁸

Read: (simply) entails (Remark from the authors)

... surjective)¹⁹

Otherwise, IR can be arbitrarily larger than the range (Bild) of the mapping IS. Without this condition, $ICEXT(I(rdfs:Resource) = RANGE(IS)$ would seem to be a more harmless claim - the problem is that the entailment lemma in the given form will not hold generally for the given condition. The two potential problems are caused by elements of IR for which there is no element of V that is mapped to it and singular nodes.

... formulated²⁰

For purists, $\Leftrightarrow$ can be resolved into two conjunctively concatenated rules with $\Rightarrow$ and $\Leftarrow$.

... true.²¹

The closure rules do not add elements to the class extension of rdfs:Literal, thus we may assume that the class extension is empty which would satisfy the condition (though this does certainly not capture the intension). Another solution would be to require that the mapping XL is used to add appropriate tuples into the extension of the interpretation of rdf:type and to assert this as a sort of ``higher'' closure rule.

....²²

In a model theory, this could be captured by introducing a new relation which corresponds to $instanceOf$ into which the extension of the interpretation of rdf:type is mapped and that additionally contains the XL mapping (to use MT terminology). This would allow for a clearer solution of the literal problem.

... literal.²³

This can be seen as implicitly assuming an universe, U, underlying the axiomatization that is divided by the use of properties in RDF documents into the disjoint sets Resources and Literals.

... to²⁴

For example, if (1) would be directly seen as an integrity constraint, we would test whether a model that we have computed for the sets of facts and deductive rules satisfies also this constraint. A simple example can demonstrate that this is not always the case for the old interpretation. Furthermore, it can straightforwardly be shown that the rules (2.17-2.19) allow to deduce a domain violation if and only if the above integrity constraints is not satisfied by a Herbrand model of the knowledge base consisting of the facts and deductive rules given in Section 2.

... rules.²⁵

To conform to the removal of ConstraintResource and ConstraitProperty the facts in the old version can be removed and the facts 8 and 11 from the new version can be added.

... constraints²⁶

With the old integrity-constraints interpretation, a conjunctive interpretation would immediately be severely non-monotonic and, furthermore, not be easily motivatable.

... combatibility²⁷

Though some may say that [4] is a candidate recommendation only. But it has been in this state for quite some time and developers started to use RDF/RDFS as specified in the available documents, so one may also perceive [4] (especially given the minor changes to the previous version) as a de-facto recommendation.

... interpretation²⁸

As the RDF core working group has already closed most issues related to the RDFS vocabulary and as we expect that these decision will find their way into new versions of the RDFS spec and the MT draft, the work presented here should not outdate too soon. It will also be continously adapted to not foreseen changes in a version available online at http://nestroy.wi-inf.uni-essen.de/rdf/new_interpretation.