18CSE457T - SEMANTIC

WEB
UNIT - I
The Semantic Web Vision
1. Introduction
1. Motivation for the Semantic Web
2. Design Decisions for the Semantic Web
3. Basic Technology for the Semantic Web
4. From Data to Knowledge
5. The Web Architecture of the Semantic Web
6. How to Get There from Here
2. Semantic Web Technologies
1. Explicit Metadata
2. Ontologies
3. Logic
4. The Semantic Web versus Artificial Intelligence
3. A Layered Approach
1. Introduction
1. Motivation for the Semantic Web
2. Design Decisions for the Semantic Web
3. Basic Technology for the Semantic Web
4. From Data to Knowledge
5. The Web Architecture of the Semantic Web
6. How to Get There from Here
Motivation for the Semantic Web
• “semantic web” can be summarized in a single phrase:
• to make the web more accessible to computers
• current web is a web of text and pictures
• Such media are very useful for people, but computers play a very
limited role on the current web:
• they index keywords, and they ship information from servers to clients, but
that is all.
• All the intelligent work (selecting, combining, aggregating, etc.) has to
be done by the human reader.
• What if we could make the web richer for machines, so that it would
be full of machine readable, machine “understandable” data?
•Such a web would facilitate many things that are
impossible on the current web:
•Search would be no longer limited to simply looking for
keywords, but could become more semantic, which would
include looking for
• synonyms
• being aware of homonyms
• taking into account context
• purpose of the search query
•Websites could become more personalized if personal
browsing agents were able to understand the contents of a
web page and tailor it to personal interest profiles.
•Linking could become more semantic by deciding
dynamically
• which pages would be useful destinations
• based on the current user’s activities
• instead of having to hardwire the same links for all users
ahead of time.
•It would be possible to integrate information across
websites, instead of users currently having to do a
“mental copy-paste” whenever they find some
information on one site that they want to combine with
information from another.
 Design Decisions for the Semantic Web
• There are many ways of going about building a more “semantic” web.
• One way would be to build a “Giga Google,” relying on “the unreasonable
effectiveness of data” to find the right correlations among words, between
terms and context, etc.
• The plateau in search engine performance that we have been witnessing
over the past few years seems to suggest that there are limitations to this
approach:
• none of the search giants have been able to go beyond returning simply flat lists of
disconnected pages
 •The Semantic Web follows different design principles,
which can be summarized as follows:
1. make structured and semi-structured data available in
standardized formats on the web;
2. make not just the datasets, but also the individual
data-elements and their relations accessible on the web;
3. describe the intended semantics of such data in a
formalism, so that this intended semantics can be
processed by machines.
• The decision to exploit structured and semi-structured data is based on a
key observation, namely that underlying the current unstructured “web
of text and pictures is” actually a very large amount of structured and
semi-structured data.
• The vast majority of web content is being generated from databases and
content management systems containing carefully structured datasets.
• However, the often rich structure that is available in such datasets is
almost completely lost in the process of publishing such structured data
as human-readable Hypertext Markup Language (HTML) pages.
Structured and unstructured data on the web:
 Basic Technology for the Semantic Web
• The aforementioned three design principles have been translated into actual
technology
1. use labeled graphs as the data model for objects and their relations, with objects
as nodes in the graph, and the edges in the graph depicting the relations
between these objects.
• The unfortunately named “Resource Descripion Framework” RDF3 is used as the
formalism to represent such graphs.
2. use web identifiers (Uniform Resource Identifiers - URI) to identify the
individual data-items and their relations that appear in the datasets.
• Again, this is reflected in the design of RDF.
3. use ontologies (briefly: hierarchical vocabularies of types and relations) as the
data model to formally represent the intended semantics of the data.
• Formalisms such as RDF Schema and The Web Ontology Language (OWL) are used for
this purpose, again using URIs to represent the types and their properties
 From Data to Knowledge
• It is important to realize that in order to really capture the intended
semantics of the data, a formalism such as RDF Schema and OWL are not
just data-description languages, but are actually lightweight knowledge
representation languages.
• They are “logics” that allow the inference of additional information from
the explicitly stated information.
• RDF Schema is a very low expressivity logic that allows some very simple
inferences, such as property inheritance over a hierarchy of types and
type-inference of domain and range restrictions.
• Similarly, OWL is somewhat richer (but still relatively lightweight) logic
that allows additional inferences such as
• equality and
• inequality,
• number restrictions,
• existence of objects and others.
• Such inferences in RDF Schema and OWL give publishers of information
the possibility to create a minimal lower bound of facts that readers must
believe about published data.
• Additionally, OWL gives information publishers the possibility to forbid
readers of information to believe certain things about the published data
(at least as long as everybody intends to stay consistent with the published
ontology).
•Together, performing such inferences over these
logics amounts to imposing both a lower bound and
an upper bound on the intended semantics of the
published data.
•By increasingly refining the ontologies,
•these lower and upper bounds can be moved arbitrarily
close together
•thereby pinning down ever more precisely the
intended semantics of the data
•to the extent required by the use cases at hand
 The Web Architecture of the Semantic Web
•A key aspect of the traditional web is the fact that its content is
distributed, both in location and in ownership:
• web pages that link to each other often live on different web servers,
and these servers are in different physical locations and owned by
different parties.
•A crucial contributor to the growth of the web is the fact that
“anybody can say anything about anything,” or more precisely:
• anybody can refer to anybody’s web page without having to negotiate
first about permissions or inquire about the right address or identifier
to use.
• A similar mechanism is at work in the Semantic Web:

• a first party can publish a dataset on the web (left side of the diagram),
• a second party can independently publish a vocabulary of terms (right side
of the diagram),
• a third party may decide to annotate the object of the first party with a term
published by the second party, without asking for permission from either of
them, and in fact without either of these two having to even know about it.
• It is this decoupling that is the essence of the weblike nature of the Semantic
Web.
How to Get There from Here
• Architectural principles an implemented reality:
1. We must agree on standard syntax to represent data and metadata.
2. We must have sufficient agreement on the metadata vocabularies in
order to share intended semantics of the data.
3. We must publish large volumes of data in the formats of step 1,
using the vocabularies of step 2.
Semantic Web Technologies
1. Explicit Metadata
2. Ontologies
3. Logic
4. The Semantic Web versus Artificial
Intelligence
Explicit Metadata
• Currently, web content is formatted for human readers rather than
programs.
• HTML is the predominant language in which web pages are written
directly or using tools.
• A portion of a typical web page of a physical therapist might look
like this
•This representation is far more easily processable by machines.
•In particular, it is useful for exchanging information on the web,
which is one of the most prominent application areas of XML
technology.
•However, XML still remains at the syntactic level, as it describes
the structure of information, but not its meaning.
•The basic language of the Semantic Web is RDF, which is a
language for making statements about pieces of information.
• In our example, such statements include:

• To a human reader, the difference between the XML representation and a

