Updating Linked Data with SPARQL 1.1

We now turn to queries that modify datasets by adding or removing data; these were not available in the original 2008 standard, but are provided for in the SPARQL 1.1 recommendation. To understand how they work, it is useful first to review how datasets are organised.

Every SPARQL query engine has an associated RDF dataset on which queries are normally run. The dataset is sometimes called a graph store, because it is organised as a collection of RDF graphs rather than a single graph. One of these graphs is called the default graph of the dataset, and has no name. The other graphs, if present, are called named graphs, each of which is identified by an IRI. Thus a dataset must have a default graph, and in addition may have any number of named graphs – including none.

The main update operations provided are as follows:

  • Deleting data from one of the graphs in the graph store.
  • Inserting data into one of the graphs in the store.
  • Loading the content of another graph into a graph in the store.
  • Clearing all triples from a graph in the store.

Unfortunately, to protect the datasets, query update is not supported by public endpoint. LinkedData.Center provides you with a private, password protected endpoint .

Adding data to a graph[edit | edit source]

Suppose you have a graph containing data about the Beatles, in which Peter Best is included as a member of the band. If we assume that the graph is meant to describe the band as it was in the mid 1960s, when the Beatles were at their most active and famous, then this information would be out-of-date; we might want to describe Peter Best as a former band member, but not a current one. Here is a query that will achieve the first part of this objective, by describing Peter Best as a former band member:

PREFIX dbpedia: <http://dbpedia.org/resource/>
PREFIX db-ont: <http://dbpedia.org/ontology/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

