Hubbry Logo
Resource Description FrameworkResource Description FrameworkMain
Open search
Resource Description Framework
Community hub
Resource Description Framework
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Resource Description Framework
Resource Description Framework
Resource Description Framework
View on Wikipedia
from Wikipedia

The Resource Description Framework (RDF) is a method to describe and exchange graph data. It was originally designed as a data model for metadata by the World Wide Web Consortium (W3C). It provides a variety of syntax notations and formats, of which the most widely used is Turtle (Terse RDF Triple Language).

RDF is a directed graph composed of triple statements. An RDF graph statement is represented by: (1) a node for the subject, (2) an arc from subject to object, representing a predicate, and (3) a node for the object. Each of these parts can be identified by a Uniform Resource Identifier (URI). An object can also be a literal value. This simple, flexible data model has a lot of expressive power to represent complex situations, relationships, and other things of interest, while also being appropriately abstract.

RDF was adopted as a W3C recommendation in 1999. The RDF 1.0 specification was published in 2004, and the RDF 1.1 specification in 2014. SPARQL is a standard query language for RDF graphs. RDF Schema (RDFS), Web Ontology Language (OWL) and SHACL (Shapes Constraint Language) are ontology languages that are used to describe RDF data.

Overview

[edit]

The RDF data model[1] is similar to classical conceptual modeling approaches (such as entity–relationship or class diagrams). It is based on the idea of making statements about resources (in particular web resources) in expressions of the form subject–predicate–object, known as triples. The subject denotes the resource; the predicate denotes traits or aspects of the resource, and expresses a relationship between the subject and the object.

For example, one way to represent the notion "The sky has the color blue" in RDF is as the triple: a subject denoting "the sky", a predicate denoting "has the color", and an object denoting "blue". Therefore, RDF uses subject instead of object (or entity) in contrast to the typical approach of an entity–attribute–value model in object-oriented design: entity (sky), attribute (color), and value (blue).

RDF is an abstract model with several serialization formats (being essentially specialized file formats). In addition the particular encoding for resources or triples can vary from format to format.

This mechanism for describing resources is a major component in the W3C's Semantic Web activity: an evolutionary stage of the World Wide Web in which automated software can store, exchange, and use machine-readable information distributed throughout the Web, in turn enabling users to deal with the information with greater efficiency and certainty. RDF's simple data model and ability to model disparate, abstract concepts has also led to its increasing use in knowledge management applications unrelated to Semantic Web activity.

A collection of RDF statements intrinsically represents a labeled, directed multigraph. This makes an RDF data model better suited to certain kinds of knowledge representation than other relational or ontological models.

As RDFS, OWL and SHACL demonstrate, one can build additional ontology languages upon RDF.

History

[edit]

The initial RDF design, intended to "build a vendor-neutral and operating system- independent system of metadata",[2] derived from the W3C's Platform for Internet Content Selection (PICS), an early web content labelling system,[3] but the project was also shaped by ideas from Dublin Core, and from the Meta Content Framework (MCF),[2] which had been developed during 1995 to 1997 by Ramanathan V. Guha at Apple and Tim Bray at Netscape.[4]

A first public draft of RDF appeared in October 1997,[5][6] issued by a W3C working group that included representatives from IBM, Microsoft, Netscape, Nokia, Reuters, SoftQuad, and the University of Michigan.[3]

In 1999, the W3C published the first recommended RDF specification, the Model and Syntax Specification ("RDF M&S").[7] This described RDF's data model and an XML serialization.[8]

Two persistent misunderstandings about RDF developed at this time: firstly, due to the MCF influence and the RDF "Resource Description" initialism, the idea that RDF was specifically for use in representing metadata; secondly that RDF was an XML format rather than a data model, and only the RDF/XML serialisation being XML-based. RDF saw little take-up in this period, but there was significant work done in Bristol, around ILRT at Bristol University and HP Labs, and in Boston at MIT. RSS 1.0 and FOAF became exemplar applications for RDF in this period.

The recommendation of 1999 was replaced in 2004 by a set of six specifications:[9] "The RDF Primer",[10] "RDF Concepts and Abstract",[11] "RDF/XML Syntax Specification (revised)",[12] "RDF Semantics",[13] "RDF Vocabulary Description Language 1.0",[14] and "The RDF Test Cases".[15]

This series was superseded in 2014 by the following six "RDF 1.1" documents: "RDF 1.1 Primer",[16] "RDF 1.1 Concepts and Abstract Syntax",[17] "RDF 1.1 XML Syntax",[18] "RDF 1.1 Semantics",[19] "RDF Schema 1.1",[20] and "RDF 1.1 Test Cases".[21]

RDF topics

[edit]

Vocabulary

[edit]

The vocabulary defined by the RDF specification is as follows:[22]

Classes

[edit]
rdf
[edit]
rdf:XMLLiteral
the class of XML literal values
rdf:Property
the class of properties
rdf:Statement
the class of RDF statements
rdf:Alt, rdf:Bag, rdf:Seq
containers of alternatives, unordered containers, and ordered containers (rdfs:Container is a super-class of the three)
rdf:List
the class of RDF Lists
rdf:nil
an instance of rdf:List representing the empty list
rdfs
[edit]
rdfs:Resource
the class resource, everything
rdfs:Literal
the class of literal values, e.g. strings and integers
rdfs:Class
the class of classes
rdfs:Datatype
the class of RDF datatypes
rdfs:Container
the class of RDF containers
rdfs:ContainerMembershipProperty
the class of container membership properties, rdf:_1, rdf:_2, ..., all of which are sub-properties of rdfs:member

Properties

[edit]
rdf
[edit]
rdf:type
an instance of rdf:Property used to state that a resource is an instance of a class
rdf:first
the first item in the subject RDF list
rdf:rest
the rest of the subject RDF list after rdf:first
rdf:value
idiomatic property used for structured values
rdf:subject
the subject of the RDF statement
rdf:predicate
the predicate of the RDF statement
rdf:object
the object of the RDF statement

rdf:Statement, rdf:subject, rdf:predicate, rdf:object are used for reification (see below).

rdfs
[edit]
rdfs:subClassOf
the subject is a subclass of a class
rdfs:subPropertyOf
the subject is a subproperty of a property
rdfs:domain
a domain of the subject property
rdfs:range
a range of the subject property
rdfs:label
a human-readable name for the subject
rdfs:comment
a description of the subject resource
rdfs:member
a member of the subject resource
rdfs:seeAlso
further information about the subject resource
rdfs:isDefinedBy
the definition of the subject resource

This vocabulary is used as a foundation for RDF Schema, where it is extended.

Serialization formats

[edit]
RDF 1.1 Turtle serialization
Filename extension
.ttl
Internet media type
text/turtle[23]
Developed byWorld Wide Web Consortium
StandardRDF 1.1 Turtle: Terse RDF Triple Language January 9, 2014; 11 years ago (2014-01-09)
Open format?Yes
RDF 1.1 TriG serialization
Filename extension
.trig
Internet media type
application/trig[24]
Developed byWorld Wide Web Consortium
StandardRDF 1.1 TriG: RDF Dataset Language February 25, 2014; 11 years ago (2014-02-25)
Open format?Yes
RDF/XML serialization
Filename extension
.rdf
Internet media type
application/rdf+xml[25]
Developed byWorld Wide Web Consortium
StandardConcepts and Abstract Syntax February 10, 2004; 21 years ago (2004-02-10)
Open format?Yes

Several common serialization formats are in use, including:

  • Turtle,[26] a compact, human-friendly format.
  • TriG,[27] an extension of Turtle to datasets.
  • N-Triples,[28] a very simple, easy-to-parse, line-based format that is not as compact as Turtle.
  • N-Quads,[29][30] a superset of N-Triples, for serializing multiple RDF graphs.
  • JSON-LD,[31] a JSON-based serialization.
  • N3 or Notation3, a non-standard serialization that is very similar to Turtle, but has some additional features, such as the ability to define inference rules.
  • RDF/XML,[32] an XML-based syntax that was the first standard format for serializing RDF.
  • RDF/JSON,[33] an alternative syntax for expressing RDF triples using a simple JSON notation.

RDF/XML is sometimes misleadingly called simply RDF because it was introduced among the other W3C specifications defining RDF and it was historically the first W3C standard RDF serialization format. However, it is important to distinguish the RDF/XML format from the abstract RDF model itself. Although the RDF/XML format is still in use, other RDF serializations are now preferred by many RDF users, both because they are more human-friendly,[34] and because some RDF graphs are not representable in RDF/XML due to restrictions on the syntax of XML QNames.

With a little effort, virtually any arbitrary XML may also be interpreted as RDF using GRDDL (pronounced 'griddle'), Gleaning Resource Descriptions from Dialects of Languages.

RDF triples may be stored in a type of database called a triplestore.

Resource identification

[edit]

The subject of an RDF statement is either a uniform resource identifier (URI) or a blank node, both of which denote resources. Resources indicated by blank nodes are called anonymous resources. They are not directly identifiable from the RDF statement. The predicate is a URI which also indicates a resource, representing a relationship. The object is a URI, blank node or a Unicode string literal. As of RDF 1.1 resources are identified by Internationalized Resource Identifiers (IRIs); IRI are a generalization of URI.[35]