list of RDF statements may appear minimal, but they are quite different in
nature:
• XML describes structure while RDF makes statements about pieces of
information.
• The term metadata refers to such information: data about data.
• Metadata captures part of the meaning of data, thus the term semantic in
Semantic Web.
Ontologies
• The term ontology originates from philosophy.
• In that context, it is used in the branch of metaphysics concerned with
identifying, in the most general terms, the kinds of things that actually
exist, and how to describe them.
• For example, the observation that the world is made up of specific
objects that can be grouped into abstract classes based on shared
properties is a typical ontological commitment.
• However, in more recent years, ontology has become one of the many
words hijacked by computer science and given a specific technical
meaning that is rather different from the original one.
• In general, an ontology describes formally a domain of discourse.
• Typically, an ontology consists of a finite list of terms and the relationships
between these terms.
• The terms denote important concepts (classes of objects) of the domain.
• For example, in a university setting, staff members, students, courses,
lecture theaters, and disciplines are some important concepts
• The relationships typically include hierarchies of classes.
• A hierarchy specifies a class C to be a subclass of another class C if every
object in C is also included in C .
• For example, all faculty are staff members.
• Apart from subclass relationships, ontologies may include information
such as
• properties (X teaches Y),
• value restrictions (only faculty members may teach courses),
• disjointness statements (faculty and general staff are disjoint )
• specifications of logical relationships between
(objects every department must include at least ten
faculty members)
• In the context of the web, ontologies provide a shared understanding of a
domain.
• Such a shared understanding is necessary to overcome differences in
terminology.
• One application’s zip code may be the same as another application’s
postcode.
• Another problem is that two applications may use the same term with
different meanings.
• In university A, a course may refer to a degree (like computer science),
while in university B it may mean a single subject (CS 101).
• Such differences can be overcome by mapping the particular terminology
to a shared ontology or by defining direct mappings between the
ontologies.
• In either case, it is easy to see that ontologies support semantic
interoperability.
• Ontologies are useful for the organization and navigation of websites.
• Many websites today expose on the left-hand side of the page the top
levels of a concept hierarchy of terms.
• The user may click on one of them to expand the subcategories.
• Also, ontologies are useful for improving the accuracy of web searches.
• The search engines can look for pages that refer to a precise concept in an
ontology instead of collecting all pages in which certain, generally
ambiguous, keywords occur.
•In this way, differences in terminology between web pages
and queries can be overcome.
•In addition, web searches can exploit
generalization/specialization information.
•If a query fails to find any relevant documents, the search
engine may suggest to the user a more general query.
• It is even conceivable for the engine to run such queries
proactively to reduce the reaction time in case the user adopts
a suggestion.
•Or if too many answers are retrieved, the search engine may
suggest to the user some specializations
•In Artificial Intelligence (AI) there is a long tradition of
developing and using ontology languages.
•It is a foundation Semantic Web research can build on.
•At present, the most important ontology languages for the
web are the following:
• RDF Schema is a vocabulary description language for
describing properties and classes of RDF resources, with a
semantics for generalization hierarchies of such properties
and classes.
•In addition, domain and range of properties may be defined.
•OWL is a richer vocabulary description language
for describing properties and classes, such as
•relations between classes (e.g., disjointness),
•cardinality (e.g., “exactly one”),
•equality,
•richer typing of properties,
•characteristics of properties (e.g., symmetry), and
•enumerated classes
Logic
• Logic is the discipline that studies the principles of reasoning; it goes
back to Aristotle.
• In general, logic first offers formal languages for expressing
knowledge.
• Second, logic provides us with well-understood formal semantics:
• in most logics, the meaning of sentences is defined without the need to
operationalize the knowledge.
• Often we speak of declarative knowledge: we describe what holds
without caring about how it can be deduced
• And third, automated reasoners can deduce (infer) conclusions from
the given knowledge, thus making implicit knowledge explicit.
• Such reasoners have been studied extensively in AI.
• Here is an example of an inference.
• Suppose we know that all professors are faculty members, that all
faculty members are staff members, and that Michael is a professor.
• In predicate logic the information is expressed as follows:
• Note that this example involves knowledge typically found in ontologies.
• Thus logic can be used to uncover ontological knowledge that is
implicitly given.
• By doing so, it can also help uncover unexpected relationships and
inconsistencies.
• But logic is more general than ontologies.
• It can also be used by intelligent agents for making decisions and
selecting courses of action.
• For example, a shop agent may decide to grant a discount to a customer
based on the rule
• Generally there is a trade-off between expressive power and
computational efficiency.
• The more expressive a logic is, the more computationally expensive it
becomes to draw conclusions.
• And drawing certain conclusions may become impossible if
noncomputability barriers are encountered.
• Luckily, most knowledge relevant to the Semantic Web seems to be
of a relatively restricted form.
• For example, our previous examples involved rules of the form,
• “If conditions, then conclusion,”
• where conditions and conclusion are simple statements,
• only a finite number of objects need to be considered.
• This subset of logic, called Horn logic, is tractable and supported by
efficient reasoning tools.
• An important advantage of logic is that it can provide explanations for
conclusions:
• the series of inference steps can be retraced.
• Moreover, AI researchers have developed ways of presenting an explanation
in a human-friendly way,
• by organizing a proof as a natural deduction and
• by grouping a number of low-level inference steps into metasteps that a person will
typically consider a single proof step.
• Ultimately an explanation will trace an answer back to a given set of facts
and the inference rules used.
• Explanations are important for the Semantic Web because they increase
users’ confidence in Semantic Web agents.
• Here is a simple example.
• Suppose agent 1, representing an online shop, sends a message “You
owe me $80” (not in natural language, of course, but in a formal,
machine-processable language) to agent 2, representing a person.
• Then agent 2 might ask for an explanation, and agent 1 might respond
with a sequence of the form
• Thus facts will typically be traced to some web addresses (the trust of
which will be verifiable by agents), and the rules may be a part of a shared
commerce ontology or the policy of the online shop.
• For logic to be useful on the web it must be usable in conjunction with
other data, and it must be machine-processable as well.
• Therefore, there is ongoing work on representing logical knowledge and
proofs in web languages.
• Initial approaches work at the level of XML, but in the future rules and
proofs will need to be represented at the level of RDF and ontology
languages.
The Semantic Web versus Artificial Intelligence
• Most of the technologies needed for the realization of the Semantic Web
build on work in the area of artificial intelligence.
• Given that AI has a long history, not always commercially successful, one
might worry that, in the worst case, the Semantic Web will repeat AI’s
errors:
• big promises that raise too high expectations, which turn out not to be fulfilled (at
least not in the promised time frame)
• This worry is unjustified.
• The realization of the Semantic Web vision does not rely on human-level
intelligence;
• in fact, as we have tried to explain, the challenges are approached in a different
way.
• The full problem of AI is a deep scientific one, perhaps comparable to the
central problems of physics (explain the physical world) or biology
(explain the living world).
• So seen, the difficulties in achieving human-level Artificial Intelligence
within ten or twenty years, as promised at some points in the past, should
not have come as a surprise.
• on the Semantic Web partial solutions work.
• Even if an intelligent agent is not able to come to all conclusions that a
human user might, the agent will still contribute to a web much superior
to the current one.
• This brings us to another difference.
• If the ultimate goal of AI is to build an intelligent agent exhibiting human-level
intelligence (and higher)
• the goal of the Semantic Web is to assist human users in their day-to-day online
activities
• It is clear that the Semantic Web makes extensive use of current AI
technology and that advances in that technology will lead to a better
Semantic Web.
• But there is no need to wait until AI reaches a higher level of
achievement;
• current AI technology is already sufficient to go a long way toward realizing the Semantic Web
vision
A Layered Approach
 A Layered Approach
