6.4 Formalizing the Vocabulary with RDFS

Formally defined RDFS schemas aren't required for all RDF documents, but the schema approach guarantees that a particular RDF document is semantically and syntactically consistent across implementations.

RDFS defines which vocabulary elements are classes and which are properties. In addition, RDFS also matches a property with a specific element, as well as defining the range for each property. This is particularly helpful when defining properties that contain a range of elements, such as the pstcn:movementType property in the last section. RDFS also documents the type of literal that each property can reference—whether the property value is a string or a number, such as an integer.

6.4.1 What Is a Class and What Is a Property?

Determining what is a class and what is a property within the vocabulary is an interesting RDF Schema challenge. Your first reaction might be that an RDFS Class is equivalent to a relational data model Entity, but that doesn't hold.

In actuality, an RDFS Class is any item that can be used in place of an rdf:Description block, with an associated rdf:type, such as Movement or Resource. An RDFS Class is not a resource property, like bio, Presentation, or Relevancy.

A quick test to double-check your use of RDFS Class versus RDFS Property for an item is to use ICS-FORTH's Validating RDF Parser (VRP), asking for a graph output on the test RDF/XML document. This tool actually identifies which elements it views as classes and which as properties. This tool is covered in Chapter 7.

6.4.2 Defining the Vocabulary Classes

To start, define the PostCon vocabulary classes. Table 6-1 shows that the classes mark the main objects defined within the table, as you would expect. Using RDFS, then, the main object of the vocabulary, Resource, is defined with the following RDF/XML syntax:

<rdfs:Class rdf:about="http://burningbird.net/postcon/elements/1.0/Resource">
 <rdfs:isDefinedBy rdf:resource="http://burningbird.net/postcon/elements/1.0/"/>
 <rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>
 <rdfs:label xml:lang="en"> Web Resource</rdfs:label>
 <rdfs:comment xml:lang="en">
    Web resource managed with PostCon System
 </rdfs:comment>
</rdfs:Class>

This RDF/XML defines Resource to be an RDF Class, defined within the schema http://burningbird.net/postcon/elements/1.0/, which is a subclass of the RDF Resource type. Its human-readable label is Web Resource, and the comments provide a brief description of the item. Both label and comments have an xml:lang attribute defining the language. If you're providing multilingual support for your elements, repeat the label and comments but change the xml:lang attribute value.

Though things such as label and comments aren't necessary for the schema, you should always include these. BrownSauce, a Java-based RDF browser (described in Chapter 7), provides this information to people browsing RDF/XML documents.

This class by itself demonstrates the need for namespaces within RDF/XML; the RDF vocabulary also has a Resource class. The same type of RDFS/XML is also applied to bio, Movement, Relevancy, and Presentation, all of which are defined as classes. All other elements are defined as properties.

6.4.3 Defining the Properties

Each property within the vocabulary is defined, including providing data type information, human-readable comments and labels, and a definition of the relationship between properties and classes. The latter is particularly important because it provides usage guidelines as well as understanding of the schema.

An example of a property definition for PostCon is the following, for type:

<rdf:Property rdf:about="http://burningbird.net/postcon/elements/1.0/type">
 <rdfs:isDefinedBy rdf:resource="http://burningbird.net/postcon/elements/1.0/"/>
 <rdfs:label xml:lang="en">Resource Type</rdfs:label>
 <rdfs:comment>Type of Required Resource</rdfs:comment>
 <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</rdf:Property>

The type element has a range that determines the type of values associated with it. In this case, the range is literal, meaning the element will contain literal values. In addition, there are two domains associated with the title that show the classes the property is associated with: bio and Movement.

The other properties are defined using almost the same schema, changing the label, comments, and domain as appropriate; the two properties history and related are different from the other properties, though, because they don't describe a literal. For instance, here is the definition for the related property:

<rdf:Property rdf:about="http://burningbird.net/postcon/elements/1.0/related">
 <rdfs:isDefinedBy rdf:resource="http://burningbird.net/postcon/elements/1.0/"/>
 <rdfs:label xml:lang="en"> Related Resource</rdfs:label>
 <rdfs:comment xml:lang="en">
    Resources within PostCon system related to current resource
 </rdfs:comment>
 <rdfs:range rdf:resource="http://burningbird.net/postcon/elements/1.0/Resource"/>
 <rdfs:domain rdf:resource="http://burningbird.net/postcon/elements/1.0/Resource"/>
</rdf:Property>

The predicate object associated with related is a resource of class Movement. Other than that, though, the definition is fairly close to how all the properties are defined.

The complete schema is shown in the next section. Note that testing the schema within the RDF Validator does prove that the RDF Schema is valid RDF/XML. The resultant RDF graph is a bit hard to read, though—all those references to the same RDFS classes.

Certain of the properties in the schema have an "allowable values are..." within them. There is currently no way to constrain allowable literals within the RDF Schema. However, since the schema is used more for human rather than machine interpretation, including this information within the comment is useful.

A vocabulary schema defines vocabulary elements and their relationship with one another and with the RDF and RDFS elements. For instance, since the PostCon schema document is a resource, using the PostCon vocabulary elements within the document to detail its creation is perfectly acceptable.

This approach is used within another widely used vocabulary, the Dublin Core (DC), which we will look at next and compare to the PostCon vocabulary. We'll also find that we can modify PostCon to make use of DC elements, simplifying it.