Although the intention of RDF is to provide an open, minimally constraining way for representing information, there exists an increasing number of applications for which guarantees on the structure and values of an RDF data set become desirable if not essential. What is missing in this respect are mechanisms to tie RDF data to quality guarantees akin to schemata of relational databases, or DTDs in XML, in particular when translating legacy data coming with a rich set of integrity constraints { like keys or cardinality restrictions { into RDF. Addressing this shortcoming, we present the RDF Data Description language (RDD), which makes it possible to specify instance-level data constraints over RDF. Making such constraints explicit does not only help in asserting and maintaining data quality, but also opens up new optimization opportunities for query engines and, most importantly, makes query formulation a lot easier for users and system developers. We present design goals, syntax, and a formal, First-order logics based semantics of RDDs and discuss the impact on consuming Linked Data.
Since the early days of relational databases, constraints have been
considered essential to specify the intended states of the data sets representing
the information of certain applications [
As an example, consider the work on mapping relational databases
to RDF from the W3C's Direct Mapping and R2RML initiatives [
Contributions. After motivating the need to enable end users in
writing precise SPARQL queries in Section 2, we present the RDF Data
Description language, RDD, to de ne constraints over RDF, akin to
DTDs for XML. We then discuss design decisions and related work in
Section 3, identifying the need for RDDs to be both user-readable and
machine-processable. Next, we elaborate on the con ict between the Open
World Assumption underlying RDF(S) and the requirements of a hard
constraint language, concluding that RDDs shall support a pay-as-you-go
paradigm in constraining RDF(S). Section 4 formalizes RDDs by means of
a user-friendly syntax that captures a broad range of constraints
including keys, cardinalities, subclass, and subproperty restrictions. Section 5
presents a First-order Logics semantics, making it easy to implement
RDD checkers and clearing the way for optimizations. Finally, in
Section 6 we discuss directions of future research, including the
implementation, coverage, extensibility, and relationship to standards like VoID [
As a motivating example, assume a developer wants to write a SPARQL query that extracts information about persons in an RDF document, described by properties rdfs:label (denoting the name), foaf:age, and foaf:mbox (mail address) { where every person shall be represented by exactly one row of the result table.3 While this sounds like a fairly trivial 3 In fact, the problem is a slightly modi ed example one of the authors recently encountered in the context of an industrial project. task (in SQL, with a reasonable schema, this could probably be expressed by a simple query like SELECT id, name, age, email FROM Person), with the unconstrained RDF model this may become quite tricky, even if the schema (i.e., FOAF and RDF(S) vocabulary) is well known to the developer: without further knowledge about the instance data, the developer cannot be sure which predicates are present at all, and which of them may be multi-valued. Making guesses that rdfs:label and foaf:age are single-valued, the developer may nally come up with the following query: SELECT ?person ?name ?age (GROUP_CONCAT(?mail; separator=", ") AS ?mail) WHERE { ?person rdf:type foaf:Person .
OPTIONAL { ?person rdfs:label ?name } OPTIONAL { ?person foaf:age ?age }
OPTIONAL { ?person foaf:mbox ?mail } } GROUP BY ?name ?age
The OPTIONAL clauses ensure that persons with incomplete information are included in the result; to group persons with multiple email addresses, the developer used GROUP BY combined with GROUP_CONCAT in the SELECT clause, thus concatenating all email addresses of a single person. The crucial point here is that even this simple task leads to a quite complex query covering the \worst case scenario" anticipated by the developer, requiring the use of advanced SPARQL 1.1 constructs (which, as a matter of fact, are hard to optimize by query engines). And even this carefully designed query leads to multiple result rows for the same person in the presence of multiple labels (e.g., with di erent language tags).
What is needed to ease SPARQL query development is a data description that describes the structural constraints of the instance data beyond the schema information contained in the underlying RDF(S) speci cation and ontologies, which the developer can consult when writing queries. The RDD language advocated in this paper was designed with exactly this goal in mind. RDD would allow the data publisher to express the instance data constraints by means of a well-de ned, human readable language.
Figure 1 depicts an example RDD that, when tied to a speci c RDF database, helps the developer in understanding the constraints that hold on instance level. With respect to the concept foaf:Person, the rst part of the RDD in Figure 1 (left) speci es a set of constraints that are known to hold for every instance of the class. Summarizing the relevant part of the RDD, it tells the developer that the property rdfs:label serves as a key for persons, every person has exactly one foaf:email property (keyword TOTAL), and every person has at most one foaf:age (keyword FUNCTIONAL). Further, all theses three properties point to literals, the latter being of type xsd:integer { this may be useful information when writing e.g. aggregation queries over the age, or when post-formatting the results. PREFIX ex: <http://www.example.com#> ...
CWA CLASSES { OWA CLASS foaf:Person SUBCLASS ex:Student {
KEY rdfs:label : LITERAL TOTAL foaf:email : LITERAL FUNCTIONAL foaf:age : LITERAL(xsd:integer) RANGE(foaf:Person) foaf:knows : IRI } } OWA CLASS ex:Student {
TOTAL ex:matricNr : LITERAL(xsd:integer) MIN(1), RANGE(ex:Course) ex:course : RESOURCE PATH(ex:course/ex:givenBy), RANGE(foaf:Person)
ex:taughtBy : IRI } OWA PROPERTIES {
TOTAL rdfs:label foaf:knows SUBPROPERTY ex:taughtBy }
With the RDD speci cation at hand { which can be understood in few seconds { the developer can considerably simplify the query: SELECT ?person ?name ?age ?mail .
WHERE { ?person rdf:type foaf:Person ; rdfs:label ?name ; foaf:mbox ?mail .
OPTIONAL { ?person foaf:age ?age } }
Even if the developer is not aware of the RDD and comes up with a query that uses, e.g., redundant OPTIONAL blocks, the RDD may still be used by the optimizer to simplify the query and speed up evaluation. 3
Philosophy. RDDs specify constraints that hold in an RDF data set. However, not to loose RDF's minimally constraining way for representing information { where one may interlink and extend data sets by adding new information { they shall not require the structure of RDF to be de ned completely, but give a pragmatic answer to these two con icting design goals in that they adhere to RDF's Open World character following a pay-as-you-go paradigm, which allows users to impose constraints only on a subset of classes, or to constrain classes and properties only partially.
Designed for Humans. To make it easy for humans to understand, write, and use RDDs as a guide when writing queries, RDDs shall come with a user-understandable syntax. To this end, we use an object-oriented approach closely aligned to the RDF(S) data model, reusing concepts like classes, properties, and subclass/subproperty relationships. An RDF serialization of RDDs is out of the scope of this paper (cf. Section 6).
Scope. The importance of constraints for RDF(S) has recently been
emphasized in the context of REST-based enterprise applications [
Enabling the targeted restriction of RDF(S) constructs, RDDs
provide built-in constructs to express constraints over classes, subclasses, and
properties such as domain, range, or cardinality restrictions. In the light
of the Direct Mapping and R2RML standards [
RDF data is often equipped with RDFS or OWL axioms and may
be interpreted in di erent entailment regimes. Dedicated studies of
constraints in the context of OWL have been presented in [
Formal Semantics. While a SPARQL-based semantics may seem
like a natural choice (cf. [
Figure 1 provides an example RDD. The de nition for class foaf:Person contains the constraints for predicates rdfs:label, foaf:email, and foaf:age discussed in Sec. 2, plus a constraint expressing that predicate foaf:knows, when used for an instances of type foaf:Person, points to instances of type foaf:Person, which are always IRIs (i.e., not blank nodes). In the spirit of RDF, this does not enforce referred objects to be exclusively typed as foaf:Person, but only that one edge typing the object as foaf:Person is present. The OWA keyword (short for Open World Assumption) in front of the CLASS de nition allows persons to have further properties not listed in the class speci cation; its counterpart, keyword CWA, would enforce that the class is closed in the sense that class instances are completely described by the properties occurring in the CLASS section. Further, foaf:Person has a subclass ex:Student (keyword SUBCLASS). With RDDs focusing on instance-level constraints, this does not enforce a triple (ex:Student, rdfs:subClassOf, foaf:Person) in the data, but guarantees that every ex:Student satis es the same constraints as foaf:Persons.
Similar in spirit, the CLASS de nition for ex:Student guarantees that (i) ex:matricNr is a TOTAL property, i.e. every student has exactly one matriculation number, (ii) ex:course occurs at least once and has RANGE ex:Course, and (iii) the PATH and RANGE constraints de ned for property ex:taughtBy asserts that, for every ex:Student, there is a property path along the edges ex:course followed by ex:givenBy pointing to the same value of type foaf:Person as property ex:taughtBy. Path constraints are special kinds of inclusion constraint, similar in spirit to foreign keys.
The surrounding CLASSES section is de ned as CWA, guaranteeing completeness in the sense that the data contains only instances of the two classes foaf:Person and ex:Student. Subsequently, the RDD contains a PROPERTIES section constraining properties in an unquali ed, global way. The rst entry, TOTAL rdfs:label, ensures that every Resource has exactly one label { a useful information for query authors. The SUBPROPERTY spec, targeting the instance level again, ensures that, for every triple (X,ex:taughtBy,Y) in the data, there is an implied triple (X,foaf:knows,Y). Finally, the OWA keyword of the PROPERTIES section expresses that there may be other properties than those listed in the section.
Rather than presenting the concrete syntax (see the Technical
Report [
Central to the RDD concept is the notion of PropConstraints, an abstract concept that is further subclassed into speci c subclasses:
RDD ccs : ClassConstraintSec pcs : PropConstraintSec
ClassConstraintSec ccs : List<ClassConstraint> isOWA : Boolean
ClassConstraint class : IRI subClasses : List<IRI> isSingleton : Boolean isOWA : Boolean keys : List<Key> qpcs : List<PropertyConstraint>
Key keyProps : List<IRI>
PropConstraintSec upcs : List<PropConstraint> isOWA : Boolean
PropConstraint (abstract) prop : IRI TotalityConstraint
FunctionalityConstraint
RangeTypeConstraint rangeType: RangeType
MinConstraint nr : Integer
MaxConstraint nr : Integer
DomainConstraint domain : IRI
RangeConstraint range : IRI
PathConstraint path : List<IRI>
SubPropertyConstraint subProps : List<IRI> { A RangeTypeConstraint indicates that the property prop points to either a URI, BlankNode, Resource, or a (possibly typed) Literal. { A Min/MaxConstraint indicates that the property prop occurs at least or at most nr times, respectively. { A Domain/RangeConstraint indicates a guaranteed domain or range for subject and objects associated with prop, respectively. { A PathConstraint indicates that the value of prop can as well be reached by following a given path of properties. { A SubPropertyConstraint indicates that for every triple using property subProp, there is also an identical triple using property prop. { Functionality/TotalityConstraints express that prop occurs at most or exactly one time, respectively.
PropConstraints are used in two di erent contexts: (1) The PropConstraintSec (cf. keyword PROPERTIES) contains a list upcs of PropConstraints, implementing unquali ed, global characteristics of properties. For instance, the TotalityConstraint in Fig. 1 (keyword TOTAL) for prop :=rdfs:label asserts that every resource has exactly one label. (2) Variable qpcs inside ClassConstraints represents quali ed, classspeci c PropConstraints, e.g. the MinConstraint (keyword MIN) for prop :=ex:course and nr := 1 in Fig. 1 in the class section of ex:Student ensures that every instance of ex:Student visits at least one course.
In addition to qpcs, a ClassConstraint contains (i) a list of subclasses (keyword SUBCLASS), enforcing that instances of the subclasses inherit inner constraints of the superclass, (ii) a boolean ag isSingleton, enforcing that exactly one instance of the class exists, (iii) the isOWA ag, and (iv) a list of keys. We sketch their semantics in the next section.
The semantics, denoted by JrKE , decomposes an RDD r into constraints that can be checked individually and independently. It uses an environment E capturing SUBCLASS and SUBPROPERTY relations speci ed in the RDD. The result is a set of in First-order Logics (FOL) constraints over relation TD(s; p; o) representing the RDF triples in RDF document D. With J.KE at hand, we de ne the notion of consistency as follows. De nition 1. Let D be an RDF document and r be an RDD speci cation. Further let cs := JrKE be the set of rst-order logic constraints de ned by r. Document D is consistent w.r.t. r if and only if for all constraints c 2 cs it holds that c is valid in TD, i.e. TD j= c.
The evaluation function J.KE is de ned by about 40 rules along the
structure of RDDs. At top-level, an RDD is decomposed into its
ClassConstraintSec and PropConstraintSec (i.e., the members of class
RDD, cf. Fig. 2), which are then further decomposed by dedicated rules.
At the core are inference rules mapping the individual constraints { e.g.,
the PropConstraint subclasses { into FOL. We sketch the idea of the
evaluation and refer to the TR [
Let us exemplarily discuss the inference rule for ClassConstraints, which derives constraints for its key and property constraints, as well as its global \con guration", namely, the subclass hierarchy, whether it is de ned as singleton, and whether it is de ned under Open or Closed World Assumption. According to Figure 2, the ClassConstraint is represented by a structure (class,subClasses,isSingleton,keys,qpcs,isOWA). cssc :=
cssingleton :=J(class, isSingleton) : SingletonKE [ J(csc,false,E:C(csc),keys,cpcs,true) : ClassConstraintKE csc2subClascsseskey := [
csqpcs := [ key2keys
J(class,cpc) : ClassPropConstraintKE cpc2cpcs cswa :=J(class, E:A(class), isOWA) : OWAP KE J(class : IRI, subClasses : ListhIRI i, isSingleton : Boolean, keys : ListhKeyi, qpcs : ListhPropConstrainti, isOWA : Boolean) : ClassConstraintK `
cssingleton [ cssc [ cskey [ csqpcs [ cswa
Starting with the conclusion, the result of evaluating the ClassConstraint is the union of the constraint sets cssingleton, cssc, : : : ; the premise of the rule describes how these constraint sets are calculated. The constraint set cssingleton, for instance, is obtained by evaluating a substructure Singleton with class IRI and the isSingleton ag as argument { if isSingleton=true, this substructure generates a constraint enforcing that the class has exactly one instance. The scheme for computing cswa, cskey and the quali ed PropConstraints csqpcs are analogous. Most interesting is the computation of cssc, which captures the inheritance of constraints to subclasses. It is obtained by evaluating a replicated version of the class constraint for every subclass csc. In these replicas, we pass the keys and cpcs constraints, and consult environment E to obtain the subclasses of the csc. Note that we neither inherit the singleton constraint (passing isSingleton:=false) nor impose a CWA constraint on the subclass (passing isOWA=true); this gives the RDD designer greater exibility.
To conclude, let us sketch the evaluation of a quali ed RangeConstraint as one of the constraint-generating rules. The rule below implements such a constraint for property p with range R for class C: the resulting formula enforces that for every instance s of class C, every value o referenced by p is of type R. Note the di erence toward RDFS: while predicate rdfs:range is similar by idea, it does not enforce the presence of such a triple, but sets up a rule that generates/completes the data { the constraint guarantees the presence of such a triple in the database.
f8s; o(TD(s; rdf:type; C) ^ TD(s; p; o) ! TD(o; rdf:type; R))g 6
RDDs constitute a powerful mechanism to describe instance-level
constraints and help both humans { when writing SPARQL queries { and
engines { which may exploit RDDs with its concise semantics to assert
data consistency and optimize queries (cf. [
Implementation. Given the First-order semantics, it is
straightforward to build a constraint checker using existing FOL engines. In the
context of SPARQL engines, though, it may be favorable to implement
checkers by means of SPARQL Ask queries. The close connection
between SPARQL and logics-based formalisms has been pointed out in
several works [
Deriving RDDs. An interesting topic is the derivation of RDDs
from instance data or { when the data has been obtained from relational
systems [
Coverage and Extensibility. Since the early years of database
research, various classes of constraints have been investigated (see e.g. [
As a side note, we want to point out that we intentionally did not
include foreign keys as proposed in [
We may want to express disjunction in other contexts, e.g. over range restrictions.
Other applications. RDDs can be exploited for use cases beyond query formulation, semantic query optimization, and quality assurance. For instance, the constraints encoded in RDDs may give valuable input for schema mapping and alignment. As another example, RDDs could be used to derive precise data input forms, and thus help in producing data.
RDD and Linked Open Data. Constraint checking, at rst glance, may look like a local task. However, as RDF resources being identi ed by IRIs are globally unique, local checking of constraints for certain constraints classes may not be su cient. Assume an inclusion dependency, say a range constraint r, is violated in data set R1, however the violating resource exists and is typed accordingly in a data set R2. According to the principles of Linked Open Data, r should not be declared to be violated.
We conclude that constraint checking in an LOD environment in general requires us to consider the constraints of all involved data sets. Even though this does not make constraint checking inapplicable, it may require novel ways and paradigms to specify and check constraints in the context of an open world, with possibly incomplete knowledge. We leave a closer investigation of these issues for future work.
Publishing of RDDs. As a bridge between the publishers and users
of RDF data, W3C proposes the VoID vocabulary (Vocabulary of
Interlinked Datasets) [
Standardization. The next steps we plan are the implementation of the RDD language by means of a SPARQL query generator that outputs the Ask queries for checking RDDs, which would make RDDs immediately usable by any SPARQL engine. Further, we are investigating di erent ways to standardize the proposed language, e.g. as part of the W3C standardization activities in the semantic technology space. Acknowledgments. This work was supported by the German Federal Ministry of Economics and Technology as part of the project \Durchblick ", grant KF2587503BZ2, and by Deutsche Forschungsgesellschaft as part of the project \CORSOS ", grant LA 598/7-1.
The authors want to thank Peter Haase and Michael Meier for fruitful discussions and the anonymous reviewers for their constructive feedback.