• The development of the Semantic Web proceeds in steps, each step building a
layer on top of another.
• The pragmatic justification for this approach is that it is easier to achieve
consensus on small steps, whereas it is much harder to get everyone on board if
too much is attempted.
• Usually there are several research groups moving in different directions; this
competition of ideas is a major driving force for scientific progress.
• However, from an engineering perspective there is a need to standardize.
• So, if most researchers agree on certain issues and disagree on others, it makes
sense to fix the points of agreement.
• This way, even if the more ambitious research efforts should fail, there will be
at least partial positive outcomes
• Once a standard has been established, many more groups and companies
will adopt it instead of waiting to see which of the alternative research lines
will be successful in the end.
• The nature of the Semantic Web is such that companies and single users
must build tools, add content, and use that content.
• We cannot wait until the full Semantic Web vision materializes
• it may take another ten years for it to be realized to its full extent
• In building one layer of the Semantic Web on top of another, two
principles should be followed:
• Downward compatibility.
• Agents fully aware of a layer should also be able to interpret and use information written at
lower levels.
• For example, agents aware of the semantics of OWL can take full advantage of information
written in RDF and RDF Schema.
• Upward partial understanding.
• The design should be such that agents fully aware of a layer should be able to take
at least partial advantage of information at higher levels.
• For example, an agent aware only of the RDF and RDF Schema semantics might
interpret knowledge written in OWL partly, by disregarding those elements that
go beyond RDF and RDF Schema.
• Of course, there is no requirement for all tools to provide this
functionality;
• the point is that this option should be enabled
• While these ideas are theoretically appealing and have been used as
guiding principles for the development of the Semantic Web, their
realization in practice has turned out to be difficult, and some
compromises have needed to be made.
• At the bottom we find XML, a language that lets one write structured
web documents with a user-defined vocabulary.
• XML is particularly suitable for sending documents across the web.
• In addition, URIs used in XML can be grouped by their namespace,
signified by NS in the diagram.
• RDF is a basic data model, like the entity-relationship model, for writing
simple statements about web objects (resources).
• The RDF data model does not rely on XML, but RDF has an XML-based
syntax.
• Therefore, in figure it is located on top of the XML layer.
• RDF Schema provides modeling primitives for organizing web objects
into hierarchies.
• Key primitives are classes and properties, subclass and subproperty
relationships, and domain and range restrictions.
• RDF Schema is based on RDF.
• RDF Schema can be viewed as a primitive language for writing ontologies.
• But there is a need for more powerful ontology languages that expand
RDF Schema and allow the representations of more complex relationships
between web objects.
• The Logic layer is used to enhance the ontology language further and to
allow the writing of application-specific declarative knowledge.
• The Proof layer involves the actual deductive process as well as the
representation of proofs in web languages (from lower levels) and proof
validation.
• Finally, the Trust layer will emerge through the use of digital signatures
and other kinds of knowledge, based on recommendations by trusted
agents or on rating and certification agencies and consumer bodies.
• Sometimes “Web of Trust” is used to indicate that trust will be organized
in the same distributed and chaotic way as the web itself.
• Being located at the top of the pyramid, trust is a high-level and crucial
concept:
• the web will only achieve its full potential when users have trust in its operations
(security) and in the quality of information provided.
• This classical layer cake was a major driver in the agenda of the
Semantic Web, but is now quite outdated.
• In particular, a number of alternatives for the ontology vocabulary layer
have emerged.
• In addition, rule languages have been defined on top of RDF, bypassing
the ontology vocabulary layer;
• this is particularly true in the recent shift from rich semantic structures to the
processing of huge amounts of (semantic) data.
• Thus, this layer cake is included here for illustration purposes, as a
means of presenting a historic view of the Semantic Web.
Describing Web Resources: RDF
• Introduction
• RDF: Data Model
• RDF Syntaxes
• RDFS: Adding Semantics
• RDF Schema: The Language
• RDF and RDF Schema in RDF Schema
• An Axiomatic Semantics for RDF and RDF Schema
• A Direct Inference System for RDF and RDFS
Describing Web
Resources:
RDF
Introduction
Introduction
• The success of the WWW has shown the power of having standard
mechanisms to exchange and communicate information.
• HTML is the standard language in which web pages are written.
• It allows anyone to publish a document and have confidence that
this document will be rendered correctly by any web browser.
• There are three components that HTML and any exchange
language has:
• a syntax,
• a data model,
• and a semantics.
• A syntax tells us how to write data down.
• A data model tells us the structure or organization of the data.
• A semantics tells us how to interpret that data.
• Each of these components with a snippet of HTML is given

<html>
<head>
<title>Apartments for Rent</title>
</head>
<body>
<ol>
<li> Studio apartment on Florida Ave.
<li> 3 bedroom Apartment on Baron Way
</ol>
</body>
</html>
• The syntax of HTML is text with tags (e.g. <title>) written using angle
brackets.

• The data model of HTML, known as the Document Object Model,

defines the organization of these elements defined by tags into a
hierarchical tree structure.

• For example, <head> should come before <body> and <li> elements
should appear within <ol> elements.

• Finally, the semantics of HTML tell us how the browser should

interpret the web page.
• For example, the browser should render the content of the web page’s body within the
browser window and <ol> elements should be displayed as an ordered list.

• The syntax, data model, and semantics are all defined within the HTML standard.

• HTML is designed to communicate information about the structure of documents for human
consumption.

• For the Semantic Web, we need something richer.

• We need a data model that can be used by multiple applications, not just for describing
documents for people but for describing application-specific information.
• This data model needs to be domain independent so that applications
ranging from real estate to social networks can leverage it.

• In addition to a flexible data model, we also need a mechanism to assign

semantics to the information represented using this data model.

• It should allow users to describe how an application should interpret

“friend” in a social network description and “city” in a geographical
description.

• Finally, like HTML, we need a way to write down all this information

– a syntax
• RDF (Resource Description Framework) provides just such a flexible
domain independent data model.

• Its basic building block is an entity-attribute-value triple, called a

statement.

• Examples of statements we can represent using such a model include

• “The Baron Way Apartment is an Apartment,”
• “The Baron Way Apartment is part of The Baron Way Building,”
• “The Baron Way Building is located in Amsterdam.”
• Because RDF is not particular to any domain or use, it is necessary for users
to define the terminology they use within these statements.

• To do this, they make use of RDF Schema (RDFS).

• RDFS allows users to precisely define how their vocabulary (i.e. their
terminology) should be interpreted.
•Combined, these technologies define the components of a
standard language for exchanging arbitrary data between
machines:
• RDF – data model
• RDFS – semantics
• Turtle / RDFa/ RDF-XML – syntax

•While RDF is primarily the data model within this language, it

is often used as the name for the whole of it
RDF: Data Model
•The fundamental concepts of RDF are
•Resources,
•Properties,
•Statements, and
•Graphs
Resources
•Resource as an object, represents a “thing”
•Resources may be authors, apartments, tennis players, places,
people, hotels, search queries, and so on.
•Every resource has a URI.
•A URI can be a URL (Uniform Resource Locator, or web
address) or another kind of unique identifier.
•URI schemes have been defined not only for web locations
but also for
• telephone numbers,
• ISBN numbers, and
• geographic locations.
•URIs provide a mechanism to unambiguously identify the “thing”
we want to talk about.
•Thus, if referring to a swimming pool, we can use a URI assigned
to swimming pools and not have it be confused with billiards
(pool) or a group of people (the pool of programmers).
•This is known as the homonym problem.
•The use of a URI does not necessarily enable access to a resource.
•However, using dereferenceable URLs for resource identifiers is
considered good practice
•It enables users to
•either retrieve a resource itself (in the case of an image)
•or a further description of that resource (in case of a person).
•The use of URIs is one of the key design decisions behind
RDF.
•It allows for a global, worldwide unique naming scheme.
•The use of such a scheme greatly reduces the homonym
problem that has plagued distributed data representation
until now.
Properties
•Properties are a special kind of resource;
•they describe relations between other resources. for
example,
- “friend of,”
- “written by,” and
- “located in.”
•Like all resources, properties are identified by URIs.
Statements
•Statements assert the properties of resources.
•A statement is an entity-attribute-value triple, consisting of
• resource,
• property, and
• value.
•The value can either be a resource or a literal.
•Literals are atomic values – for example
• numbers,
• strings, or
• dates.
 • We often use the word subject to refer to the entity in a statement and
object to refer to its value.
• Take an example statement
“Baron Way Building is located in Amsterdam.”
• We can write this as:
<http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayBu
ilding>
<http://dbpedia.org/ontology/location>
<http://dbpedia.org/resource/Amsterdam>.
• Notice how we used URLs to identify the things we are referring to in our
statement.
Graphs
• We can also write this same statement down graphically.
• Note that we leave off the URIs in the picture for readability.

• In figure labeled nodes are connected by labeled arcs.