In Semantic Web applications, and in relatively popular applications of RDF like RSS and FOAF (Friend of a Friend), resources tend to be represented by URIs that intentionally denote, and can be used to access, actual data on the World Wide Web. But RDF, in general, is not limited to the description of Internet-based resources. In fact, the URI that names a resource does not have to be dereferenceable at all. For example, a URI that begins with "http:" and is used as the subject of an RDF statement does not necessarily have to represent a resource that is accessible via HTTP, nor does it need to represent a tangible, network-accessible resource—such a URI could represent absolutely anything. However, there is broad agreement that a bare URI (without a # symbol) which returns a 300-level coded response when used in an HTTP GET request should be treated as denoting the internet resource that it succeeds in accessing.

Therefore, producers and consumers of RDF statements must agree on the semantics of resource identifiers. Such agreement is not inherent to RDF itself, although there are some controlled vocabularies in common use, such as Dublin Core Metadata, which is partially mapped to a URI space for use in RDF. The intent of publishing RDF-based ontologies on the Web is often to establish, or circumscribe, the intended meanings of the resource identifiers used to express data in RDF. For example, the URI: 

http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Merlot

is intended by its owners to refer to the class of all Merlot red wines by vintner (i.e., instances of the above URI each represent the class of all wine produced by a single vintner), a definition which is expressed by the OWL ontology—itself an RDF document—in which it occurs. Without careful analysis of the definition, one might erroneously conclude that an instance of the above URI was something physical, instead of a type of wine.

Note that this is not a 'bare' resource identifier, but is rather a URI reference, containing the '#' character and ending with a fragment identifier.

Statement reification and context

[edit]
Basic RDF triple comprising (subject, predicate, object).

The body of knowledge modeled by a collection of statements may be subjected to reification, in which each statement (that is each triple subject-predicate-object altogether) is assigned a URI and treated as a resource about which additional statements can be made, as in "Jane says that John is the author of document X". Reification is sometimes important in order to deduce a level of confidence or degree of usefulness for each statement.

In a reified RDF database, each original statement, being a resource, itself, most likely has at least three additional statements made about it: one to assert that its subject is some resource, one to assert that its predicate is some resource, and one to assert that its object is some resource or literal. More statements about the original statement may also exist, depending on the application's needs.

Borrowing from concepts available in logic (and as illustrated in graphical notations such as conceptual graphs and topic maps), some RDF model implementations acknowledge that it is sometimes useful to group statements according to different criteria, called situations, contexts, or scopes, as discussed in articles by RDF specification co-editor Graham Klyne.[36][37] For example, a statement can be associated with a context, named by a URI, in order to assert an "is true in" relationship. As another example, it is sometimes convenient to group statements by their source, which can be identified by a URI, such as the URI of a particular RDF/XML document. Then, when updates are made to the source, corresponding statements can be changed in the model, as well.

Implementation of scopes does not necessarily require fully reified statements. Some implementations allow a single scope identifier to be associated with a statement that has not been assigned a URI, itself.[38][39] Likewise named graphs in which a set of triples is named by a URI can represent context without the need to reify the triples.[40]

Query and inference languages

[edit]
Main article: RDF query language

The predominant query language for RDF graphs is SPARQL. SPARQL is an SQL-like language, and a recommendation of the W3C as of January 15, 2008.

The following is an example of a SPARQL query to show country capitals in Africa, using a fictional ontology: 

PREFIX ex: <http://example.com/exampleOntology#>
SELECT ?capital ?country
WHERE {
  ?x ex:cityname ?capital ;
     ex:isCapitalOf ?y .
  ?y ex:countryname ?country ;
     ex:isInContinent ex:Africa .
}

Other non-standard ways to query RDF graphs include:

  • RDQL, precursor to SPARQL, SQL-like
  • Versa, compact syntax (non–SQL-like), solely implemented in 4Suite (Python).
  • RQL, one of the first declarative languages for uniformly querying RDF schemas and resource descriptions, implemented in RDFSuite.[41]
  • SeRQL, part of Sesame
  • XUL has a template element in which to declare rules for matching data in RDF. XUL uses RDF extensively for data binding.

SHACL Advanced Features specification[42] (W3C Working Group Note), the most recent version of which is maintained by the SHACL Community Group,[43] defines support for SHACL Rules, used for data transformations, inferences and mappings of RDF based on SHACL shapes.

Validation and description

[edit]
Main article: RDF query language

The predominant language for describing and validating RDF graphs is SHACL (Shapes Constraint Language).[44] SHACL specification is divided in two parts: SHACL Core and SHACL-SPARQL. SHACL Core consists of a list of built-in constraints such as cardinality, range of values and many others. SHACL-SPARQL describes SPARQL-based constraints and an extension mechanism to declare new constraint components.

Other non-standard ways to describe and validate RDF graphs include:

Examples

[edit]

Example 1: Description of a person named Eric Miller

[edit]

The following example is taken from the W3C website[48] describing a resource with statements "there is a Person identified by http://www.w3.org/People/EM/contact#me, whose name is Eric Miller, whose email address is e.miller123(at)example (changed for security purposes), and whose title is Dr."

An RDF graph describing Eric Miller[48]

The resource "http://www.w3.org/People/EM/contact#me" is the subject.

The objects are:

  • "Eric Miller" (with a predicate "whose name is"),
  • mailto:e.miller123(at)example (with a predicate "whose email address is"), and
  • "Dr." (with a predicate "whose title is").

The subject is a URI.

The predicates also have URIs. For example, the URI for each predicate:

  • "whose name is" is http://www.w3.org/2000/10/swap/pim/contact#fullName,
  • "whose email address is" is http://www.w3.org/2000/10/swap/pim/contact#mailbox,
  • "whose title is" is http://www.w3.org/2000/10/swap/pim/contact#personalTitle.

In addition, the subject has a type (with URI http://www.w3.org/1999/02/22-rdf-syntax-ns#type), which is person (with URI http://www.w3.org/2000/10/swap/pim/contact#Person).

Therefore, the following "subject, predicate, object" RDF triples can be expressed:

  • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#fullName, "Eric Miller"
  • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#mailbox, mailto:e.miller123(at)example
  • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#personalTitle, "Dr."
  • http://www.w3.org/People/EM/contact#me, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, http://www.w3.org/2000/10/swap/pim/contact#Person

In standard N-Triples format, this RDF can be written as: 

<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#fullName> "Eric Miller" .
<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#mailbox> <mailto:e.miller123(at)example> .
<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#personalTitle> "Dr." .
<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/10/swap/pim/contact#Person> .

Equivalently, it can be written in standard Turtle (syntax) format as: 

@prefix eric:    <http://www.w3.org/People/EM/contact#> .
@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

eric:me contact:fullName "Eric Miller" .
eric:me contact:mailbox <mailto:e.miller123(at)example> .
eric:me contact:personalTitle "Dr." .
eric:me rdf:type contact:Person .

Or more concisely, using a common shorthand syntax of Turtle as: 

@prefix eric:    <http://www.w3.org/People/EM/contact#> .
@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

eric:me contact:fullName "Eric Miller" ;
  contact:mailbox <mailto:e.miller123(at)example> ;
  contact:personalTitle "Dr." ;
  rdf:type contact:Person .

Or, it can be written in RDF/XML format as: 

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:eric="http://www.w3.org/People/EM/contact#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:fullName>Eric Miller</contact:fullName>
  </rdf:Description>
  <rdf:Description rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:mailbox rdf:resource="mailto:e.miller123(at)example"/>
  </rdf:Description>
  <rdf:Description rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:personalTitle>Dr.</contact:personalTitle>
  </rdf:Description>
  <rdf:Description rdf:about="http://www.w3.org/People/EM/contact#me">
    <rdf:type rdf:resource="http://www.w3.org/2000/10/swap/pim/contact#Person"/>
  </rdf:Description>
</rdf:RDF>

Example 2: The postal abbreviation for New York

[edit]

Certain concepts in RDF are taken from logic and linguistics, where subject-predicate and subject-predicate-object structures have meanings similar to, yet distinct from, the uses of those terms in RDF. This example demonstrates:

In the English language statement 'New York has the postal abbreviation NY' , 'New York' would be the subject, 'has the postal abbreviation' the predicate and 'NY' the object.

Encoded as an RDF triple, the subject and predicate would have to be resources named by URIs. The object could be a resource or literal element. For example, in the N-Triples form of RDF, the statement might look like: 

<urn:x-states:New%20York> <http://purl.org/dc/terms/alternative> "NY" .

In this example, "urn:x-states:New%20York" is the URI for a resource that denotes the US state New York, "http://purl.org/dc/terms/alternative" is the URI for a predicate (whose human-readable definition can be found here[49]), and "NY" is a literal string. Note that the URIs chosen here are not standard, and do not need to be, as long as their meaning is known to whatever is reading them.

Example 3: A Wikipedia article about Tony Benn

[edit]

In a like manner, given that "https://en.wikipedia.org/wiki/Tony_Benn" identifies a particular resource (regardless of whether that URI could be traversed as a hyperlink, or whether the resource is actually the Wikipedia article about Tony Benn), to say that the title of this resource is "Tony Benn" and its publisher is "Wikipedia" would be two assertions that could be expressed as valid RDF statements. In the N-Triples form of RDF, these statements might look like the following: 

<https://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/title> "Tony Benn" .
<https://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/publisher> "Wikipedia" .

To an English-speaking person, the same information could be represented simply as:

The title of this resource, which is published by Wikipedia, is 'Tony Benn'

However, RDF puts the information in a formal way that a machine can understand. The purpose of RDF is to provide an encoding and interpretation mechanism so that resources can be described in a way that particular software can understand it; in other words, so that software can access and use information that it otherwise could not use.

Both versions of the statements above are wordy because one requirement for an RDF resource (as a subject or a predicate) is that it be unique. The subject resource must be unique in an attempt to pinpoint the exact resource being described. The predicate needs to be unique in order to reduce the chance that the idea of Title or Publisher will be ambiguous to software working with the description. If the software recognizes http://purl.org/dc/elements/1.1/title (a specific definition for the concept of a title established by the Dublin Core Metadata Initiative), it will also know that this title is different from a land title or an honorary title or just the letters t-i-t-l-e put together.

The following example, written in Turtle, shows how such simple claims can be elaborated on, by combining multiple RDF vocabularies. Here, we note that the primary topic of the Wikipedia page is a "Person" whose name is "Tony Benn": 

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc:   <http://purl.org/dc/elements/1.1/> .

<https://en.wikipedia.org/wiki/Tony_Benn>
    dc:publisher "Wikipedia" ;
    dc:title "Tony Benn" ;
    foaf:primaryTopic [
        a foaf:Person ;
        foaf:name "Tony Benn"
    ] .

Applications

[edit]
  • DBpedia – Extracts facts from Wikipedia articles and publishes them as RDF data.
  • YAGO – Similar to DBpedia extracts facts from Wikipedia articles and publishes them as RDF data.
  • Wikidata – Collaboratively edited knowledge base hosted by the Wikimedia Foundation.
  • Creative Commons – Uses RDF to embed license information in web pages and mp3 files.
  • FOAF (Friend of a Friend) – designed to describe people, their interests and interconnections.
  • Haystack client – Semantic web browser from MIT CS & AI lab.[50]
  • IDEAS Group – developing a formal 4D ontology for Enterprise Architecture using RDF as the encoding.[51]
  • Microsoft shipped a product, Connected Services Framework,[52] which provides RDF-based Profile Management capabilities.
  • MusicBrainz – Publishes information about Music Albums.[53]
  • NEPOMUK, an open-source software specification for a Social Semantic desktop uses RDF as a storage format for collected metadata. NEPOMUK is mostly known because of its integration into the KDE SC 4 desktop environment.
  • Cochrane is a global publisher of clinical study meta-analyses in evidence based healthcare. They use an ontology driven data architecture to semantically annotate their published reviews with RDF based structured data.[54]
  • RDF Site Summary – one of several "RSS" languages for publishing information about updates made to a web page; it is often used for disseminating news article summaries and sharing weblog content.
  • Simple Knowledge Organization System (SKOS) – a KR representation intended to support vocabulary/thesaurus applications
  • SIOC (Semantically-Interlinked Online Communities) – designed to describe online communities and to create connections between Internet-based discussions from message boards, weblogs and mailing lists.[55]
  • Smart-M3 – provides an infrastructure for using RDF and specifically uses the ontology agnostic nature of RDF to enable heterogeneous mashing-up of information[56]
  • LV2 - a libre plugin format using Turtle to describe API/ABI capabilities and properties[57]
  • Software Package Data Exchange – A standard for specifying bills of material.

Some uses of RDF include research into social networking. It will also help people in business fields understand better their relationships with members of industries that could be of use for product placement.[58] It will also help scientists understand how people are connected to one another.

RDF is being used to gain a better understanding of road traffic patterns. This is because the information regarding traffic patterns is on different websites, and RDF is used to integrate information from different sources on the web. Before, the common methodology was using keyword searching, but this method is problematic because it does not consider synonyms. This is why ontologies are useful in this situation. But one of the issues that comes up when trying to efficiently study traffic is that to fully understand traffic, concepts related to people, streets, and roads must be well understood. Since these are human concepts, they require the addition of fuzzy logic. This is because values that are useful when describing roads, like slipperiness, are not precise concepts and cannot be measured. This would imply that the best solution would incorporate both fuzzy logic and ontology.[59]

See also

[edit]

Notations for RDF

[edit]

Similar concepts

[edit]

Other

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Resource Description Framework

View on Grokipedia
from Grokipedia
The Resource Description Framework (RDF) is a W3C standard for representing and exchanging structured and on the Web as a directed, labeled graph composed of subject-predicate-object expressions known as . It enables the description of resources using unique identifiers like Internationalized Resource Identifiers (IRIs), literals, and blank nodes, allowing data from diverse sources to be merged seamlessly even if underlying schemas differ or evolve over time. RDF forms the foundational data model for the , a vision of the Web where information is given well-defined meaning to enable computers to process it more intelligently and facilitate across applications. At its core, an RDF graph is a set of triples where the subject identifies a , the predicate denotes a relationship or property, and the object provides the value or target of that relationship, creating a flexible framework for encoding metadata and knowledge representations. RDF datasets extend this by organizing multiple graphs, including a default graph and named graphs, which support advanced querying and provenance tracking via standards like . Originally proposed in 1997 and formalized in its first specification in 1999, RDF has evolved through multiple versions, with RDF 1.1 published as a W3C Recommendation in 2014 to refine serialization formats, semantics, and entailment rules. The ongoing RDF 1.2 updates, under development by a new W3C RDF Working Group, introduce enhancements such as triple terms (allowing triples as objects), directional language-tagged strings for better internationalization, and mechanisms for version announcements to ensure backward compatibility. These features make RDF particularly suited for knowledge graphs, linked data initiatives, and domains like bioinformatics, cultural heritage, and enterprise data integration, where precise, machine-readable descriptions are essential.

Introduction

Overview

The Resource Description Framework (RDF) is a W3C for data interchange on the Web, enabling the representation of information about resources through subject-predicate-object . This triple-based approach models relationships between entities in a way that supports the description of arbitrary resources, forming the foundational for representation. In RDF, data takes the form of a directed, labeled graph, where nodes represent resources (identified by Internationalized Resource Identifiers, or IRIs) or literals (such as strings or numbers), and directed edges denote properties that connect these nodes. The primary goal of RDF is to facilitate machine-readable data interchange within the , allowing structured and semi-structured information from disparate sources to be linked, merged, and queried seamlessly. RDF employs an abstract syntax defined by its graph model, which remains independent of any particular serialization format, thereby supporting multiple concrete syntaxes like or for expressing the same underlying data. Among its key benefits, RDF offers flexibility in modeling diverse domains, extensibility via namespaces that permit the definition and reuse of custom vocabularies, and inherent support for decentralized publishing of data across distributed Web environments.

Historical Development

The Resource Description Framework (RDF) originated as a W3C recommendation in 1999 with the publication of the RDF Model and Syntax Specification, which defined an initial XML-based syntax for representing metadata on the Web. This early version, often referred to as RDF 1.0, was heavily influenced by the emerging vision articulated by , who proposed a framework for machine-readable data to enable more intelligent Web applications, building on XML as a foundational technology. Key contributors to this specification included Ora Lassila and Ralph Swick, who served as editors, along with broader input from the community involved in early metadata initiatives. In , the RDF Working Group formalized RDF 1.0 through several key recommendations, including the RDF Concepts and Abstract Syntax, which provided a precise independent of syntax, and the RDF Primer, which offered introductory guidance for adoption. These documents addressed foundational ambiguities in the 1999 specification, such as the semantics of reification for making statements about statements, while establishing RDF's core abstract model of resources, properties, and statements. RDF 1.1, released in 2014, introduced significant updates to enhance usability and , including revised serialization formats like for human-readable syntax and improved handling of language-tagged literals. These changes resolved lingering issues from earlier versions, such as ambiguities in reification mechanisms and syntactic verbosity in , making RDF more accessible for global deployment. Post-2014 developments expanded RDF's interoperability, notably with the 2014 W3C recommendation of , a lightweight serialization that maps JSON structures to RDF graphs for easier integration with Web APIs. As of November 2025, the RDF & Working Group is advancing RDF 1.2 toward recommendation, with key Working Drafts such as the Concepts and Abstract published on 18 November 2025. These introduce enhancements including triple terms (for using as objects to support statements about statements), directional language-tagged strings for improved , and mechanisms for version announcements, addressing reification limitations while preserving backward compatibility.

Fundamental Components

Triples and RDF Graphs

The Resource Description Framework (RDF) employs an abstract syntax model centered on triples and graphs, which form the foundational structure for representing . An RDF triple consists of three components: a subject, a predicate, and an object, typically denoted in the form subject–predicate–object. The subject of an RDF triple identifies the being described and must be either an Internationalized Resource Identifier (IRI) or a blank node. The predicate, which specifies the relationship between the subject and object, must be an IRI. The object can be an IRI, a blank node, or a literal, allowing for descriptions of resources, relationships, or direct values. An RDF graph is defined as a set of RDF triples, with no inherent order among the triples or their components. This structure corresponds to a directed, labeled graph in which subjects and objects serve as nodes (IRIs, blank nodes, or literals), predicates act as labeled edges connecting them, and the absence of ordering ensures that the semantics depend solely on the presence of triples rather than their sequence. Blank nodes, often abbreviated as bNodes, provide a mechanism for denoting anonymous resources within an RDF graph without assigning a global identifier. These nodes are locally scoped to the specific graph or document in which they appear, meaning that blank node identifiers used in serialization are not part of the abstract syntax and must not be interpreted as implying identity across different graphs; this scoping rule prevents unintended identity conflicts when merging or comparing graphs. In notation, IRIs are commonly represented using angle brackets, such as <http://example.org/alice> for a identifying a named Alice, while literals are denoted with quotes, such as "Alice" for a plain string value. An RDF graph may be empty, containing no triples, which represents the absence of any statements. Two RDF graphs are considered equivalent if they are , meaning there exists a between their nodes (including blank nodes) that preserves the structure such that a triple in one graph maps precisely to a corresponding triple in the other. This isomorphism accounts for the of blank nodes by allowing them to be relabeled during comparison, ensuring that structural equivalence is determined independently of specific blank node identifiers. RDF graphs can be extended to datasets comprising multiple named graphs, where each graph is associated with an IRI for identification, though detailed mechanisms for this are addressed separately.

Resources, URIs, and Literals

In the Resource Description Framework (RDF), a resource is any entity that can be described, such as a physical object, a , an abstract concept, or even another description. Resources are universally identified using Internationalized Resource Identifiers (IRIs), which serve as global names for these entities within RDF graphs. IRIs are Unicode strings that conform to the syntax defined in RFC 3987, extending the earlier (URI) scheme to support international characters beyond ASCII. While URIs form a subset of IRIs limited to ASCII characters, RDF 1.1 prioritizes IRIs to enable broader language support in resource naming. For example, an IRI like http://example.org/person#alice identifies a specific resource, where the part after the hash (#alice) is a fragment identifier denoting a secondary resource, such as a particular element within a document or graph. Not all resources require global identifiers; RDF also employs blank nodes as locally scoped placeholders for entities whose existence is asserted without assigning a permanent name. Blank nodes are unique only within the context of a single RDF graph and cannot be referenced across different graphs, making them suitable for anonymous or temporary resources. For instance, a blank node might represent an unnamed relationship in a triple without needing an IRI. In contrast to resources, literals represent values such as strings, numbers, or dates that are not intended to be further described by RDF statements. A literal consists of a lexical form (the literal string itself), an optional datatype IRI that specifies its interpretation, and an optional language tag for strings. RDF relies on datatypes from (XSD) for precise value mapping, where the lexical form is mapped to a value in the datatype's value space; for example, the literal "42"^^xsd:integer denotes the value using the XSD datatype. Language-tagged literals, such as "Hello"@en, indicate plain strings with a specific , like English, without a datatype.

Conceptual Building Blocks

Vocabularies

An RDF vocabulary is a collection of Internationalized Resource Identifiers (IRIs) intended for use in RDF graphs to define classes and properties for describing resources. These vocabularies are typically published as RDF Schema (RDFS) documents or Web Ontology Language (OWL) ontologies, providing a structured way to extend the RDF model with domain-specific terms. For instance, the RDF Schema vocabulary itself uses the namespace IRI http://www.w3.org/2000/01/rdf-schema# to organize its terms. To facilitate readability and prevent IRI collisions, RDF vocabularies employ namespace IRIs and associated prefixes as syntactic conveniences, though these are not part of the core RDF data model. A namespace IRI serves as a common prefix for a set of related IRIs, such as http://www.w3.org/1999/02/22-rdf-syntax-ns# abbreviated as rdf:, http://www.w3.org/2000/01/rdf-schema# as rdfs:, and http://www.w3.org/2002/07/owl# as owl:. This abbreviation allows concise serialization of full IRIs, like rdf:type instead of the expanded form, promoting clarity in RDF documents across different syntaxes. The core RDF vocabulary includes fundamental terms such as rdf:type, which asserts that a resource is an instance of a class, and rdf:Property, which declares a resource as a property representing a between subjects and objects. These terms form the basis for more elaborate vocabularies, enabling the declaration of additional classes and properties. Best practices for designing RDF vocabularies emphasize reusing established terms to enhance compatibility, such as those from the Metadata Initiative for descriptive properties or the (FOAF) vocabulary for social networking concepts. Versioning is achieved by associating IRIs with specific releases, ensuring and clear evolution tracking through dereferenceable URIs. Vocabularies play a crucial role in by establishing shared semantics across diverse datasets, allowing systems to integrate and interpret RDF data from multiple sources without ambiguity.

Classes and Properties

In RDF, classes represent sets of resources that share common characteristics, where individual resources become instances or members of a class through the use of the rdf:type property. This membership indicates that the resource belongs to the class extension, which is the collection of all such instances. For example, a specific resource might be typed as an instance of a "Person" class, establishing its categorization within an RDF graph. Classes support hierarchical structures via the rdfs:subClassOf property, which defines specialization relationships between classes. If class C1 is a subclass of C2, then every instance of C1 is also an instance of C2, enabling inheritance of properties and constraints across the hierarchy; this relation is transitive, allowing multi-level subclass chains. This mechanism allows vocabularies to model taxonomic relationships, such as "" as a subclass of "." Properties in RDF function as binary relations connecting a subject resource to an object resource or literal, facilitating the description of attributes and associations. The rdfs:domain property specifies the expected class or classes for the subject of a given property, while rdfs:range defines the expected class or classes for the object, providing semantic constraints on usage. These declarations are advisory rather than strictly enforced, guiding applications in interpreting and validating RDF data, and multiple domain or range specifications imply intersection of the classes. Property hierarchies are established using rdfs:subPropertyOf, where a subproperty inherits the domain and range constraints of its superproperty, allowing for more specific relations within a broader category. For instance, the FOAF vocabulary's foaf:knows property, which relates individuals indicating reciprocal interaction, can be modeled as a subproperty of a more general "" property to specialize interpersonal connections. This supports layered vocabularies, enhancing reusability and precision in descriptions. RDF and RDFS include foundational built-in classes to underpin the model: rdfs:Class is the class of all classes, serving as an instance of itself; rdfs:Resource acts as the superclass encompassing everything describable in RDF, with all classes being subclasses of it; and rdfs:Literal denotes the class of literal values, such as strings or numbers, which are subclasses of rdfs:Resource. These primitives ensure a consistent ontological foundation for RDF vocabularies. A key distinction in RDF typing arises between class membership, which applies to resources via rdf:type to indicate categorical belonging (e.g., to rdfs:Class), and datatype usage, which pertains to literals for specifying value types like xsd:integer to define lexical forms and value spaces. This separation avoids conflating structural categorization of resources with the precise valuation of literals, though ambiguities can occur when datatypes are misinterpreted as classes in certain entailment scenarios.

Representation and Exchange

Resource Identification

In RDF, resources are uniquely identified using Uniform Resource Identifiers (URIs), with HTTP URIs preferred to enable dereferencing, allowing clients to retrieve descriptions of the resources over the web. This practice aligns with the principles outlined by , which recommend using HTTP URIs as names for things so that they can be looked up to obtain useful information in RDF format. Dereferencable URIs facilitate the discovery and integration of RDF data by ensuring that resolving the identifier yields machine-readable descriptions, such as RDF graphs, thereby promoting interoperability across distributed datasets. Content negotiation enhances resource identification by allowing servers to serve different representations of the same URI based on client requests, typically via HTTP Accept headers. For instance, a client requesting Accept: text/turtle might receive the resource description in Turtle serialization, while a browser requesting HTML (Accept: text/html) gets a human-readable page with embedded RDFa or links to RDF data. This mechanism, rooted in HTTP standards, ensures that RDF resources are accessible in both machine-processable and user-friendly formats without altering the underlying URI. Servers implementing content negotiation must handle multiple media types, such as application/rdf+xml or application/ld+json, to support diverse RDF serializations. To distinguish between information resources (e.g., documents) and non-information resources (e.g., real-world entities like people or concepts), Linked Data employs specific URI patterns: hash URIs (e.g., http://example.org/resource#id) or 303 redirects. With hash URIs, the fragment identifier (#id) identifies the non-information resource, and dereferencing the base URI returns an HTML document with the description linked via the hash; RDF clients can then extract the relevant data without redirection. Alternatively, 303 redirects use a distinct URI for the non-information resource, responding with an HTTP 303 status code that points to a separate information resource URI containing the RDF description, avoiding ambiguity in HTTP range issues. The choice between these approaches depends on server capabilities and the need to avoid client-side fragment processing, with 303 offering clearer separation for complex scenarios. RDF extends URI usage to Internationalized Resource Identifiers (IRIs), which support Unicode characters for global applicability, particularly in multilingual contexts. IRIs are encoded for transmission using percent-encoding (e.g., non-ASCII characters like "é" become %C3%A9 in UTF-8), ensuring compatibility with existing URI infrastructure while allowing natural language identifiers. As defined in RDF 1.1, an IRI in an RDF graph is a Unicode string conforming to RFC 3987 syntax, enabling resources to be named in languages beyond ASCII without loss of meaning. Despite these mechanisms, challenges in RDF resource identification include ensuring URI persistence, where identifiers must remain stable over time to maintain link integrity. Authority delegation requires clear and formal policies for URI namespaces to prevent unauthorized changes, as outlined in W3C best practices for vocabulary management. Common pitfalls, such as using relative URIs in RDF documents, can lead to resolution ambiguities during or merging, as they depend on a base URI that may vary across contexts; absolute URIs are thus recommended for global identifiers to avoid such issues.

Serialization Formats

RDF serialization formats provide concrete syntaxes for encoding RDF graphs and datasets, enabling the representation, storage, and exchange of RDF data across systems. These formats vary in readability, compactness, and suitability for different applications, such as human editing, machine processing, or integration with web technologies. The of these formats reflects a shift from verbose XML-based representations to more concise, developer-friendly alternatives, with efforts by the W3C ensuring . RDF/XML, introduced as the original serialization format in the 2004 RDF 1.0 specification and reaffirmed in the 2014 RDF 1.1 recommendation, uses XML elements to encode RDF triples. It represents subjects via rdf:Description or typed elements with rdf:about attributes for IRIs, predicates as child property elements, and objects as text content or rdf:resource attributes. This structure leverages XML's Namespaces and Infoset for validation but results in verbose markup, making it less intuitive for manual authoring despite its foundational role in early Semantic Web applications. For example:

xml

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/"> <rdf:Description rdf:about="http://example.org/spiderman"> <ex:enemyOf rdf:resource="http://example.org/green-goblin"/> </rdf:Description> </rdf:RDF>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/"> <rdf:Description rdf:about="http://example.org/spiderman"> <ex:enemyOf rdf:resource="http://example.org/green-goblin"/> </rdf:Description> </rdf:RDF>

Its use cases include legacy systems and environments requiring XML processing, though it has been largely supplanted by simpler formats in modern deployments. , standardized as a W3C Recommendation in 2014 under RDF 1.1, offers a compact, human-readable textual syntax that builds on N3 notations for expressing RDF graphs. It supports IRI prefixes via @prefix declarations (e.g., @prefix ex: <http://example.org/> .), semicolon-separated predicates (;), comma-separated objects (,), and @base for relative IRI resolution, allowing concise triple notation like subject predicate object followed by a period. This format prioritizes developer productivity and readability over XML's formality, making it ideal for configuration files, , and editing. An equivalent to the RDF/XML example above is:

@prefix ex: <http://example.org/> . <http://example.org/spiderman> ex:enemyOf <http://example.org/green-goblin> .

@prefix ex: <http://example.org/> . <http://example.org/spiderman> ex:enemyOf <http://example.org/green-goblin> .

Turtle's adoption has grown due to its balance of brevity and expressiveness, serving as the basis for extensions like TriG. , also standardized in the 2014 RDF 1.1 recommendation, is a line-based, plain-text format designed for simplicity and streaming of RDF graphs, with each line encoding one triple as <subject> <predicate> <object> . using absolute IRIs, quoted literals, or blank nodes (_:node). Lacking prefixes or abbreviations, it ensures unambiguous without directives, suiting automated , testing, and bulk transfer. N-Quads extends this in the same 2014 specification by appending a fourth term for graph naming (e.g., <subject> <predicate> <object> <graph> .), enabling of RDF datasets with named graphs for tracking or multi-context scenarios. These formats excel in low-overhead environments like data pipelines but sacrifice readability for precision. JSON-LD, formalized as a W3C Recommendation in 2014 and updated to version 1.1 in 2020, serializes RDF data in format, facilitating integration with web APIs and ecosystems. Its key feature, @context, maps keys to RDF terms (IRIs or vocabularies) and handles data types, allowing plain to represent semantic structures without RDF-specific syntax. For instance, a might define "enemyOf": "http://example.org/enemyOf", enabling compact objects like {"@context": {"enemyOf": "http://example.org/enemyOf"}, "@id": "http://example.org/spiderman", "enemyOf": {"@id": "http://example.org/green-goblin"}}. This bridges RDF with non-semantic web services, supporting use cases in APIs, embedded data in , and schema.org annotations, though it requires processing for full RDF fidelity. Other formats include (N3), a 2008 W3C submission extending Turtle-like syntax with logical features like implications (=>) and variables for rules, favored in early rule-based systems despite lacking formal recommendation status. TriG, introduced in the 2014 RDF 1.1 recommendation, extends to datasets by enclosing named graph content in curly braces (e.g., { <triple> } a ex:Graph .), trading minimal compactness for graph-level expressiveness in scenarios involving multiple contexts. Trade-offs across formats generally favor readability (, ) for development versus compactness and parsability (, ) for exchange. As of November 2025, RDF 1.2 Working Drafts, such as those for Concepts (November 4, 2025) and (November 7, 2025), introduce features like triple terms to support more expressive RDF datasets while maintaining , refining support for these in evolving web standards.

Advanced Mechanisms

Reification and Named Graphs

Reification in RDF provides a mechanism to treat an RDF triple—consisting of a subject, predicate, and object—as a itself, enabling statements to be made about other statements. This is achieved by using the class rdf:Statement from the RDF vocabulary, where an instance of rdf:Statement represents the reified triple, and the properties rdf:subject, rdf:predicate, and rdf:object link it to the original triple's components. For example, to reify the triple <ex:Alice> <ex:age> "30"^^xsd:integer ., one might create:

_:s1 rdf:type rdf:Statement ; rdf:subject <ex:Alice> ; rdf:predicate <ex:age> ; rdf:object "30"^^xsd:integer .

_:s1 rdf:type rdf:Statement ; rdf:subject <ex:Alice> ; rdf:predicate <ex:age> ; rdf:object "30"^^xsd:integer .

This structure allows attaching additional metadata, such as a creation date, to the statement via further about _:s1. In visualizations of nested RDF triples, reification introduces an extra statement node connected to the original subject, predicate, and object, with nested properties attached to this intermediary node. However, traditional RDF reification has notable limitations, including the loss of certain entailments present in the original graph, as the reified form does not preserve the direct semantic relationships or URI denotations of the triple components. For instance, reification may fail to infer equivalences that hold in the unreified graph, complicating reasoning processes. Additionally, it introduces inefficiency in storage and querying due to the proliferation of blank nodes and auxiliary required for each reified statement. As an alternative to full reification, RDF-star introduces support for nested or quoted , allowing a triple to be directly referenced as a term (subject or object) in another triple without the overhead of creating multiple intermediary statements. In RDF-star, the example above could be annotated more concisely as << <ex:Alice> <ex:age> "30"^^xsd:integer >> <ex:created> "2023-01-01"^^xsd:date ., preserving the original triple's structure while enabling annotations. For visualizing nested triples, RDF-star supports displaying them as annotations on the main edge, such as auxiliary edges or labels, avoiding additional nodes for simpler representations. This approach, integrated into RDF 1.2 as triple terms (allowing RDF to appear as objects), addresses reification's verbosity and supports recursive nesting for complex metadata without altering core RDF semantics. RDF 1.2 further enhances reification by introducing the rdf:reifies , where a reifier (subject) links to a triple term (object) to make statements about propositions, such as claims or beliefs, while triple terms can be asserted or unasserted. These features are detailed in the RDF 1.2 Concepts and Abstract Data Model Working Draft of November 2025, produced by the W3C RDF-star Working Group. Named graphs extend RDF by associating an Internationalized Resource Identifier (IRI) or blank node with a specific RDF graph (subgraph of ), effectively partitioning a into multiple identifiable components. This forms part of an RDF , which includes a default (unnamed) graph and zero or more named graphs, where the graph name serves to distinguish and reference the enclosed . Named graphs are particularly useful for tracking , such as attributing to their source or version, and for access control in distributed systems. For example, a named graph might encapsulate from a particular revision, allowing queries to target specific origins. The syntax for named graphs is supported in serialization formats like TriG and N-Quads. In TriG, a named graph is denoted by a graph label followed by curly braces enclosing the triples, such as <ex:provenance1> { <ex:Alice> <ex:age> "30"^^xsd:integer . }. N-Quads extends N-Triples by appending a graph label to each quad (subject-predicate-object-graph), e.g., <ex:Alice> <ex:age> "30"^^xsd:integer <ex:provenance1> ., facilitating the representation of entire datasets with multiple graphs and now supporting triple terms. Common use cases for reification and named graphs include adding metadata about statements, such as trust levels or measures, which is essential in domains like knowledge graphs where reliability varies (e.g., annotating a biological assertion with strength). Named graphs further enable federated queries over partitioned data, supporting versioning by isolating updates in separate graphs. Despite these benefits, reification's drawbacks persist in RDF-star contexts, including increased storage demands and challenges in efficient reasoning over reified structures.

Contexts and Quads

An RDF extends the RDF beyond a single graph by comprising a default graph, which is an unnamed RDF graph, and zero or more named graphs, each associated with an IRI or blank node as its name. This structure allows for the organization of RDF data into multiple contexts within a single , as formally defined in the RDF 1.2 Semantics specification (Working Draft, November 2025). The default graph serves as the primary, unnamed component, while named graphs provide explicit labeling for subsets of , enabling isolation or grouping of related information. Quads represent the fundamental units of an RDF dataset, extending RDF triples by adding a fourth component: a graph name, typically an IRI identifying the named graph containing the triple. Formally, a quad is a (subject, predicate, object, graph-name), where the first three elements form a standard RDF triple, and the graph-name specifies the context or named graph to which it belongs; triples without a specified graph-name belong to the default graph. This quad-based model facilitates the storage and manipulation of multi-graph RDF data, distinguishing it from simple triple-based graphs, and in RDF 1.2 supports triple terms for enhanced expressivity. RDF datasets and quads support key applications such as tracking, where graph names can indicate the source, version, or origin of data subsets, allowing users to trace information back to its providers. They also enable in triplestores by associating permissions or security policies with specific named graphs, restricting queries or updates to authorized contexts. Additionally, in service descriptions, datasets describe the structure of available graphs, including named graphs and their entailment regimes, to inform query planning and execution. For serialization, the TriG format provides a human-readable, compact syntax for RDF datasets, extending Turtle by enclosing triples within curly braces prefixed by a graph name, such as ex:graph1 { ex:s ex:p ex:o . }. In contrast, N-Quads offers a simple, line-based format for machine parsing, representing each quad as space-separated terms ending in a period, like <s> <p> <o> <g> ., with optional graph labels for the default graph. Semantically, RDF 1.2 allows optional extensions where named graphs may be merged into the default graph for entailment purposes, treating the dataset's content as a union while preserving graph isolation for other operations; this merging can share blank nodes across graphs or keep them distinct, depending on the interpretation. Such semantics ensure that inferences apply appropriately without conflating unrelated contexts, maintaining the integrity of multi-graph data.

Querying and Reasoning

Query Languages

SPARQL (SPARQL Protocol and RDF Query Language) is the W3C-standardized declarative query language for RDF, enabling retrieval and manipulation of RDF data across diverse sources. Adopted in 2008 and extended in SPARQL 1.1 in 2013, it provides a unified way to express graph pattern matching, filtering, and aggregation on RDF datasets, which comprise a default graph and zero or more named graphs. The language's protocol defines how queries and updates are exchanged between clients and servers, typically over HTTP. As of November 2025, the W3C RDF & Working Group is developing 1.2 as a Working Draft, introducing enhancements such as support for multiplicity in solutions, ToList and ToMultiSet functions, and updates to the syntax and semantics to align with RDF 1.2 features like triple terms. 1.1 supports four primary query forms: SELECT, CONSTRUCT, ASK, and DESCRIBE. SELECT queries return a tabular result set of variable bindings, projecting specific variables or expressions from matching patterns; for example, SELECT ?name WHERE { ?person foaf:name ?name } retrieves names from FOAF descriptions. CONSTRUCT builds a new RDF graph from a template applied to query solutions, useful for transformation, as in CONSTRUCT { ?s a ex:Person } WHERE { ?s foaf:name ?name }. ASK yields a true or false indicating whether a pattern has any matches, while DESCRIBE generates an RDF graph describing specified resources, though its exact resources are implementation-dependent. At the core of SPARQL queries are graph patterns, starting with basic triple patterns that match subject-predicate-object triples in the dataset, where components can be RDF terms or variables (e.g., ?s ?p ?o). These extend to complex patterns via operators: FILTER restricts solutions with expressions like FILTER (?age > 18), OPTIONAL includes non-binding matches without failing the query, UNION combines alternatives (e.g., { ?x foaf:givenName ?name } UNION { ?x foaf:firstName ?name }), and GRAPH scopes patterns to specific named graphs (e.g., GRAPH <ex:graph1> { ?s ?p ?o }). Solutions are multisets of bindings—mappings from variables to RDF terms—and result sets serialize these in formats like or XML. SPARQL 1.1 Update extends the language for modifying RDF graphs in a graph store, using operations like INSERT to add triples (e.g., INSERT [DATA](/page/Data) { ex:Alice a foaf:[Person](/page/Person) }), DELETE to remove them, and LOAD to from an IRI (e.g., LOAD <http://example.org/data.rdf> INTO GRAPH <ex:g>). These updates are atomic and leverage query-like syntax for prologues and where clauses in more complex cases like INSERT or DELETE with patterns. Preceding SPARQL, languages like RDQL and SeRQL influenced its design. RDQL, a 2004 W3C submission, used SQL-like syntax for triple pattern matching with constraints (e.g., select ?x where (?x, type, person) and ?x.age >= 24 using vcard for <http://www.w3.org/2001/vcard-rdf/3.0#>). SeRQL, developed for the framework, supported RDF/RDFS queries with path expressions, optional matching, and construct queries returning RDF graphs, combining elements from RDQL and RQL. SPARQL 1.1 also includes the Federated Query extension, allowing distributed execution via the SERVICE keyword (e.g., SERVICE <http://dbpedia.org/sparql> { ?s rdfs:label ?label }), which joins remote endpoint results with local data.

Inference Rules

Inference in RDF involves deriving implicit knowledge from explicit triples through defined entailment regimes and rule systems, enabling the expansion of RDF graphs with logically entailed statements. The RDF 1.1 Semantics specification formalizes these mechanisms, providing model-theoretic interpretations for RDF graphs and datasets that determine when one graph entails another. These regimes are monotonic, meaning adding triples to a graph cannot invalidate prior entailments, and they apply to both ground graphs (without blank nodes) and those with existentials represented by blank nodes. As of November 2025, RDF 1.2 Semantics is under development as a W3C Working Draft by the RDF & Working Group, extending the 1.1 to support new features like triple terms and updated entailment rules, alongside 1.2 Entailment Regimes that redefine evaluation under regimes such as RDFS entailment. The simplest regime is simple entailment, which captures the basic graph structure of RDF without considering vocabulary meanings. A graph GG simply entails a graph EE if every simple interpretation satisfying GG also satisfies EE, where interpretations map IRIs and literals to a non-empty domain while treating blank nodes as existential variables. This corresponds to subgraph isomorphism: GG entails EE if EE can be obtained by renaming blank nodes in a subgraph of GG. For example, the {ex:Alice ex:knows _:bob . _:bob rdf:type ex:[Person](/page/Person) .} simply entail {ex:Alice ex:knows ex:Bob .} if _:bob is instantiated as ex:Bob. Simple entailment is decidable but NP-complete in general due to the complexity of blank node matching. RDF entailment extends simple entailment by incorporating the semantics of core RDF vocabulary terms like rdf:type and rdf:Property. A graph SS RDF-entails EE if every RDF interpretation (which recognizes RDF datatypes like xsd:string and enforces that properties denote in the property set) satisfying SS satisfies EE. Key inference rules include datatype instantiation, such as xxx aaa "sss"^^ddd . entailing xxx aaa _:nnn . _:nnn rdf:type ddd . (rdfD1), and property typing, where xxx aaa yyy . entails aaa rdf:type rdf:Property . (rdfD2). This regime handles explicit typing and container memberships but remains lightweight. RDF entailment is also decidable and aligns closely with simple entailment for ground graphs. RDFS entailment builds on RDF entailment by adding semantics for RDFS vocabularies, such as rdfs:subClassOf, rdfs:domain, and rdfs:range, which define class hierarchies and property constraints. A graph SS RDFS-entails EE if every RDFS interpretation (extending RDF interpretations with class extensions and subclass relations) satisfying SS satisfies EE. Inference rules enable closure over hierarchies: for subclass closure, xxx rdfs:subClassOf yyy . zzz rdf:type xxx . entails zzz rdf:type yyy . (rdfs9); for domain inference, aaa rdfs:domain xxx . yyy aaa zzz . entails yyy rdf:type xxx . (rdfs2); and for range, aaa rdfs:range xxx . yyy aaa zzz . entails zzz rdf:type xxx . (rdfs3). These rules propagate types through subclass relations and property declarations, as in the example where ex:Person rdfs:subClassOf ex:Human . ex:Alice rdf:type ex:Person . entails ex:Alice rdf:type ex:Human .. RDFS entailment is decidable and NP-complete, polynomial-time solvable without blank nodes in the target graph. Beyond built-in entailment regimes, RDF supports extensible rule languages for more expressive inference. The (SWRL) combines DL/Lite ontologies with a subset of RuleML to express Horn-like rules over RDF and data. SWRL rules take the form of implications (antecedent atoms → consequent atoms), using variables, individuals, and constructs; for instance, hasParent(?x, ?y) ∧ hasBrother(?y, ?z) → hasUncle(?x, ?z) infers uncles from parent and sibling relations. Its model-theoretic semantics extends interpretations, enabling integration with reasoners, though SWRL itself is semi-decidable when combined with full . Notation3 (N3) rules provide another mechanism, extending RDF syntax with logical formulae for forward- or backward-chaining . N3 rules use implication {antecedent} => {consequent}, supporting universal (@forAll) and existential (@forSome) quantification; an example is {?x a :[Person](/page/Person)} => {?x :isHuman true .}, which infers humanity for persons. As a superset of RDF, N3 enables rule-based reasoning directly in textual notation, with semantics defined operationally for deriving entailed triples from RDF graphs. RDF triplestores often implement through built-in reasoners, balancing performance and flexibility via materialized or on-the-fly approaches. Materialized reasoning precomputes and stores all entailed (e.g., applying RDFS rules upfront), as in systems like RDFox and GraphDB, which accelerate queries but increase storage and require recomputation on updates. On-the-fly reasoning computes during query evaluation, as in OntoBroker, reducing storage overhead and handling dynamic data but potentially slowing responses. The RDF 1.1 Semantics extends these to datasets, defining entailment between named graphs while preserving graph boundaries. Limitations of RDF inference center on its lightweight design: while simple, RDF, and RDFS entailments are decidable, extending to full semantics introduces undecidability due to unrestricted expressive power, such as arbitrary cyclic definitions. Thus, practical systems prioritize RDFS for scalable, tractable reasoning over RDF data.

Constraints and Validation

Description Frameworks

RDF Schema (RDFS) serves as a foundational extension to the Resource Description Framework (RDF), providing a for defining classes, properties, and basic constraints to model domain-specific knowledge in RDF data. It enables the description of RDF vocabularies by introducing terms such as rdfs:Class for defining categories of resources and rdfs:Resource as the universal superclass encompassing all RDF entities. Key properties include rdfs:subClassOf, which establishes hierarchical relationships between classes in a transitive manner, allowing instances of a subclass to inherit properties from superclasses, and rdfs:subPropertyOf, which similarly defines inheritance among properties, ensuring that subproperties can be used interchangeably with their superproperties where applicable. As an extension vocabulary, RDFS builds directly upon RDF's core model, utilizing RDF triples to express its own definitions and thereby facilitating basic without introducing new syntaxes. This integration allows RDFS to describe the structure and semantics of RDF data, such as specifying domains and ranges for via rdfs:domain and rdfs:range, which constrain the types of subjects and objects that can participate in property assertions. For instance, declaring a property's domain as a particular class implies that any resource using that property must be an instance of the specified class. The RDFS entailment regime defines the semantic closure rules that enable over RDF graphs augmented with RDFS vocabulary, supporting and through a set of monotonic rules. Central to this regime are rules for subclass and subproperty transitivity: if class C1 is a subclass of C2 and an instance belongs to C1, it is entailed to belong to C2; similarly, subproperty relations propagate assertions upward. Domain and range rules further entail : if a property has domain C and subject S relates to object O via P, then S is entailed to be of type C. These rules form a lightweight inferencing layer, computable efficiently, that expands the explicit RDF data into implicit knowledge without requiring full reasoning. Practical implementation of RDFS is supported by libraries such as Apache Jena, which provides reasoners for applying RDFS entailment rules to RDF models, including support for rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, and rdfs:range to derive additional triples. Validators in these tools check compliance with RDFS semantics, ensuring that vocabularies adhere to defined hierarchies and constraints during data integration tasks. RDFS establishes a lightweight semantic layer that serves as the foundational base for more expressive ontology languages, such as , which extend RDFS with advanced constructs like property restrictions and cardinality constraints while remaining compatible with RDF serialization.

Shape Languages

Shape languages provide declarative mechanisms for defining and validating the structure of RDF data at the instance level, complementing the vocabulary-focused semantics of RDFS by enforcing constraints on specific nodes and properties. The Shapes Constraint Language (SHACL), standardized as a W3C Recommendation in 2017, enables the validation of RDF graphs—referred to as data graphs—against shapes graphs that specify conditions such as node kinds, value ranges, and property cardinalities. A SHACL 1.2 Working Draft, published in November 2025, introduces enhancements including new constraint components such as sh:xone for exclusive-or logic, property pair constraints like sh:equals and sh:lessThan, and improved list validations with sh:uniqueMembers and length restrictions, aligning with updates in RDF 1.2 and SPARQL 1.2. Shapes in SHACL are typically node shapes that include constraints like sh:property for defining expected predicates and their value shapes, or sh:minCount to require a minimum number of values for a property, ensuring structural integrity without relying on inference. Core components include targets, such as sh:targetClass to select focus nodes based on class membership, shapes graphs that encapsulate the constraints, and validation reports that output conformance status via properties like sh:conforms and detailed results including severity levels. For advanced scenarios, SHACL incorporates SPARQL-based features, allowing custom constraints through queries to handle complex validations beyond core builtins. SHACL supports key use cases including data quality assurance, where it verifies instance data against models to detect missing or invalid properties; schema definition, such as constraining hypermedia-driven interfaces with Hydra; and , ensuring by validating shape compatibility across RDF exchanges. As an alternative, Shape Expressions (ShEx), formalized in , offers a language for RDF with a compact, human-readable syntax (ShExC) that resembles and integrates seamlessly with via ShExJ for machine processing. Unlike SHACL's RDF-centric approach, ShEx emphasizes concise expressions for node and triple constraints, supporting features like algebraic operators (e.g., ) and recursion checks, making it suitable for and validation in diverse environments. These shape languages advance beyond RDFS by prioritizing direct instance validation—checking conformance of actual data nodes—rather than merely defining class and property semantics for inference.

Practical Illustrations

Simple Resource Description

The Resource Description Framework (RDF) enables the description of resources through simple statements known as , each consisting of a subject, predicate, and object. A basic example illustrates this by describing a person named Eric Miller. The subject is a URI (ex:EricMiller) representing the individual, the predicates are properties from the (FOAF) vocabulary, and the objects are either a class URI, a literal string, or another URI. This description can be serialized in , a compact RDF syntax that uses prefixes for and semicolons to group properties for the same subject:

@prefix ex: <http://example.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . ex:EricMiller a foaf:Person ; foaf:name "Eric Miller" ; foaf:workplaceHomepage <http://www.w3.org/> .

@prefix ex: <http://example.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . ex:EricMiller a foaf:Person ; foaf:name "Eric Miller" ; foaf:workplaceHomepage <http://www.w3.org/> .

In this Turtle notation, the prefix ex: defines a base URI for local identifiers, while foaf: refers to the external FOAF vocabulary . The triple ex:EricMiller a foaf:Person (where a is shorthand for rdf:type) asserts that the resource is an instance of the FOAF class. The subsequent triples assign the literal value "Eric Miller" to the foaf:name property and link to the W3C homepage URI via foaf:workplaceHomepage, indicating the individual's workplace. These triples collectively form a in the RDF , with ex:EricMiller as a central node connected by labeled edges (predicates) to other nodes or literal values. The rdf:type edge points to the foaf:Person class node, the foaf:name edge terminates at a literal node containing the string, and the foaf:workplaceHomepage edge points to the external URI node representing the W3C . This graph structure allows resources to be interconnected and queried as a whole, providing a flexible way to represent attributes without a fixed . A key aspect of this simple description is the reuse of established vocabularies like FOAF, which provides standardized terms such as foaf:Person (a class for individuals), foaf:name (a property for a person's name as a literal), and foaf:workplaceHomepage (a property linking to an organization's homepage URI). Literals, such as the quoted string "Eric Miller", capture non-resource values directly, enabling precise attribute assignment while maintaining interoperability across RDF datasets.

Relational Mapping Example

To illustrate how RDF can map relational data structures, consider a simple relational table storing information, with columns for a unique (serving as the ) and the corresponding full name. In RDF, this relational row can be transformed into a set of triples where the identifies the resource (e.g., as a ), the type declares it as a state, and link to the full name and values as literals. For the state of New York, the mapping yields the following triples in format, a plain-text of RDF that emphasizes the subject-predicate-object structure for clarity in relational contexts:

<http://example.org/state/NY> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/vocab#State> . <http://example.org/state/NY> <http://example.org/vocab#postalCode> "NY" . <http://example.org/state/NY> <http://example.org/vocab#fullName> "New York" .

<http://example.org/state/NY> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/vocab#State> . <http://example.org/state/NY> <http://example.org/vocab#postalCode> "NY" . <http://example.org/state/NY> <http://example.org/vocab#fullName> "New York" .

Here, the subject URI <http://example.org/state/NY> derives from the relational key "NY", enabling direct representation without requiring a separate identifier; the predicates act as column mappings, and the objects use literals for the string values. This approach bridges relational databases to RDF by treating keys as resource identifiers and attributes as typed properties, often automated via standards like R2RML for more complex schemas. RDF's flexibility shines in such mappings, as it accommodates tabular data without enforcing fixed schemas—new properties or relations can be added dynamically to the graph, unlike rigid relational joins. This schema-optional nature supports evolving , such as extending the state example with additional attributes like or capital without altering the core structure.

Linked Data Integration

integration utilizes RDF to interconnect disparate on the Web, allowing resources to and link to entities across boundaries in a standardized manner. This approach relies on the use of URIs as global identifiers for resources, enabling machines to follow links from one dataset to another for enriched and discovery. By embedding RDF descriptions with from shared vocabularies, such as FOAF and , data publishers can explicitly denote relationships that span sources, fostering without centralized control. A concrete example of this integration appears in linking Wikipedia articles to structured extracts in DBpedia, where RDF triples describe the article as a resource tied to its conceptual subject. Consider the page for British politician :

<https://en.wikipedia.org/wiki/Tony_Benn> rdf:type foaf:Document ; dc:subject <http://dbpedia.org/resource/Tony_Benn> ; foaf:primaryTopic <http://dbpedia.org/resource/Tony_Benn> .

<https://en.wikipedia.org/wiki/Tony_Benn> rdf:type foaf:Document ; dc:subject <http://dbpedia.org/resource/Tony_Benn> ; foaf:primaryTopic <http://dbpedia.org/resource/Tony_Benn> .

In this representation, the foaf:Document class from the FOAF vocabulary classifies the page as a document, the dc:subject property from indicates its thematic focus, and foaf:primaryTopic specifies the main entity it discusses, which is the DBpedia URI for . DBpedia, derived from infoboxes and categories, exposes this entity with additional RDF assertions about Benn's life, career, and relations, drawn from across approximately 125 language editions. As of the 2023 release, DBpedia extracts structured data describing more than 10 million entities, interlinking to dozens of external datasets. These URIs follow principles by being dereferenceable via HTTP, where resolving the DBpedia URI returns RDF-serialized data—such as or —through based on the requesting agent's Accept headers. This mechanism ensures that dereferencing yields not just but machine-readable descriptions, allowing seamless traversal from the Wikipedia document to DBpedia's . In turn, RDF's graph model supports such cross-dataset linking by treating URIs as nodes that connect local triples to global ones, as seen in DBpedia's interlinks to over 50 external datasets. To further aid integration, RDF datasets employ VoID metadata, a W3C recommendation that describes dataset properties like URI patterns, supported vocabularies, and linkage statistics in RDF form. For DBpedia, VoID descriptions outline its subsets (e.g., person entities) and the volume of links to sources like or , providing a roadmap for consumers to integrate or subset the data effectively. This self-description enhances the ecosystem's scalability, as VoID enables automated discovery of interlinks without manual curation.

Real-World Usage

Semantic Web Applications

RDF serves as a foundational layer in the , enabling the representation of as interconnected that support machine-readable semantics and across diverse applications. By modeling resources, properties, and relationships in a graph structure, RDF facilitates the creation of linked sets that enhance web-scale discovery and reuse. This foundational role positions RDF at the core of initiatives aimed at transforming the web into a global , where from various sources can be queried and reasoned over uniformly. RDF integrates seamlessly with the (OWL) to define ontologies that extend RDF's expressive power for formal reasoning and inference. OWL ontologies, serialized in RDF, allow for the specification of classes, properties, and axioms that enable over RDF data, such as classifying instances or detecting inconsistencies. For instance, OWL's build upon (RDFS) to support complex semantic relationships, making it possible to derive implicit knowledge from explicit RDF triples. This integration is crucial for applications requiring deductive capabilities, as evidenced in W3C specifications that ensure compatibility between RDF graphs and OWL constructs. Complementing , the (SKOS) leverages RDF to represent systems like thesauri, taxonomies, and controlled vocabularies. SKOS provides a lightweight model for concepts, labels, and semantic relations (e.g., broader/narrower), allowing RDF-based encoding of non-hierarchical knowledge structures without the full rigor of OWL ontologies. This enables easier publication and linking of terminological resources on the web, supporting tasks such as multilingual indexing and concept mapping in systems. W3C's SKOS Reference defines this RDF vocabulary to promote reuse of existing systems in contexts. The Linked Open Data (LOD) Cloud exemplifies RDF's application in large-scale data publishing, where datasets are exposed via dereferenceable URIs and linked using RDF vocabularies. As of September 2025, the LOD Cloud comprises 1,357 datasets interconnected by thousands of links, encompassing tens of billions of RDF triples across domains like government, life sciences, and . This growth, from just 12 datasets in to the current scale, demonstrates RDF's scalability in fostering an ecosystem of reusable, interlinked . The LOD initiative, coordinated through community efforts, relies on RDF's flexibility to enable querying across distributed sources, driving applications in and . Practical deployment of RDF in Semantic Web applications is supported by a range of specialized tools, including for storage and querying. , an open-source RDF , handles massive datasets with high-performance endpoints and supports inference over RDF, RDFS, and , scaling to billions of in enterprise environments. RDF libraries further enable programmatic manipulation of Semantic Web data. RDFlib, a Python library, provides parsers, serializers, and querying capabilities for RDF formats like and , facilitating integration into AI pipelines and data processing scripts. Apache , a framework, offers comprehensive support for RDF storage, ontology management, and execution, including Fuseki for server deployment. These libraries are widely adopted for building RDF-based applications due to their adherence to W3C standards. For visualization and exploration, tools like YASGUI provide user-friendly interfaces with , auto-completion, and result rendering in formats such as tables and charts. YASGUI enhances developer productivity by simplifying query testing against public endpoints, as detailed in its Semantic Web Journal publication. The W3C's standards roadmap underscores RDF's pivotal position as the baseline for data interchange, with subsequent layers like RDFS, , and building upon it to enable advanced semantics and querying. Originating from Tim Berners-Lee's 1998 vision, this layered architecture has evolved through W3C recommendations, ensuring RDF's role in a cohesive for machine-understandable web content. Recent updates, including RDF 1.1 and 2, maintain backward compatibility while addressing modern needs like streaming and integration. Emerging trends highlight RDF's adaptation to AI knowledge graphs, where its triple-based structure supports entity linking and semantic enrichment for large language models. RDF enables interoperable knowledge representation in AI systems, as seen in frameworks that use RDF for grounding neural networks in verifiable facts from LOD sources. In Web3 decentralized data contexts, RDF principles inspire standards like ontologies for DAOs, facilitating semantic querying over blockchain-stored triples to enhance trustless data sharing. For example, the Web3-DAO ontology models governance structures in RDF, bridging decentralized applications with Semantic Web reasoning.

Data Integration and Interoperability

RDF plays a pivotal role in and by enabling the merging of heterogeneous data sources through its flexible graph-based model, which allows for the representation of relationships across disparate without requiring a unified global . This capability addresses key challenges in aligning and federating data from diverse origins, such as databases, web services, and linked repositories, facilitating seamless querying and reuse. Ontology alignment techniques are essential for mapping vocabularies across RDF datasets, ensuring semantic consistency during integration. The framework provides a declarative approach to discovering links between RDF entities by specifying similarity conditions, such as string matching or property comparisons, to generate equivalence or relatedness assertions like owl:sameAs. Similarly, OWL alignment methods, supported by tools like the Alignment API, establish correspondences between ontology entities using techniques such as structure-based matching or , producing RDF mappings that bridge conceptual differences. These techniques promote vocabulary reuse, often referencing established RDF vocabularies like those in the Conceptual Building Blocks for semantic enrichment. Federated SPARQL extends RDF querying to distributed environments, allowing integration without physical data movement. The SERVICE keyword in 1.1 enables subqueries to be executed against remote RDF endpoints, composing results from multiple sources into a unified response, which supports scalable across federated datasets. In healthcare, RDF integration with HL7 FHIR standards allows clinical data from electronic health records to be represented as RDF graphs, enabling semantic querying and linkage with research datasets for improved patient care coordination. The EU Data Portal leverages RDF to catalog and interconnect data from across , using endpoints to facilitate cross-border discovery and reuse of information. In , RDF supports product matching by aligning item descriptions from multiple vendors through schema.org vocabularies and link discovery, reducing duplication and enhancing recommendation systems. Despite these advances, RDF integration faces challenges including schema evolution, where changes in ontology structures over time can break existing links and require ongoing mapping . Data silos persist due to proprietary formats and access restrictions, hindering efforts and necessitating robust alignment tools. Quality metrics, such as those provided by the Linked Open Vocabularies (LOV) catalog, help mitigate issues by promoting reuse of standardized terms and assessing vocabulary alignment precision. Standards like VoID (Vocabulary of Interlinked Datasets) provide RDF-based descriptions of datasets, including metadata on structure, access, and interlinks, to aid discovery and optimization in integrated environments. Complementing this, the DCAT (Data Catalog Vocabulary) enables cataloging of RDF datasets with properties for distribution formats and licenses, fostering in data portals and marketplaces.

References

  1. https://www.w3.org/RDF/
  2. https://www.w3.org/TR/rdf12-concepts/
  3. https://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
  4. https://www.w3.org/TR/rdf11-concepts/
  5. https://www.w3.org/TR/rdf-schema/
  6. https://www.w3.org/2000/Talks/0906-xmlweb-tbl/text.htm
  7. https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
  8. https://www.w3.org/TR/rdf11-new/
  9. https://datatracker.ietf.org/doc/html/rfc3987
  10. https://www.w3.org/TR/xmlschema11-2/
  11. https://www.w3.org/TR/ld-bp/
  12. https://www.w3.org/2006/07/SWD/Vocab/principles
  13. https://www.w3.org/DesignIssues/LinkedData.html
  14. https://www.w3.org/TR/cooluris/
  15. https://www.w3.org/TR/dx-prof-conneg/
  16. https://www.w3.org/2001/sw/BestPractices/VM/principles/20050705
  17. https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/
  18. https://www.w3.org/TR/2014/REC-turtle-20140225/
  19. https://www.w3.org/TR/2014/REC-n-triples-20140225/
  20. https://www.w3.org/TR/2020/REC-json-ld11-20200716/
  21. https://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/
  22. https://www.w3.org/TR/rdf-schema/#ch_reificationvocab
  23. https://www.w3.org/DesignIssues/Reify.html
  24. https://www.w3.org/TR/rdf12-concepts/#section-dataset
  25. https://www.w3.org/TR/trig/#sec-syntax-named
  26. https://www.w3.org/TR/rdf12-n-quads/
  27. https://w3c.github.io/rdf-star/UCR/rdf-star-ucr.html
  28. https://www.w3.org/TR/rdf12-semantics/
  29. https://www.w3.org/TR/rdf12-datasets/
  30. https://www.w3.org/2009/12/rdf-ws/papers/ws25.pdf
  31. https://www.w3.org/TR/sparql11-service-description/
  32. https://www.w3.org/TR/trig/
  33. https://www.w3.org/TR/n-quads/
  34. https://www.w3.org/TR/sparql11-query/
  35. https://www.w3.org/TR/sparql11-overview/
  36. https://www.w3.org/TR/sparql11-protocol/
  37. https://www.w3.org/TR/sparql12-query/
  38. https://w3c.github.io/sparql-new/spec/
  39. https://www.w3.org/TR/sparql11-results-json/
  40. https://www.w3.org/TR/sparql11-update/
  41. https://www.w3.org/submissions/rdql/
  42. https://standards.clarin.eu/sis/views/view-spec.xq?id=SpecSeRQL
  43. https://www.w3.org/TR/sparql11-federated-query/
  44. https://www.w3.org/TR/rdf11-mt/
  45. https://w3c.github.io/sparql-entailment/spec/
  46. https://www.sciencedirect.com/science/article/abs/pii/S1570826805000144
  47. https://www.w3.org/submissions/SWRL/
  48. https://www.w3.org/TeamSubmission/n3/
  49. https://wires.onlinelibrary.wiley.com/doi/full/10.1002/widm.1537
  50. https://www.semantic-web-book.org/w/images/5/5e/KI09-OWL-Rules-2.pdf
  51. https://www.w3.org/TR/rdf12-schema/
  52. https://jena.apache.org/documentation/rdfs/
  53. https://www.w3.org/TR/owl2-overview/
  54. https://www.w3.org/TR/shacl/
  55. https://www.w3.org/TR/shacl12-core/
  56. https://www.w3.org/TR/shacl-ucr/
  57. https://shexspec.github.io/spec/
  58. https://www.w3.org/2014/data-shapes/wiki/SHACL-ShEx-Comparison
  59. http://xmlns.com/foaf/spec/
  60. https://www.w3.org/TR/rdb-direct-mapping/
  61. https://www.w3.org/TR/r2rml/
  62. https://www.dbpedia.org/resources/datasets/
  63. https://link.springer.com/chapter/10.1007/978-3-540-76298-0_52
  64. https://www.w3.org/TR/owl2-primer/
  65. https://www.w3.org/TR/rif-rdf-owl/
  66. https://www.w3.org/TR/skos-reference/
  67. https://lod-cloud.net/
  68. https://www.getty.edu/research/tools/vocabularies/Linked_Data_Getty_Vocabularies.pdf
  69. https://db-engines.com/en/ranking/rdf%2Bstore
  70. https://www.w3.org/wiki/LargeTripleStores
  71. https://rdflib.readthedocs.io/
  72. https://jena.apache.org/tutorials/rdf_api.html
  73. https://www.semantic-web-journal.net/system/files/swj1126.pdf
  74. https://www.w3.org/DesignIssues/Semantic.html
  75. https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1546179/full
  76. https://www.sciencedirect.com/science/article/pii/S1570826824000167
  77. https://dl.acm.org/doi/10.1145/3653317
  78. https://ceur-ws.org/Vol-538/ldow2009_paper13.pdf
  79. https://www.semantic-web-journal.net/sites/default/files/swj60_0.pdf
  80. https://build.fhir.org/rdf.html
  81. https://data.europa.eu/data/sparql?locale=en
  82. https://www.semantic-web-journal.net/system/files/swj1470.pdf
  83. https://www.mdpi.com/2078-2489/16/11/932
  84. https://www.ontotext.com/blog/data-fabric-with-knowledge-graphs/
  85. https://semantic-web-journal.net/system/files/swj974.pdf
  86. https://www.w3.org/TR/void/
  87. https://www.w3.org/TR/vocab-dcat-3/
Add your contribution
Related Hubs
User Avatar
No comments yet.