INSERT { dbpedia:The_Beatles db-ont:formerMember ?x }
WHERE  { dbpedia:The_Beatles db-ont:currentMember ?x .
        ?x foaf:name "Peter Best"

This query is very similar in syntax to the queries we examined in section 2.4, especially CONSTRUCT and DESCRIBE queries. The query form in this case is INSERT, and like CONSTRUCT it is followed by a graph pattern that specifies a set of RDF triples, given bindings for any variables that are included in the pattern. These bindings, as before, are obtained through a WHERE clause. In this simple example, we assume that the person formulating the query does not know the IRI naming the resource Peter Best, and accordingly retrieves it from the dataset using the foaf:name relation to the literal "Peter Best". Once the relevant IRI is plugged into the single triple following INSERT, we obtain an exact specification of an RDF triple (with no variables). The query engine then checks whether this triple is present in the default graph, and if not, adds it. If the triple was already present in the graph, there would be no change.

If you knew the URI for Peter Best, you could use an alternative form of the insert query with the keywords INSERT DATA. This is followed not by a graph pattern (including variables) but a set of fully specified triples; accordingly, a WHERE clause is not needed.

If you wish the triples to be added to a named graph rather than the default graph, you can name the relevant graph at the beginning of the pattern after INSERT, as in the following slightly modified example:

PREFIX dbpedia: <http://dbpedia.org/resource/>
PREFIX db-ont: <http://dbpedia.org/ontology/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

INSERT { GRAPH <http://myFavGroups/The_Beatles> 
         { dbpedia:The_Beatles db-ont:formerMember ?x }
WHERE  { dbpedia:The_Beatles db-ont:currentMember ?x .
        ?x foaf:name "Peter Best"

Deleting data from a graph[edit | edit source]

As in the case of inserting, you have two options: either use DELETE DATA followed by a set of RDF triples (without variables), or use DELETE followed by a graph pattern and a WHERE clause. In either case, you again have the option of indicating, within the DELETE clause, the graph from which the specified triples will be removed. If no graph is named, the triples will be removed from the default graph.

In the following example, which would be a natural sequel to the query in 2.6.1, Peter Best is removed as a current band member from the default graph.

PREFIX dbpedia: <http://dbpedia.org/resource/>
PREFIX db-ont: <http://dbpedia.org/ontology/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

DELETE { dbpedia:The_Beatles db-ont:currentMember ?x }
WHERE  { dbpedia:The_Beatles db-ont:currentMember ?x .
        ?x foaf:name "Peter Best"

Combining insertion and deletion[edit | edit source]

In the examples for INSERT and DELETE the aim was to replace an outdated statement (Peter Best as current member) by an up-to-date one (Peter Best as former member). When the INSERT and DELETE operations use the same variable bindings, they can be combined in a single query, sharing the same WHERE clause, as follows:

PREFIX dbpedia: <http://dbpedia.org/resource/>
PREFIX db-ont: <http://dbpedia.org/ontology/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>

DELETE { dbpedia:The_Beatles db-ont:currentMember ?x }
INSERT { dbpedia:The_Beatles db-ont:formerMember ?x }
WHERE  { dbpedia:The_Beatles db-ont:currentMember ?x .
        ?x foaf:name "Peter Best"

Loading an RDF graph[edit | edit source]

You might wish to extend your dataset by loading triples from an external dataset for which you have the URL. This can be done using the LOAD query, which has the following simple basic syntax:

LOAD <http://xmlns.com/foaf/spec/20100809.rdf>

This will retrieve all triples from the specified external web source – if it exists – and copy them into the default graph of your query engine. If you want instead to copy them into a named graph you can use the keyword INTO to specify the graph name:

LOAD <http://xmlns.com/foaf/spec/20100809.rdf>
INTO <http://myFavGroups/The_Beatles>

Clearing an RDF graph[edit | edit source]

If you want to retain a graph in the store as a location into which you can load and insert data, but to repopulate it from scratch by clearing out its current triples, you can use a CLEAR query with the following simple syntax:

CLEAR GRAPH <http://myFavGroups/The_Beatles>

The keyword GRAPH is employed when you identify the graph to be cleared using its IRI. Alternatives are CLEAR DEFAULT, which clears the default graph, CLEAR NAMED, which clears the graph with the specified name, and CLEAR ALL, which clears all graphs in the store. Thus the following would be a complete query removing all triples from the query engine's default graph:


Adding and removing graphs[edit | edit source]

SPARQL 1.1 allows you to manage the graphs in the query engine's store by the query forms CREATE and DROP. It is important to understand that these operate on graphs, not on triples. CLEAR removes all triples from a graph, but does not remove the graph itself; it remains in place as a location into which triples may be inserted or loaded. DROP, by contrast, removes the graph altogether from the store, so that any attempt to load or insert into it will yield an error – unless you first reinstate it using CREATE. Thus CLEAR is like removing all text from a Word document while leaving the document in place, whereas DROP is like trashing the document altogether.

To create a new graph, just specify its IRI as follows:

CREATE GRAPH <http://myFavGroups/The_Beatles>

To drop an existing graph, use the same syntax with DROP instead of CREATE:

DROP GRAPH <http://myFavGroups/The_Beatles>

Other graph management operations[edit | edit source]

If you are working with several graphs in a store, you might wish to copy or move information from one to another. For instance, when starting a new version of a named graph, you might first create a new (empty) graph for version 2, and then wish to copy across the entire contents of version 1. This is done as follows:

COPY GRAPH <http://myFavGroups/The_Beatles/v1>
TO GRAPH <http://myFavGroups/The_Beatles/v2>

Note that version 1 remains unchanged by this operation, which is like copying text from one document and pasting it into another document, overwriting any text already in the second document. This means that after the COPY operation is performed, the two graphs will have exactly the same triples.

If the source graph is a draft that you have no more use for, you can use the MOVE command, which first copies all triples from the first graph to the second, and then removes the first graph altogether – equivalent to performing COPY followed by DROP:

MOVE GRAPH <http://myFavGroups/The_Beatles/draft>
TO GRAPH <http://myFavGroups/The_Beatles/v1>

This is like copying text from one document to another, overwriting any text in the second document, and then trashing the first document.

If you want to retain triples already present in the destination graph, you can use the ADD command, which is the same as COPY except that triples from the source graph are added to the destination graph without overwriting. You might do this, for example, if you have been constructing separate graphs for different rock groups (The Beatles, The Rolling Stones, etc.), and now wish to add your Beatles data to a larger graph covering all your favourite rock groups:

ADD GRAPH <http://myFavGroups/The_Beatles>
TO GRAPH <http://myRockGroups>

Like COPY, this operation leaves the source graph unchanged. It is like copying text from a document and pasting it into another document without overwriting the text already present there.

For all these operations, a destination graph will be created automatically if it does not exist already.

SPARQL protocol[edit | edit source]

The SPARQL 1.1 Protocol comprises two operations, one for querying, one for updating. An operation specifies the following:

  • An HTTP method (either GET or POST)
  • HTTP query parameters
  • Message content in the HTTP request body
  • Message content in the HTTP response body

A request is sent from the SPARQL client to the SPARQL server (or endpoint), which sends back a status code, possibly accompanied by other data (e.g., tables with the results of the query). For a query operation, the response is a table of data in one of various formats (XML, CSV, etc.) for a SELECT query, and triples formatted in RDF/XML or Turtle for a CONSTRUCT query.

Status codes are three-digit integers whose meanings are defined by the HTTP specification; for instance, the standard response to a successful request has the code "200".

Figure 9 shows a possible encoding of the HTTP GET request for a simple query. The details are not important for this chapter, but it is worth noting the final line (starting with "Accept"), which lists the media types that the sender can understand, with preference ratings expressed as numbers between 0.0 and 1.0. This is called content negotiation, and is also part of the HTTP specification.

Web Generations

Figure 9: Encoding of a GET request

Reasoning over linked data[edit | edit source]

Reasoning enhances the information contained in a dataset by including results obtained by inference from the triples already present. As a simple example, suppose that the dataset includes the following triples, shown here in Turtle (assume the usual prefixes):

dbpedia:The_Beatles a mo:MusicGroup .
mo:MusicGroup rdfs:subClassOf mo:MusicArtist .

Recall that the predicate a in the first triple is Turtle shorthand for rdf:type, denoting class membership. Now, suppose that we submit the following SELECT query designed to retrieve all triples in which the Beatles occur as subject:

PREFIX dbpedia: <http://dbpedia.org/resource/>

WHERE { dbpedia:The_Beatles ?predicate ?object }

Assuming there are no other relevant triples, the response to this query under a regime with no entailment will be the following single-row table:

?predicate ?object
a mo:MusicGroup

An obvious inference has been missed here, since if every music group is a music artist (as asserted by the second triple), the Beatles will also be a music artist. (It might sound odd to call a group an artist, but this is how the information is encoded in the Music Ontology.) If we execute the query on an engine that implements the RDFS entailment regime (a set of rules governing inference based on RDFS resources like rdfs:subClassOf), the output table will be enriched by a second variable binding inferred with the aid of the second triple.

?predicate ?object
a mo:MusicGroup
a mo:MusicArtist

This is a very simple case, but in general the formulation of workable entailment regimes is a complex task, still under investigation and discussion. One hard problem is what to do if the dataset is inconsistent, since a well-known result of logic states that from a contradiction, anything can be inferred. (This follows from the definition of material implication, for which the truth-conditions state that if the antecedent is false, the implication holds whatever the consequent. Hence a contradiction, being false by definition, implies any statement whatever.)

Another problem is that some queries might return an infinite set of solutions. For instance, there is a convention in RDF that allows for a family of predicates rdf:_1, rdf:_2, etc. ending in any positive integer; such predicates are used when constructing lists. This means that if all possible inferences are performed, a query of the form ?x rdf:type rdf:Property (intuitively, return all properties) would yield an infinite set.

For practical purposes we can ignore such cases, but they illustrate that that query engines may not always return all the entailments that one might expect.

In the rest of this section we look first at typical entailments that arise from RDFS, and then at the much richer entailments that can result from an ontology in OWL.

Reasoning using RDFS[edit | edit source]

RDF Schema introduces a very limited range of logical terms based mostly on the concept of class, or rdfs:Class, a concept absent from RDF. It is possible to state directly that a resource denotes a class, using a triple such as the following (to save space we omit prefixes):

mo:MusicGroup rdf:type rdfs:Class .

We have already seen an example of the predicate rdfs:subClassOf, through which we can assert that the resource in subject position is a subclass of the resource in object position – a relationship often expressed in English by sentences of the form All X are Y (e.g., "All pianists are musicians"). A similar predicate is provided for properties rather than classes, illustrated by the following triple in which subject, predicate and object are all property resources:

ex:hasSinger rdfs:subPropertyOf ex:hasPerformer .

This means that if a subject and object are related by the ex:hasSinger predicate, they must also be related by the ex:hasPerformer predicate. Note that even though these are properties, they may occur in subject and object position – in other words, we can make statements about properties, as well as using them to express relationships among other resources. Two important facts about any property are its domain and range, which constrain the resources that can be employed in subject and object position when the property is used as a predicate; these can also be defined using RDFS resources, as follows:

ex:hasSinger rdfs:domain mo:Performance .
ex:hasSinger rdfs:range foaf:Agent .

This means that any resource occurring as subject of ex:hasSinger must belong to the class mo:Performance (only performances have singers), while any resource occurring as object of ex:hasSinger must belong to the class foaf:Agent (only agents are singers).

RDFS entailment rules[edit | edit source]

The RDFS entailment regime is defined by thirteen rules, which are listed here. In brief, their import is as follows:

Allocates a blank node to a literal, and classifies this node as a member of the class rdfs:Literal.
Uses a rdfs:domain statement to classify a resource found in subject position (in a triple containing the relevant property as predicate).
Uses a rdfs:range statement to classify a resource found in object position (in a triple containing the relevant property as predicate).
Classifies a resource found in subject or object position in a triple as belonging to the class rdfs:Resource.
Inference based on the transitivity of rdfs:subPropertyOf.
Infers that any resource classified as a property is a sub-property of itself.
Uses a rdfs:subPropertyOf statement to infer that two resources are related by a property P if they are related by a subproperty of P.
Infers that any resource classified as a class is a subclass of rdfs:Resource.
Infers that a resource belongs to a class if it belongs to its subclass.
Infers that any class is a subclass of itself.
Uses the transitivity of rdfs:subClassOf to infer that the subclass of a class C is a subclass of the superclass of C.
Infers that any resource belonging to rdfs:ContainerMembershipProperty is a subproperty of rdfs:member.
Infers that any resource belonging to rdfs:Datatype is a subclass of rdfs:Literal.

In what follows, we look more closely at how these RDFS resources and their associated rules can support inferences when information is retrieved from a dataset.

Inferring subclass and class membership relationships[edit | edit source]

We have already seen an example of an inference based on rdfs:subClassOf, which we repeat below omitting Prefix statements:

dbpedia:The_Beatles a mo:MusicGroup .
mo:MusicGroup rdfs:subClassOf mo:MusicArtist .

The general form of this inference is that if a resource belongs to a class, which in turn belongs to a broader class, then the resource must also belong to this broader class (see rdfs9). This pattern will be familiar as a variant of the Aristotelian syllogism:

Socrates is a man.

All men are mortal.

Therefore, Socrates is mortal.

A similar inference can be drawn from two subclass statements in which the object of one statement is the subject of the other (see rdfs11):

mo:MusicGroup rdfs:subClassOf mo:MusicArtist .
mo:MusicArtist rdfs:subClassOf foaf:Agent .

If music groups are a subclass of music artists, who are in turn a subclass of agents, then music groups must be a subclass of agents. This corresponds to the so-called Barbara pattern of the syllogism:

All Greeks are men.

All men are mortal.

Therefore, all Greeks are mortal.

Classifying a resource from its relationships to other resources[edit | edit source]

Suppose a dataset contains the following triple asserting that Paul McCartney belongs to the Beatles:

dbpedia:The_Beatles mo:bandMember dbpedia:Paul_McCartney .

Can we infer anything further about the resources in subject and object position? To a human, of course, it will be obvious from the resource names that the Beatles is a group, and that Paul McCartney is an agent, or more specifically a person. However, these names are meaningless to the query engine, which can only utilise information encoded in RDF triples. To put ourselves in this position, we could try using arbitrary IRIs, as in this version of the triple:

ex:X mo:bandMember ex:Y .

Even with subject and object anonymised in this way, a person could infer from the predicate that X will be a band, and Y a person. The query engine can perform this inference too if the dataset includes triples defining the domain and range of the property (see rdfs2 and rdfs3):

mo:bandMember rdfs:domain mo:MusicGroup ;
              rdfs:range foaf:Agent .

(Remember the use of the semi-colon here to abbreviate two statements with the same subject.) If these triples are present in the dataset, and the query engine is deploying the RDFS entailment regime, then two further triples can be directly inferred:

ex:X a mo:MusicGroup .
ex:Y a foaf:Agent .

A special case of this inference arises when a triple uses an RDFS predicate for which domain and range statements are axiomatic, meaning that they are defined in RDFS itself and need not be included in the dataset over which the query is run. Thus for rdfs:subClassOf, the following triples are axiomatic and need not be defined by developers:

rdfs:subClassOf rdfs:domain rdfs:Class .
rdfs:subClassOf rdfs:range  rdfs:Class .

It follows that on encountering any subclass statement, the query engine can infer that its subject and object must be classes. Thus from –

mo:MusicGroup rdfs:subClassOf mo:MusicArtist .

– it can infer:

mo:MusicGroup a rdfs:Class .
mo:MusicArtist a rdfs:Class .

Inferences based on sub-property relationships[edit | edit source]

Finally, whenever SP has been defined as a sub-property of P, it can be inferred that any subject and object having an SP relationship must also have the (broader) P relationship (see rdfs5):

ex:hasSinger rdfs:subPropertyOf ex:hasPerformer .
ex:Yesterday ex:hasSinger dbpedia:PaulMcCartney .

From these two statements, the query engine may infer:

ex:Yesterday ex:hasPerformer dbpedia:PaulMcCartney .

Such inferences are common when a dataset uses RDFS to organise classes and properties into hierarchies. Thus classes like Corgi, Dog, Canine, Mammal, Animal, Living thing, comprise an obvious hierarchy in which membership of any class implies membership of all its superclasses; as we have just shown, a similar hierarchical organisation can be defined for properties.

More advanced inferences[edit | edit source]

Compared with OWL, RDFS has two main limitations: (a) it provides no operators for constructing complex classes or properties out of simpler ones (e.g., "artist that belongs to at least two bands" from artist, band, and member-of); (b) it lacks some important resources for describing the logical properties of classes and properties, such as disjointness (for classes) and inverse (for properties). Limitations of the second kind are particularly common when working with linked data, and it is worth illustrating some of them now, before we look in detail at OWL.

Suppose that a dataset contains resources named ex:Man and Woman, both classes, which can be used for classifying resources that represent individual people:

dbpedia:Paul_McCartney a ex:Man .
dbpedia:Cilla_Black a ex:Woman .

Now, suppose that in addition to these two triples, a third triple is either present in the dataset, or can be inferred:

dbpedia:Paul_McCartney a ex:Woman .

Plainly something has gone wrong here, and we would like a query engine capable of even elementary reasoning to signal an inconsistency. It might surprise you the learn that there is no way of doing this, because RDFS provides no predicate allowing you to state that men and women are disjoint (i.e., that no man is a woman, or nothing is both a man and a woman). The necessary predicate, owl:disjointWith, is found in OWL only, and allows statements such as the following:

ex:Man owl:disjointWith ex:Woman .

To give one more example, suppose that we introduce a property resource allowing us to state that one person is married to another. We might for instance apply it to the McCartneys:

dbpedia:Paul_McCartney ex:marriedTo dbpedia:Linda_McCartney .

Now, suppose that someone formulates the following query, corresponding to the question "Who is married to Paul McCartney?" (we omit PREFIX clauses as before):

SELECT ?person
WHERE { ?person ex:marriedTo dbpedia:Paul_McCartney }

Obviously the answer should be "Linda McCartney", but this binding will not be found because the following triple is missing from the dataset:

dbpedia:Linda_McCartney ex:marriedTo dbpedia:Paul_McCartney .

To infer this we need a statement to the effect that if X is married to Y, Y must be married to X. In mathematics, this fact is expressed by saying that the property ex:marriedTo is symmetric. This can be stated directly using OWL, as follows:

ex:marriedTo a owl:SymmetricProperty .

No such resource exists in RDFS, so this kind of inference cannot be performed under an RDFS entailment regime.

Reasoning using OWL[edit | edit source]

As a reminder, Figure 10 shows the location of the Web Ontology Language (OWL) in the Semantic Web stack. As can be seen, OWL depends on RDF and RDFS, from which it draws crucial resources such as rdf:type and rdfs:Class. Like RDFS, it can enhance the information in RDF datasets, accessible to SPARQL queries.

Web Generations

Figure 10: OWL in Semantic Web stack

The current OWL standard OWL-2 is complex, providing for a number of fragments with different computational properties (see chapter 1). Most of these are subsets of OWL2-DL, the OWL description logic, but there is also a more expressive variant called OWL2-Full which ventures outside description logic. We will not try to cover all this material in this section. Instead, we look at some of the main logical resources in OWL2-DL from the viewpoint of their role in inference.

Inferences based on characteristics of properties[edit | edit source]

We have illustrated in the last section an inference based on one of the property characteristics that can be represented in OWL, namely symmetry (if X p Y, then Y p X). A number of others are provided, of which the following are used most often:

  • Transitive properties support the inference: if X p Y, and Y p Z, then X p Z. An example is the property "longer than" applied to track durations: if "Hey Jude" is longer than "Help", and "Help" is longer than "Yesterday", then we can infer that "Hey Jude" is longer than "Yesterday".
  • Functional properties support the inference that if X p Y and X p Z, Y and Z must be identical: in other words, X can bear the relation p to only one thing. An example is the property "has mother", assuming that this means biological mother. To say that this property is functional means that a person can have at most one mother. Thus if Charles has Elizabeth as mother, and Charles also has Mrs Windsor as mother, then Elizabeth and Mrs Windsor are two names of the same person.
  • Inverse-functional properties support the inference that if Y p X and Z p X, then Y and Z must be identical. An example would be the property "is mother of". Thus if Elizabeth is mother of Charles, and so is Mrs Windsor, then Elizabeth and Mrs Windsor are the same person.
  • Two properties p1 and p2 are inverse if X p1 Y means exactly the same as Y p2 X (i.e., they are equivalent, and each can be inferred from the other). Thus in our last two examples, "has mother" and "is mother of" are inverse properties, since if Charles has mother Elizabeth, then Elizabeth is mother of Charles, and vice-versa.

Let us see how these characteristics are used in practice, starting with a transtive property.

ex:locatedIn a owl:TransitiveProperty .
ex:AbbeyRoadStudios ex:locatedIn ex:London .
ex:London ex:locatedIn ex:UnitedKingdom .

Here the classification of ex:locatedIn as a transitive property allows a query engine with an OWL2-DL regime to draw the following inference in response to a query concerning the location of the Abbey Road Studio (or concerning what is located in the United Kingdom):

ex:AbbeyRoadStudios ex:locatedIn ex:UnitedKingdom .

Moving on to functional properties, consider this set of triples:

ex:hasFather a owl:FunctionalProperty .
dbpedia:Julian_Lennon ex:hasFather dbpedia:John_Lennon .
dbpedia:Julian_Lennon ex:hasFather ex:J_Lennon .

The classification of ex:hasFather as functional permits the inference that Julian Lennon can have only one father, and hence that the objects of the second and third triples must be co-referential. In OWL this is expressed using owl:sameAs:

dbpedia:John_Lennon owl:sameAs ex:J_Lennon .

Exactly the same inference can be drawn if the same information is presented using the inverse-functional property ex:isFatherOf:

ex:isFatherOf a owl:InverseFunctionalProperty .
dbpedia:John_Lennon ex:isFatherOf dbpedia:Julian_Lennon .
ex:J_Lennon ex:isFatherOf dbpedia:Julian_Lennon .

Note that owl:sameAs is symmetric, and also transitive; these characteristics are axiomatic in OWL, so they need not be specified by the ontology developer.

Finally, if we include a triple stating that ex:hasFather and ex:isFatherOf are inverse, we obtain two ways of expressing fatherhood, with subject and object switched. Imagine for instance a dataset with just two triples –

ex:hasFather owl:inverseOf ex:isFatherOf .
dbpedia:Julian_Lennon ex:hasFather dbpedia:John_Lennon .

– and suppose we run the following query (prefixes omitted) on who is the father of Julian Lennon:

SELECT ?person
WHERE { ?person ex:isFatherOf dbpedia:Julian_Lennon }

Without OWL-based reasoning the query engine has no way of returning John Lennon as an answer to this query, but using the inverse property statement it can derive the following entailment:

dbpedia:John_Lennon ex:isFatherOf dbpedia:Julian_Lennon .

Inferences based on equivalence among terms[edit | edit source]

We have already seen an OWL property owl:sameAs which allows us to state that two IRIs name the same individual:

dbpedia:John_Lennon owl:sameAs ex:J_Lennon .

This property is very important in linked data, since it provides a means by which datasets with different naming conventions can be connected. OWL also provides predicates for stating that two classes, or two properties, have the same meaning, as follows:

mo:MusicArtist owl:equivalentClass ex:musician .
foaf:made owl:equivalentProperty ex:creatorOf .

In essence we have three ways here of stating that two terms mean the same thing, and in each case inferences can be drawn from the fact that equivalence of meaning is symmetric and transitive. The practical consequence is that if a dataset already contains two names for John Lennon (say), owing to the owl:sameAs statement above, we can add a third name by relating it to only one of these names –

dbpedia:John_Lennon owl:sameAs new:JL666 .

– whereupon by symmetry and transitivity, a similar statement can be inferred for any subect-object pair drawn from these three names:

ex:J_Lennon owl:sameAs new:JL666 .
new:JL666 owl:sameAs ex:J_Lennon .
new:JL666 owl:sameAs dbpedia:John_Lennon .

Similarly, a single owl:sameAs statement introducing a fourth name will suffice to make it equivalent in meaning to any of the other three – and so on.