• The arcs are directed from the subject of the statement to the object of the
statement, with the label on the arc to the statement’s property.
• The labels on the nodes are the identifiers of the subject and object.
• The object of a statement can be the subject of another statement.
• For example, we can say that “Amsterdam is a city.”
• This graphical representation highlights the notion that RDF is a graph-centric data
model.
• Indeed, RDF resembles what is termed a semantic net in the Artificial Intelligence
community.
• It can be continued to expand the graph with information about the Baron Way
Building.
• It shows an expanded version of our RDF graph.
• Importantly, this graph can be created in a distributed fashion by multiple different
participants just by using the same URLs.
• This allows us to create a Web of Data allowing for knowledge to be reused;
• for example, if we find RDF on the web describing Amsterdam, we can reuse that information just
by using that URL.
• Indeed, there is a set of best practices, called the Linked Data principles, that
encourage us to reuse and make available information to help create this global graph
1. Use URIs as names for things.
2. Use HTTP URIs so that people can look up those names.
3.When someone looks up a URI, provide useful
information, using the standards (RDF).
4. Include links to other URIs so that they can discover
more things.
•While the RDF data model does not require that we follow
these principles, by doing so we can take advantage of the
contributed knowledge of others.
Pointing to Statements and Graphs
• Sometimes it is useful to be able to point to particular statements and parts
of graphs, such as when assigning a degree of belief in a statement or
identifying where a statement has come from.
• For example, we may want to say that the statement about the location of
the BaronWay Building was created by a person, Frank.
• RDF provides two mechanisms for doing so.
• One is called reification.
• The key idea behind reification is to introduce an auxiliary object, say,
LocationStatement, and relate it to each of the three parts of the original statement
through the properties subject, predicate, and object.
• In the preceding example the subject of LocationStatement would be
BaronWayBuilding, the predicate would be location, and the object Amsterdam.
• We can then refer to the statement in the subject of another triple that defines the
creator.
• Figure depicts the resulting graph.
• Again, the full URIs are not shown for presentation purposes.
• This rather cumbersome approach is necessary because there are only triples in RDF;
therefore we cannot add an identifier directly to a triple (then it would be a
quadruple).
• Because of the overhead of reification, in newer versions of the RDF
standard, the notion of named graphs was introduced.
• URL is given to a statement or set of statements.
• This identifier can then be referred to in normal triples.
• This is a more straightforward mechanism for identifying statements
as well as graphs.
• Simply put, a named graph allows one to circle a set of RDF
statements and provide these statement an identifier.
Dealing with Richer Predicates
• We can think of a triple (x, P, y) as a logical formula P(x, y), where the
binary predicate P relates the object x to the object y.
• In fact, RDF offers only binary predicates (properties).
• However, in some cases we may need predicates that have more than
two arguments.
• Luckily, such predicates can be simulated by a number of binary
predicates.
• We illustrate this technique for a predicate broker with three arguments.
• broker(X, Y, Z) is X is the broker in a home sale between seller Y and purchaser
Z.
•We now introduce a new auxiliary resource home-sale and
the binary predicates broker,seller, and purchaser.
•Then we can represent broker(X, Y, Z) as follows:
•broker(home-sale, X)
•seller(home-sale, Y)
•purchaser(home-sale, Z)
•While the predicate with three arguments is more succinct
to write, the use of binary predicates does simplify the
overall data model.
 RDF Syntaxes
1. Turtle
1. Literals
2. Abbreviations
3. Named Graphs

2. Other Syntaxes
1. RDF/XML
2. RDFa
Turtle
• Already seen graphical syntax for RDF neither machine interpretable nor
standardized.
• Here newly introduced standard machine interpretable syntax is called Turtle - Terse
RDF Triple Language (Turtle) is a text-based syntax for RDF.
• The file extension used for Turtle text files is “.ttl”.
• We have already seen how to write a statement in Turtle earlier.
• Here’s an example:

<html>
<body>
<H1> Baron Way Apartment for Sale</H1>
The Baron Way Apartment has three bedrooms and is located in the family
friendly Baron Way Building. The Apartment is located in the north of Amsterdam.
</body>
</html>
• URLs are enclosed in angle brackets.
• The subject, property, and object of a statement appear in order, followed
by a period.
• Indeed, we can write a whole RDF graph just using this approach.
1. Literals
• So far we have defined statements that link together resources.
• Literals, that is, atomic values within RDF.
• In Turtle, we write this down by simply enclosing the value in quotes
and appending it with the data type of the value.
• A data type tells us whether we should interpret a value as string, a
date, integer or some other type.
• Data types are again expressed as URLs.
• It is recommend practice to use the data types defined by XML
Schema.
• When using these data types the values must conform to the XML
Schema definition.
• If no data type is specified after a literal, it is assumed to be a string.
Here are some common data types and how they look in Turtle:
string - ‘‘Baron Way’’
integers - ‘‘1’’^^<http://www.w3.org/2001/XMLSchema#integer>
decimals - ‘‘1.23’’ <http://www.w3.org/2001/XMLSchema#decimal>
dates - ‘‘1982-08-30’’^^http://www.w3.org/2001/XMLSchema#date
time - ‘‘11:24:00’’^^<http://www.w3.org/2001/XMLSchema#time>
date with a time - ‘‘1982-08-30T11:24:00’’^^<http://www.w3.org/2001/XMLSchema#dateTime>
Suppose that we want to add to our graph that the Baron Way Apartment has three bedrooms. We
would add the following statement in Turtle to our graph.
<http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayApartment>
<http://www.semanticwebprimer.org/ontology/apartments.ttl#hasNumberOfBedrooms>
"3"^^<http://www.w3.org/2001/XMLSchema#integer>.
<http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayApartment>
<http://www.semanticwebprimer.org/ontology/apartments.ttl#isPartOf>
<http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayBuilding>.
<http://www.semanticwebprimer.org/ontology/apartments.ttl#BaronWayBuilding>
<http://dbpedia.org/ontology/location>
<http://dbpedia.org/resource/Amsterdam>
2. Abbreviations
• Often when we define vocabularies, we do so at the same URI.
• In our example, the resources Baron Way Apartment and Baron Way Building are both
defined at the URL http://www.semanticwebprimer.org/ontology/apartments.ttl.
• This URL defines what is termed the namespace of those resources.
• Turtle takes advantage of this convention to allow URLs to be abbreviated.
• It introduces the @prefix syntax to define short stand-ins for particular namespaces.
• For example, we can say that swp should be the stand-in for
http://www.semanticwebprimer.org/ontology/apartments.ttl.
• Such a stand-in is termed a qualified name.
Example using prefixes
@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.
@prefix dbpedia: <http://dbpedia.org/resource/>.
@prefix dbpedia-owl: <http://dbpedia.org/ontology/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
swp:BaronWayApartment swp:hasNumberOfBedrooms "3"^^<xsd:integer>.
swp:BaronWayApartment swp:isPartOf swp:BaronWayBuilding.
swp:BaronWayBuilding dbpedia-owl:location dbpedia:Amsterdam
• Note that the angle brackets are dropped from around resources that are referred to
using a qualified name
• Secondly, we can mix and match regular URLs with these qualified names.
• Turtle also allows us to not repeat particular subjects when they are used
repeatedly.
• In the example above, swp:BaronWayApartment is used as the subject of two
triples.
• This can be written more compactly by using a semicolon at the end of a
statement.
• For example:
@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.
@prefix dbpedia: <http://dbpedia.org/resource/>.
@prefix dbpedia-owl: <http://dbpedia.org/ontology/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
swp:BaronWayApartment swp:hasNumberOfBedrooms "3"^^<xsd:integer>;
swp:isPartOf swp:BaronWayBuilding.
swp:BaronWayBuilding dbpedia-owl:location dbpedia:Amsterdam.
• If both a subject and predicate are used repeatedly, we can use a comma at the
end of a statement.
• For instance, if we want to extend our example to say that Baron Way Building
is not only located in Amsterdam but also in the Netherlands,
• we can write the following Turtle:

@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.

