Literals, blank nodes, n-ary relations and rdf:value

A literal node is a specific type of a node because it represents a value and as such is always dependent on a resource whose value represents. As has been discussed in the post Problems of the RDF model: Literals, there is a need to clearly separate the concept of a literal from this resource that acts sort of like a primitive variable. The rdf:value property has been used for the implementation of this idea, as shown in the example where the blank node takes the role of an instance of the class “Nick”, while the literal represents the value of this instance:

<http://carlosraynorris.com/data_/carlos> foaf:nick [ rdf:value “Chuck” ]

The rdf:value is an interesting property that needs to be further analyzed. In the RDF Primer, this property is described in the context of modeling n-ary relationships. N-ary relationships are those that exist between more than two resources (a triple represents a binary relationship between the subject and the object). A general way to represent any n-ary relation in RDF, as described in the RDF primer, is to…

[...] select one of the participants to serve as the subject of the original relation, then specify an intermediate resource to represent the rest of the relation, then give that new resource properties representing the remaining components of the relation.

This new resource, which is tipicaly represented as a blank node, takes the role of the “glue” – it becomes the subject in the new triples that describe the other resources of the n-ary relation. As an example of an n-ary relation, person’s address information is used:

address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730")

It is then “broken” in the described way into the following triples:

exstaff:85740   exterms:address        _:johnaddress .
_:johnaddress   exterms:street         "1501 Grant Avenue" .
_:johnaddress   exterms:city           "Bedford" .
_:johnaddress   exterms:state          "Massachusetts" .
_:johnaddress   exterms:postalCode     "01730" .

In the first triple, the exstaff:85740 (the URI reference identifying one of the employees) takes the role of the subject, while a blank node identifier _:johnaddress" (identifying John’s address) becomes the object. This blank node then becomes the subject in the rest of the triples describing the elements of the address – the street, city, state and zip code.

In this example, none of the individual parts of the structured value (the address) could be considered the “main” value (of the exterms:address property), all of the parts contribute equally to the value. However, in some cases one of the parts of the structured value is often thought of as the “main” value, with the other parts of the relation providing additional contextual or other information that qualifies the main value. Such a case is described in the following example of the same document:

exproduct:item10245   exterms:weight   _:weight10245 .
_:weight10245         rdf:value        "2.4"^^xsd:decimal .
_:weight10245         exterms:units    exunits:kilograms .

These three triples describe the product exproduct:item10245 weighted 2.4 kg. The rdf:value is used as a convinient property to represent the main value ​​of the weight  which equals 2.4. In the RDF Primer, this decision is explained as follows:

There is no need to use rdf:value for these purposes (e.g., a user-defined property name, such as exterms:amount, could have been used instead of rdf:value), and RDF does not associate any special meaning with rdf:value. rdf:value is simply provided as a convenience for use in these commonly-occurring situations.

Therefore, the rdf:value property has no precisely defined meaning. The rdf:value “is typically used to identify the ‘primary’ or ‘major’ value of a property which has several values, or has as its value a complex entity with several facets or properties of its own.” However, the standard use cases where this property imposes itself as an intuitive choice suggests that the meaning of the rdf:value property perhaps might be defined more precisely.

Let’s look at the general case of a literal RDF triple in the (classical) RDF model:

resource    property    literal .

A literal, therefore, represents the value of the property of a resource. However, this is conceptually wrong because the “value” of the property of a resource in general is a new resource (identified by a URI reference). In the example at the beginning of this post, the literal “Chuck” is not the property’s value, but the value of a new concept that could be called “Carlos’ nickname”. This new concept, which can be loosely referred to as a primitive variable, is missing in a literal triple.

In other words, the object of a literal triple is a “complex entity”, which has two aspects – a “variable” and a value. In a similar way a new node was introduced during the realization of an n-ary relationship, we can create two triples in which the “primitive variable” serves as the “glue” connecting them. Thus, the general case of using literals with the rdf:value property should look like this:

resource               property      primitive variable .
primitive variable     rdf:value     literal .

Data a literal represents on its own has no meaning – its meaning is dependent on the resource “primitive variable” whose value is the literal. The “primitive variable” is a node identified by URI reference that acts as a primitive variable because it can be represented by a single value. The rdf:value thus explicitly describes the relationship between a URI reference and a literal and must be a single-value property. This means that the rdf:value property is the only instance of the class “owl:DatatypeProperty”, while all the other properties are the instances of the class “owl:ObjectProperty”. In other words, each literal triple must have the rdf:value property as a predicate.

Thus there are three constraints that define a literal:

  • A literal must be the object of an RDF triple in which the rdf:value is the predicate
  • A URI reference may have only one rdf:value property
  • A literal can not be described by the new properties

A node “primitive variable” can be described by other properties that more closely describe its value – for example, the language used, the unit of measurement, the currency and so on. It’s worth noting that these properties refer to the “primitive variable” rather than the literal. For example, a specific nickname can be in English language, not the “Chuck”, a specific weight can be expressed in kilograms, not the value “2.4″, the specific product’s price can be in EUR, rather than its value “99.99″. Also, the literal datatype is defined when describing the class to which the “primitive variable” belongs, as will be discussed in the next post.

A plain literal is not a string – it is a node identified by URI reference representing a value, which can be of a string datatype. The URI of a literal is obtained in the same way as with blank nodes – by adding the property CURIE on the URI reference whose value is the literal. Since this property is always rdf:value, a literal has a standard URI “primitiveVariableURI/rdf_value”.

In an RDF notation, a literal is always represented by its value, while its URI can be concluded easily if needed. The URI is important when a literal is used in the Web context. There are two ways to implement a literal on the Web – as the web resource sharing the literal’s URI (primitiveVariableURI/rdf_value) and returning the literal value, or as a shortcut – the content of a web resource “primitiveVariableURI”. The realization of these two methods will be discussed in more detail in future posts.


  • http://milicicvuk.com/blog/2011/09/30/getting-rid-of-typed-literals/ Getting rid of typed literals

    [...] I start discussing potential solutions for the above problems, let’s recall how literals are different in the new RDF model I’ve been proposing in this blog, compared to the classical RDF [...]

  • http://milicicvuk.com/blog/2011/10/20/the-challenge-of-building-the-semantic-web/ The Challenge of Building the Semantic Web

    [...] but there is simply no additional information to differentiate the two. This can be solved with an additional node that takes place between the URI reference and the [...]