@prefix dbpedia: <http://dbpedia.org/resource/>.
@prefix dbpedia-owl: <http://dbpedia.org/ontology/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
swp:BaronWayApartment swp:hasNumberOfBedrooms "3"^^<xsd:integer>;
swp:isPartOf swp:BaronWayBuilding.
swp:BaronWayBuilding dbpedia-owl:location
dbpedia:Amsterdam,dbpedia:Netherlands.
• Finally, Turtle also allows us to abbreviate common data types.
• For example, numbers can be written without quotes.
• If they contain a decimal (e.g. 14.3), they are interpreted as decimals.
• If they do not contain a decimal (e.g. 1), they are interpreted as integers.
• This shortens our example some more:

@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.

@prefix dbpedia: <http://dbpedia.org/resource/>.
@prefix dbpedia-owl: <http://dbpedia.org/ontology/>.
swp:BaronWayApartment swp:hasNumberOfBedrooms 3;
swp:isPartOf swp:BaronWayBuilding.
swp:BaronWayBuilding dbpedia-owl:location
dbpedia:Amsterdam,dbpedia:Netherlands.
3. Named Graphs
• The ability to point to a set of statements together.
• Trig is an extension to Turtle that allows us to express such a notion.
• For example, we might want to say that our statements about the Baron
Way Apartment were created by a person, Frank, identified by the URL
http://www.cs.vu.nl/~frankh.
• We do this by putting brackets around the set of statements we want and
assigning that set of statements a URL
• In this approach, statements that are not part of a particular graph go in a
set of brackets without a URL in front.
• This is called the default graph.
• Let’s look at an example:
@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.
@prefix dbpedia: <http://dbpedia.org/resource/>.
@prefix dbpedia-owl: <http://dbpedia.org/ontology/>.
@prefix dc: <http://purl.org/dc/terms/>.
{
<http://www.semanticwebprimer.org/ontology/apartments.ttl#>
dc:creator <http://www.cs.vu.nl/ frankh>
}
<http://www.semanticwebprimer.org/ontology/apartments.ttl#>
{
swp:BaronWayApartment swp:hasNumberOfBedrooms 3;
swp:isPartOf swp:BaronWayBuilding.
swp:BaronWayBuilding dbpedia-owl:location dbpedia:Amsterdam,
dbpedia:Netherlands.
}
Other Syntaxes
•Besides Turtle, there are a number of other syntaxes
that we can use to write down RDF.
•Among them are two other standard syntaxes:
• RDF/XML
• RDFa.
1. RDF/XML
• RDF/XML is an encoding of RDF in the XML language.
• This allows RDF to be used with existing XML processing tools.
• Originally, RDF/XML was the only standard syntax for RDF.
• However, Turtle was adopted as an additional standard as it is often easier
to read.
• Below is RDF/XML.
• Subjects are denoted by the rdf:about within an rdf:Description element
(enclosed in brackets).
• Predicates and objects related to that subject are enclosed in the
rdf:Description element.
• Namespaces can be used through the XML namespaces (xmlns:) construct.
All RDF/XML should be enclosed in an element rdf:RDF.
 <rdf:Description
<?xml version="1.0" encoding="utf-8"?>
rdf:about="http://www.semanticwebprimer.org/ontology/apartments.tt
<rdf:RDF l#BaronWayApartment">
xmlns:dbpedia-owl="http://dbpedia.org/ontology/" <swp:isPartOf
rdf:resource="http://www.semanticwebprimer.org/ontology/apartment
xmlns:dbpedia="http://dbpedia.org/resource/" s.ttl#BaronWayBuilding"/>
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax </rdf:Description>
-ns#" <rdf:Description
xmlns:swp="http://www.semanticwebprimer.org/onto rdf:about="http://www.semanticwebprimer.org/ontology/apartments.tt
logy/apartments.ttl#"> l#BaronWayBuilding">
<dbpedia-owl:location
<rdf:Description
rdf:resource="http://dbpedia.org/resource/Amsterdam"/>
rdf:about="http://www.semanticwebprimer.org/ontolo
gy/apartments.ttl#BaronWayApartment"> </rdf:Description>
<rdf:Description
<swp:hasNumberOfBedrooms
rdf:about="http://www.semanticwebprimer.org/ontology/apartments.tt
rdf:datatype="http://www.w3.org/2001/XMLSchema l#BaronWayBuilding">
#integer"> <dbpedia-owl:location
3 rdf:resource="http://dbpedia.org/resource/Netherlands"/>
</swp:hasNumberOfBedrooms> </rdf:Description>
</rdf:RDF>
</rdf:Description>
2. RDFa
• One use case of RDF is to describe or mark up the content of HTML web pages.
• In order to make it easier, a syntax RDFa was introduced to help with that use case.
• RDFa embeds RDF within the attributes of HTML tags.
• We’ll use an example of advertisement for the Baron Way Apartment.

<html>
<body>
<H1> Baron Way Apartment for Sale</H1>
The Baron Way Apartment has three bedrooms and is located in the family
friendly Baron Way Building. The Apartment is located in the north of Amsterdam.
</body>
</html>
• This page does not contain any machine readable description. We can mark up the page using RDFa as follows:
<html xmlns:dbpedia="http://dbpedia.org/resource/"
xmlns:dbpediaowl="http://dbpedia.org/ontology/"
xmlns:swp="http://www.semanticwebprimer.org/ontology/apartments.ttl#"
xmlns:geo="http://www.geonames.org/ontology#">
<body>
<H1> Baron Way Flat for Sale</H1>
<div about="[swp:BaronWayFlat]">
The BaronWay Flat has <span property="swp:hasNumberOfBedrooms">3</span> bedrooms
and is located in the family friendly <span rel="swp:isPartOf" resource="[
swp:BaronWayBuilding]">Baron Way Building</span>
<div about="[swp:BaronWayBuilding]">
The building is located in the north of Amsterdam.
<span rel="dbpediaowl:location" resource="[dbpedia:Amsterdam]"></span>
<span rel="dbpediaowl:location" resource="[dbpedia:Netherlands]"></span>
</div>
</div>
</body>
</html>
• This markup will produce the same RDF expressed above in Turtle.
• Since the RDF is encoded in tags such as spans, paragraphs, and links, the
RDF will not be rendered by browsers when displaying the HTML page.
• Similar to RDF/XML, namespaces are encoded using the xmlns
declaration.
• In some cases, we must use brackets to inform the parser that we are using
prefixes.
• Subjects are identified by the about attribute.
• Properties are identified by either a rel or property attribute.
• Rel attributes are used when the object of the statement is a resource
whereas a property attribute is used when the object of a statement is a
literal.
•Properties are associated with subjects through the use of the
hierarchal structure of HTML.
•Each syntax for RDF presented above is useful for different
situations.
•However, it is important to realize that even though different
syntaxes may be used, they all share the same underlying data
model and semantics.
•How to write down statements about things identified by URLs
have discussed
•But what do those statements mean?
•How should a computer go about interpreting the statements
made?
RDFS: Adding Semantics
1. Classes and Properties
2. Class Hierarchies and Inheritance
3. Property Hierarchies
4. RDF versus RDFS Layers
•RDF is a universal language that lets users describe
resources using their own vocabularies.
•RDF does not make assumptions about any particular
application domain, nor does it define the semantics of
any domain.
•In order to specify these semantics, a developer or user of
RDF needs to define what those vocabularies mean in
terms of a set of basic domain independent structures
defined by RDF Schema.
1. Classes and Properties
• How do we describe a particular domain?
• Let us consider our domain of apartment rentals.
• First we have to specify the “things” we want to talk about.
• Here we make a first, fundamental distinction.
• On one hand, we want to talk about particular apartments, such as the
BaronWay Apartment, and particular locations, such as Amsterdam; we
have already done so in RDF.
• But we also want to talk about apartments, buildings, countries, cities, and
so on.
• What is the difference?
• In the first case we talk about individual objects (resources), and in the second about
classes that define types of objects.
• A class can be thought of as a set of elements.
• Individual objects that belong to a class are referred to as instances of that
class.
• RDF provides us a way to define the relationship between instances and
classes using a special property rdf:type.
• An important use of classes is to impose restrictions on what can be stated
in an RDF document using the schema.
• In programming languages, typing is used to prevent nonsense from being
written
• such as A+1, where A is an array;
• we lay down that the arguments of + must be numbers).

• The same is needed in RDF.

•After all, we would like to disallow statements such as:
• Baron Way Apartment rents Jeff Meyer
• Amsterdam has number of bedrooms
•The first statement is nonsensical because buildings do not rent
people.
•This imposes a restriction on the values of the property “rents.”
•In mathematical terms, we restrict the range of the property.
•The second statement is nonsensical because cities do not have
bedrooms.
•This imposes a restriction on the objects to which the property
can be applied.
•In mathematical terms, we restrict the domain of the property.
2. Class Hierarchies and Inheritance
•Once we have classes, we would also like to establish
relationships between them.
•For example, suppose that we have classes for unit
residential unit commercial unit house & apartment
office
•These classes are not unrelated to each other.
•For example, every residential unit is a unit.
•The“residential unit” is a subclass of “unit,” or
equivalently, that “unit” is a superclass of “residential
unit.”
• In general, A is a subclass of B if
every instance of A is also an
instance of B. A hierarchy of classes is shown in
• There is no requirement in RDF figure
Schema that the classes together
form a strict hierarchy.
• In other words, a subclass graph as
in figure need not be a tree.
• A class may have multiple
superclasses.
• If a class A is a subclass of both B1
and B2, this simply means that every
instance of A is both an instance of
B1 and an instance of B2
• A hierarchical organization of classes has a very important practical
significance
• Consider the range restriction People can only rent residential units.
• Suppose Baron Way Apartment is defined as an apartment.
• Then, according to the preceding restriction, it does not qualify as a
Residential Unit because there is no statement specifying that the Baron
Way Apartment is also a residential unit.
• It would be counterintuitive to overcome this difficulty by adding that
statement to our description.
• Instead we would like the Baron Way Apartment to inherit the ability to be
rented from the class of residential units.
• Exactly this is done in RDF Schema.
• By doing so, RDF Schema fixes the semantics of “is a subclass of.”
• Now it is not up to an application to interpret “is a subclass of;” instead its
intended meaning must be used by all RDF processing software.
• By making such semantic definitions, RDFS is a (still limited) language for
defining the semantics of particular domains.
• Stated another way, RDF Schema is a primitive ontology language.
• Classes, inheritance, and properties are, of course, known in other fields of
computing for example, in object-oriented programming.
• But while there are many similarities, there are differences, too.
• In object-oriented programming, an object class defines the properties that
apply to it.
• To add new properties to a class means to modify the class.
• However, in RDFS, properties are defined globally.
• That is, they are not encapsulated as attributes in class definitions.
• It is possible to define new properties that apply to an existing class
without changing that class.
• On one hand, this is a powerful mechanism with far-reaching
consequences:
- We may use classes defined by others and adapt them to our
requirements through new properties.
• On the other hand, this handling of properties deviates from the standard
approach that has emerged in the area of modeling and object-oriented
programming.
• It is another idiosyncratic feature of RDF/RDFS.
3. Property Hierarchies
•We saw that hierarchical relationships between classes can be
defined.
•The same can be done for properties. For example,
“rents” is a subproperty of “resides at.”
•If a person p rents a residential unit r, then p also resides at r.
•The converse is not necessarily true.
•For example, p may be a child living with a family and not
paying rent or a person may be just visiting.
•In general, if some property P is a subproperty of Q if Q(x, y)
whenever P(x, y).
4. RDF versus RDFS Layers
• As a final point, we illustrate the different layers involved in RDF and RDFS using
a simple example.
• Consider the RDF statement Jeff Meyer rents the Baron Way Apartment.
• The schema for this statement may contain classes such as person, apartments,
houses, units, and properties such as rents, resides at, or address.
• Figure illustrates the layers of RDF and RDF Schema for this example.
• In this figure, blocks are properties, bubbles above the dashed line are classes, and
bubbles below the dashed line are instances.
• The schema in figure is itself written in a formal language, RDF Schema, that can
express its ingredients:
• subClassOf,
• Class,
• Property,
• subPropertyOf,
• Resource, and so on.
• Next we describe the language of RDF Schema in more detail.
RDF Schema: The Language
1. Core Classes
2. Core Properties for Defining Relationships
3. Core Properties for Restricting Properties
4. Useful Properties for Reification
5. Container Classes
6. Utility Properties
7. Example: Housing
8. Example: Motor Vehicles
RDF Schema: The Language
• RDF Schema provides modeling primitives for expressing the
information.
• One decision that must be made is what formal language to use.
• It should not be surprising that RDF itself will be used: the modeling
primitives of RDF Schema are defined using resources and properties.
• We presented this figure as displaying a class/property hierarchy plus
instances, but it is, of course, itself simply a labeled graph that can be
encoded in RDF.
• Remember that RDF allows one to express any statement about any
resource, and that anything with a URI can be a resource.
• The class “apartment” is a subclass of “residential unit,” .
1. Define the required resources for apartment, residential unit, and
subClassOf;
2. define subClassOf to be a property;
3. write the triple (apartment subClassOf residential unit).

• All these steps are within the capabilities of RDF.

• So, an RDFS document is just an RDF document, and we use one of the
standard syntaxes for RDF.
• Now we define the modeling primitives of RDF Schema.
1.Core Classes
•The core classes are
•rdfs:Resource, the class of all resources
•rdfs:Class, the class of all classes
•rdfs:Literal, the class of all literals (strings)
•rdf:Property, the class of all properties
•rdf:Statement, the class of all reified statements
2. Core Properties for Defining Relationships
• The core properties for defining relationships are
1. rdf:type,
• which relates a resource to its class
• The resource is declared to be an instance of that class.
2. rdfs:subClassOf,
• which relates a class to one of its superclasses.

• All instances of a class are instances of its superclass.

• Note that a class may be a subclass of more than one class.
• As an example, the class femaleProfessor may be a subclass of both female and
professor.
3. rdfs:subClassOf,
• which relates a class to one of its superclasses.
• All instances of a class are instances of its superclass.
• Note that a class may be a subclass of more than one class.
• As an example, the class femaleProfessor may be a subclass of both
female and professor.

4. rdfs:subPropertyOf,
• which relates a property to one of its superproperties.
• Here is an example stating that all apartments are residential units:
swp:apartment refs:subClassOf swp:ResidentialUnit
• Note that rdfs:subClassOf and rdfs:subPropertyOf are transitive, by
definition.
• Also, it is interesting that rdfs:Class is a subclass of rdfs:Resource
(every class is a resource),
• and rdfs:Resource is an instance of rdfs:Class (rdfs:Resource is the class
of all resources, so it is a class!).
• For the same reason, every class is an instance of rdfs:Class.
3. Core Properties for Restricting Properties
• The core properties for restricting properties are
• rdfs:domain, which specifies the domain of a property P and states that any
resource
• that has a given property is an instance of the domain classes.
• rdfs:range, which specifies the range of a property P and states that the
values of a
• property are instances of the range classes.
• Here is an example stating that whenever any resource has an
address, it is (by inference)
• a unit and that its value is a literal:
• swp:address rdfs:domain swp:Unit.
• swp:address refs:range rdf:Literal.
4.Useful Properties for Reification
•The following are some useful properties for
reification:
•rdf:subject, which relates a reified statement to its subject
•rdf:predicate, which relates a reified statement to its
predicate
•rdf:object, which relates a reified statement to its object

Reification:
The key idea behind reification is to introduce an auxiliary object, say, LocationStatement, and relate
it to each of the three parts of the original statement through the properties subject, predicate, and
object.
5. Container Classes
• RDF also allows for containers to be represented in a standard way.
• One can represent bags, sequences, or alternatives (i.e., choice).
• rdf:Bag, the class of bags,
• rdf:Seq, the class of sequences,
• rdf:Alt, the class of alternatives,
• rdfs:Container, a superclass of all container classes, including the three
preceding ones.
6. Utility Properties
•A resource may be defined and described in many places on
the web.
•The following properties allow us to define links to those
addresses:
• rdfs:seeAlso relates a resource to another resource that explains it.
• rdfs:isDefinedBy is a subproperty of rdfs:seeAlso and relates a
resource to the place where its definition, typically an RDF schema,
is found.
Often it is useful to provide more information intended for human
readers. This can be done with the following properties:
• rdfs:comment.
• Comments, typically longer text, can be associated with a resource.
• rdfs:label.
• A human-friendly label (name) is associated with a resource.
• Among other purposes, it may serve as the name of a node in a graphic
representation of the RDF document.
7. Example: Housing
We refer to the housing example, and provide a conceptual model of the domain, that is, an ontology.
@prefix swp: <http://www.semanticwebprimer.org/ontology/apartments.ttl#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
swp:Person rdf:type rdfs:Class.
swp:Person rdfs:comment "The class of people".
swp:Unit rdf:type rdfs:Class.
swp:Unit rdfs:comment "A self-contained section of accommodations in a larger building or group of buildings.".
swp:ResidentialUnit rdf:type rdfs:Class.
swp:ResidentialUnit rdfs:subClassOf swp:Unit.
swp:ResidentialUnit rdfs:comment "The class of all units or places where people live.".
swp:Apartment rdf:type rdfs:Class.
swp:Apartment rdfs:subClassOf swp:ResidentialUnit.
swp:Apartment rdfs:comments "The class of apartments".
swp:House rdf:type rdfs:Class.
swp:House rdfs:subClassOf swp:ResidentialUnit.
swp:House rdfs:comment "The class of houses".
swp:residesAt rdf:type rdfs:Property.
swp:residesAt rdfs:comment "Relates persons to their residence".
swp:residesAt rdfs:domain swp:Person.
swp:residesAt rdfs:range swp:ResidentialUnit.
swp:rents rdf:type rdfs:Property.
swp:rents rdfs:comment "It inherits its domain (swp:Person) and range (swp:ResidentialUnit) from its
superproperty (swp:residesAt)".
swp:rents rdfs:subPropertyOf swp:residesAt.
swp:address rdf:type rdfs:Property.
swp:address rdfs:comment "Is a property of units and takes literals as its value".
swp:address rdfs:domain swp:Unit.
swp:address rdfs:range rdf:Literal.
8. Example: Motor Vehicles
Here we present a simple ontology of motor vehicles

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<#miniVan> a rdfs:Class ;rdfs:subClassOf <#passengerVehicle>, <#van>
<#motorVehicle> a rdfs:Class .
<#passengerVehicle> a rdfs:Class ;
rdfs:subClassOf <#motorVehicle> .
<#truck> a rdfs:Class ;
rdfs:subClassOf <#motorVehicle> .
<#van> a rdfs:Class ;
rdfs:subClassOf <#motorVehicle> .
RDF and RDF Schema in RDF Schema
1.RDF
2. RDF Schema
• Now that we know the main components of the RDF and RDFS
languages, it may be instructive to look at the definitions of RDF and
RDFS.
• These definitions are expressed in the language of RDF Schema.
• One task is to see how easily they can be read now that the meaning of
each component has been clarified.
• The following definitions are just part of the full language
specification.
• The remaining parts are found in the namespaces specified in rdf:RDF.
• We provide them in their original XML syntax.
1. RDF
<?xml version="1.0" encoding="UTF-16"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#¨>
<rdfs:Class rdf:ID="Statement"
rdfs:comment="The class of triples consisting of a predicate, a subject and an object (that is, a reified statement)"/>
<rdfs:Class rdf:ID="Property"
rdfs:comment="The class of properties"/>
<rdfs:Class rdf:ID="Bag"
rdfs:comment="The class of unordered collections"/>
<rdfs:Class rdf:ID="Seq"
rdfs:comment="The class of ordered collections"/>
<rdfs:Class rdf:ID="Alt"
rdfs:comment="The class of collections of alternatives"/>
<rdf:Property rdf:ID="predicate"
rdfs:comment="Identifies the property used in a statement when representing the statement in reified
form¨>
<rdfs:domain rdf:resource="#Statement"/>
<rdfs:range rdf:resource="#Property"/>
</rdf:Property>
<rdf:Property rdf:ID="subject"
rdfs:comment="Identifies the resource that a statement is describing when representing the statement in
reified form¨>
<rdfs:domain rdf:resource="#Statement"/>
</rdf:Property>
<rdf:Property rdf:ID="object“ rdfs:comment="Identifies the object of a statement when representing the
statement in reified form"/>
<rdf:Property rdf:ID="type"
rdfs:comment="Identifies the class of a resource. The resource is an instance of that class."/>
</rdf:RDF>
 2. RDF Schema
<rdf:RDF
xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#¨>
<rdfs:Class rdf:ID="Resource“ rdfs:comment="The most general class"/>
<rdfs:Class rdf:ID="comment“ rdfs:comment="Use this for descriptions¨>
<rdfs:domain rdf:resource="#Resource"/>
<rdfs:range rdf:resource="#Literal"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Class“ rdfs:comment="The concept of classes. All classes are resources.¨>
<rdfs:subClassOf rdf:resource="#Resource"/>
</rdfs:Class>
<rdf:Property rdf:ID="subClassOf¨>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="#Class"/>
</rdf:Property>
<rdf:Property rdf:ID="subPropertyOf¨>
<rdfs:domain rdf:resource="&rdf;Property"/>
<rdfs:range rdf:resource="&rdf;Property"/>
</rdf:Property>
</rdf:RDF>
• The namespaces do not provide the full definition of RDF and RDF
Schema.
• Consider, for example, rdfs:subClassOf.
• The namespace specifies only that it applies to classes and has a class as a
value.
• The meaning of being a subclass, namely, that all instances of one class
are also instances of its superclass, is not expressed anywhere.
• In fact, it cannot be expressed in an RDF document.
• If it could, there would be no need for defining RDF Schema.
• We provide a formal semantics in the next section.
• Of course, RDF parsers and other software tools for RDF (including query
processors) must be aware of the full semantics.
An Axiomatic Semantics for RDF and RDF Schema
1. The Approach
2. Basic Predicates
3. RDF
4. RDF Schema
An Axiomatic Semantics for RDF and RDF Schema
• In this section we formalize the meaning of the modeling primitives of RDF and RDF
Schema.
• Thus we capture the semantics of RDF and RDFS.
• The formal language we use is predicate logic, universally accepted as the foundation
of all (symbolic) knowledge representation.
• Formulas used in this formalization are referred to as axioms.
• By describing the semantics of RDF and RDFS in a formal language like logic we
make the semantics unambiguous and machine-accessible.
• Also, we provide a basis for reasoning support by automated reasoners manipulating
logical formulas.
1. The Approach
• All language primitives in RDF and RDF Schema are represented by constants:
• Resource,
• Class,
• Property,
• subClassOf, and so on.
• A few predefined predicates are used as a foundation for expressing relationships between the
constants.
• An auxiliary theory of lists is used.
• It has function symbols
• nil (empty list), cons(x, l) (adds an element to the front of the list),
• first(l) (returns the first element),
• rest(l) (returns the rest of the list),
predicate symbols
• item(x, l) (true iff an element occurs in the list),
• list(l) (true iff l is a list).
•Lists are used to represent containers in RDF.
•They are also needed to capture the meaning of certain
constructs (such as cardinality constraints) in richer ontology
languages.
•Most axioms provide typing information.
•For example, Type(subClassOf, Property) says that subClassOf
is a property.
•We use predicate logic with equality.
•Variable names begin with ?.
•All axioms are implicitly universally quantified.
2.Basic Predicates
• The basic predicates are
• PropVal(P,R,V), a predicate with three arguments, which is used to
represent an RDF
• statement with resource R,
• property P, and
• value V Type(R, T),
• short for PropVal(type,R, T), which specifies that the resource R has the type T
Type(?r, ?t) ←→ PropVal(type, ?r, ?t)
3. RDF
• An RDF statement (triple) (R, P, V ) is represented as PropVal(P,R, V ).
• Classes
In our language we have constants Class,Resource, Property, and Literal.
All classes are instances of Class; that is, they have the type Class:
Type(Class,Class)
Type(Resource,Class)
Type(Property,Class)
Type(Literal,Class)
Resource is the most general class: every object is a resource. Therefore, every class
and every property is a resource:
Type(?p, Property) −→ Type(?p,Resource)
Type(?c,Class) −→ Type(?c,Resource)
Finally, the predicate in an RDF statement must be a property:
PropVal(?p, ?r, ?v) −→ Type(?p, Property)

The type Property

type is a property:
Type(type, Property)
Note that it is equivalent to PropV al(type, type, Property): the type of type is
Property. type can be applied to resources and has a class as its value:
Type(?r, ?c) −→ (Type(?r,Resource) ∧ Type(?c,Class))
The Auxiliary FuncProp Property
• A functional property is a property that is a function: it relates a resource
to at most one value.
• Functional properties are not a concept of RDF but are used in the
axiomatization of other primitives.
• The constant FuncProp represents the class of all functional properties.
• P is a functional property if, and only if, it is a property, and there are no
x, y1, and y2 such that
P(x, y1), P(x, y2), and y1 = y2.
Type(?p, FuncProp) ←→ (Type(?p, Property) ∧ ∀?r∀?v1∀?v2
(PropVal(?p, ?r, ?v1) ∧ PropVal(?p, ?r, ?v2) −→?v1 =?v2))
Reified Statements
• The constant Statement represents the class of all reified statements.
• All reified statements are resources, and Statement is an instance of Class:
Type(?s, Statement) −→ Type(?s,Resource)
Type(Statement,Class)
• A reified statement can be decomposed into the three parts of an RDF triple:
Type(?st, Statement) −→
∃?p∃?r∃?v(PropVal(Predicate, ?st, ?p)∧
PropVal(Subject, ?st, ?r) ∧ PropVal(Object, ?st, ?v))
• Subject, Predicate, and Object are functional properties.
• That is, every statement has exactly one subject, one predicate, and one object:
Type(Subject, FuncProp)
Type(Predicate, FuncProp)
Type(Object, FuncProp)
• Their typing information is
PropVal(Subject, ?st, ?r) −→
(Type(?st, Statement) ∧ Type(?r,Resource))
PropVal(Predicate, ?st, ?p) −→
(Type(?st, Statement) ∧ Type(?p, Property))
PropVal(Object, ?st, ?v) −→
(Type(?st, Statement) ∧ (Type(?v,Resource) ∨ Type(?v,Literal)))
• The last axiom says, if Object appears as the property in an RDF
statement, then it must apply to a reified statement and have as its value
either a resource or a literal.
•Containers
• All containers are resources:
Type(?c,Container) −→ Type(?c,Resource)
Containers are lists:
Type(?c,Container) −→ list(?c)
• Containers are bags or sequences or alternatives:
• Type(?c,Container) ←→
• (Type(?c,Bag) ∨ Type(?c, Seq) ∨ Type(?c, Alt))
• Bags and sequences are disjoint:
￢(Type(?x,Bag) ∧ Type(?x, Seq))
• For every natural numbern > 0, there is the selector _n, which selects the nth element of a container. It is a
functional property
Type(_n, FuncProp)
• and applies to containers only:
PropV al(_n, ?c, ?o) −→ Type(?c,Container)
4. RDF Schema
Subclasses and Subproperties subClassOf is a property:
Type(subClassOf, Property)
If a class C is a subclass of a class C, then all instances of C are also instances of C:
PropVal(subClassOf, ?c, ?c) ←−
(Type(?c,Class) ∧ Type(?c, Class)∧ ∀ ?x(Type(?x, ?c) −→ Type(?x, ?c)))
Similarly for subPropertyOf: P is a subproperty of P if P(x, y) whenever P(x, y):
Type(subPropertyOf, Property)
PropVal(subP ropertyOf, ?p, ?p) ←→
(Type(?p, Property) ∧ Type(?p, Property)∧
∀?r∀?v(PropV al(?p, ?r, ?v) −→ PropVal(?p, ?r, ?v)))
Constraints
Every constraint resource is a resource:
PropVal(subClassOf,ConstraintResource,Resource)
• Constraint properties are all properties that are also constraint resources:
Type(?cp,ConstraintProperty) ←→
(Type(?cp,ConstraintResource) ∧ Type(?cp, Property))
• domain and range are constraint properties:
Type(domain,ConstraintProperty)
Type(range,ConstraintProperty)
• domain and range define, respectively, the domain and range of a
property.
• Recall that the domain of a property P is the set of all objects to which P
applies.
• If the domain of P is D, then for every P(x, y), x ∈ D.
PropVal(domain, ?p, ?d) −→
∀?x∀?y(PropV al(?p, ?x, ?y) −→ Type(?x, ?d))
• The range of a property P is the set of all values P can take.
• If the range of P is R, then for every P(x, y), y ∈ R.
PropVal(range, ?p, ?r) −→
∀?x∀?y(PropVal(?p, ?x, ?y) −→ Type(?y, ?r))
• Formulas that can be inferred from the preceding ones:
PropVal(domain, range, Property)
PropVal(range, range,Class)
PropVal(domain, domain, Property)
PropVal(range, domain,Class)
• Thus we have formalized the semantics of RDF and RDFS.
• Software equipped with this knowledge is able to draw interesting
conclusions.
•For example
•given that the range of rents is ResidentialUnit,
•that ResidentialUnit is a subclass of Unit,
•and that rents(JeffMeyer, BaronWayApartment),
•the agent can automatically deduce
Unit(BaronWayApartment) using the predicate logic
semantics or one of the predicate logic proof systems.
A Direct Inference System for RDF and RDFS
• As stated, the axiomatic semantics can be used for automated reasoning with RDF
and RDF Schema.
• However, it requires a first-order logic proof system to do so.
• This is a very heavy requirement and also one that is unlikely to scale when millions
(or billions) of statements are involved (e.g., millions of statements of the form
Type(?r, ?c)).
• For this reason, RDF has also been given a semantics (and an inference system that is
sound and complete for this semantics) directly in terms of RDF triples instead of
restating RDF in terms of first-order logic.
• This inference system consists of rules of the form
IF E contains certain triples
THEN add to E certain additional triples
• (where E is an arbitrary set of RDF triples).
• Without repeating the entire set of inference rules (which can be found in the official
RDF documents), we give here a few basic examples:
IF E contains the triple (?x, ?p, ?y)
THEN E also contains the triple (?p, rdf : type, rdf : property)
• This states that any resource ?p that is used in the property position of a triple can be
inferred to be a member of the class rdf:Property.
• A somewhat more interesting example is the following rule:
IF E contains the triples (?u, rdfs : subClassOf, ?v)
and (?v, rdfs : subclassOf, ?w)
THEN E also contains the triple (?u, rdfs : subClassOf, ?w)
• which encodes the transitivity of the subclass relation.
• Closely related is the rule
IF E contains the triples (?x, rdf : type, ?u)
and (?u, rdfs : subClassOf, ?v)
THEN E also contains the triple (?x, rdf : type, ?v)
• which is the essential definition of the meaning of rdfs:subClassOf.

• A final example often comes as a surprise to people first looking at RDF Schema:
IF E contains the triples (?x, ?p, ?y)
and (?p, rdfs : range, ?u)
THEN E also contains the triple (?y, rdf : type, ?u)