RDFLib


RDFLib is a Python library for working with RDF, a simple yet powerful language for representing information. Through this library, Python is one of the main RDF manipulation languages, the other being Java. This library contains parsers/serializers for almost all of the known RDF serializations, such as RDF/XML, Turtle, N-Triples, & JSON-LD, many of which are now supported in their updated form. The library also contains both in-memory and persistent Graph back-ends for storing RDF information and numerous convenience functions for declaring graph namespaces, lodging SPARQL queries and so on. It is in continuous development with the most recent stable release, having been released on 18 April, 2020. It was originally created by Daniel Krech with the first release in November, 2002.
A number of other Python projects use rdflib for RDF manipulation, including:

Overview

RDFLib and Python idioms

RDFLib's use of various Python idioms mean it is fairly simple for programmers with only junior Python skills to manipulate RDF. On the other hand, the Python idioms are simple enough that someone familiar with RDF, but not Python, can probably work out how to use rdflib quite easily.
The core class in RDFLib is which is a Python dictionary used to store collections of RDF triples in memory. It redefine certain built-in Python object methods in order to exhibit simple graph behaviour, such as simple graph merging via addition.
RDFLib graphs emulate container types and are best thought of as a set of 3-item triples:
set,
,
...

])
RDFLib graphs are not sorted containers; they have ordinary Python set operations, e.g. add methods that search triples and return them in arbitrary order.

RDF graph terms

The following RDFLib classes model in a graph and inherit from a common class, which extends Python unicode. Instances of these are nodes in an RDF graph.
RDFLib provides mechanisms for managing namespaces. In particular, there is a class which takes the Base URI of the namespace. Fully qualified URIs in the namespace can be constructed by attribute / dictionary access on Namespace instances:

>>> from rdflib import Namespace
>>> SDO = Namespace
>>> SDO.Person
https://schema.org/Person
>>> SDO
https://schema.org/url

Graphs as iterators

RDFLib graphs also override __iter__ in order to support iteration over the contained triples:

for subject, predicate, object_ in someGraph:
assert in someGraph, "Iterator / Container Protocols are Broken!!"

Set operations on RDFLib graphs

__iadd__ and __isub__ are overridden to support adding and subtracting Graphs to/from each other :
RDFLib graphs support basic triple pattern matching with a triples) function. This function is a generator of triples that match the pattern given by the arguments. The arguments of these are RDF terms that restrict the triples that are returned. Terms that are None are treated as a wildcard.

for subject, predicate, object_ in someGraph.triples:
print # prints all the triples with the predicate being https://schema.org/name

RDF convenience APIs (RDF collections / containers)

Managing triples

Adding triples

Triples can be added in two ways:
Similarly, triples can be removed by a call to remove: remove)

RDF Literal support

RDFLib 'Literal's essentially behave like Unicode characters with an XML Schema datatype or language attribute. The class provides a mechanism to both convert Python literals into equivalent RDF Literals and convert Literals to their Python equivalent. There is some support of considering datatypes in comparing Literal instances, implemented as an override to __eq__. This mapping to and from Python literals is achieved with the following dictionaries:

PythonToXSD =

Maps Python instances to WXS datatyped Literals

XSDToPython =

Maps WXS datatyped Literals to Python. This mapping is used by the toPython method defined on all Literal instances.

SPARQL querying

RDFLIb supports a majority of the current SPARQL 1.1 specification and includes a harness for the publicly available RDF DAWG test suite. Support for SPARQL is provided by two methods:

The RDF store API

A Universal RDF Store Interface
This document attempts to summarize some fundamental components of an RDF store. The motivation is to outline a standard set of interfaces for providing the necessary support needed in order to persist an RDF Graph in a way that is universal and not tied to any specific implementation. For the most part, the core RDF model is adhered to as well as terminology that is consistent with the RDF Model specifications. However, this suggested interface also extends an RDF store with additional requirements necessary to facilitate the aspects of Notation 3 that go beyond the RDF model to provide a framework for First Order Predicate Logic processing and persistence.
Terminology
;Context: A named, unordered set of statements. Also could be called a sub-graph. The named graphs literature and ontology are relevant to this concept. A context could be thought of as only the relationship between an RDF triple and a sub-graph in which it is found or the sub-graph itself.
;Conjunctive Graph: This refers to the 'top-level' Graph. It is the aggregation of all the contexts within it and is also the appropriate, absolute boundary for closed world assumptions / models. This distinction is the low-hanging fruit of RDF along the path to the semantic web and most of its value is in real-world problems:

rdf:type :ConjunctiveGraph
rdf:type log:Truth
:persistedBy :MySQL

;Quoted Statement: A statement that isn't asserted but is referred to in some manner. Most often, this happens when we want to make a statement about another statement without necessarily saying these quoted statements. For example:


;Formula: A context whose statements are quoted or hypothetical.
;Terms: Terms are the kinds of objects that can appear in a quoted/asserted triple. This includes those that are core to RDF:
;Nodes: Nodes are a subset of the Terms that the underlying store actually persists. The set of such Terms depends on whether or not the store is formula-aware. Stores that aren't formula-aware would only persist those terms core to the RDF Model, and those that are formula-aware would be able to persist the N3 extensions as well. However, utility terms that only serve the purpose for matching nodes by term-patterns probably will only be terms and not nodes.
;Context-aware: An RDF store capable of storing statements within contexts is considered context-aware. Essentially, such a store is able to partition the RDF model it represents into individual, named, and addressable sub-graphs.
;Formula-aware: An RDF store capable of distinguishing between statements that are asserted and statements that are quoted is considered formula-aware.
;Conjunctive Query: Any query that doesn't limit the store to search within a named context only. Such a query expects a context-aware store to search the entire asserted universe. A formula-aware store is expected not to include quoted statements when matching such a query.
;N3 Round Trip: This refers to the requirements on a formula-aware RDF store's persistence mechanism necessary for it to be properly populated by a N3 parser and rendered as syntax by a N3 serializer.
;Transactional Store: An RDF store capable of providing transactional integrity to the RDF operations performed on it.
Interpreting syntax
The following Notation 3 document:

=>

Could cause the following statements to be asserted in the store:

_:a log:implies _:b

This statement would be asserted in the partition associated with quoted statements

?x rdf:type :N3Programmer

Finally, these statements would be asserted in the same partition

?x :has _:c
_:c rdf:type :Migraine

Formulae and Variables as Terms
Formulae and variables are distinguishable from URI references, Literals, and BNodes by the following syntax:

- Formula
?x - Variable

They must also be distinguishable in persistence to ensure they can be round tripped. Other issues regarding the persistence of N3 terms.
Database management
An RDF store should provide standard interfaces for the management of database connections. Such interfaces are standard to most database management systems
The following methods are defined to provide this capability:
The configuration string is understood by the store implementation and represents all the necessary parameters needed to locate an individual instance of a store. This could be similar to an ODBC string, or in fact be an ODBC string if the connection protocol to the underlying database is ODBC. The open function needs to fail intelligently in order to clearly express that a store already exists or that there is no store depending on the value of create.
Triple interfaces
An RDF store could provide a standard set of interfaces for the manipulation, management, and/or retrieval of its contained triples :
This function can be thought of as the primary mechanism for producing triples with nodes that match the corresponding terms and term pattern provided.
A conjunctive query can be indicated by either providing a value of NULL/None/Empty string value for context or the identifier associated with the Conjunctive Graph.
These interfaces work on contexts and formulae interchangeably.
RDFLib defines the following kinds of Graphs:
A Conjunctive Graph is the most relevant collection of graphs that are considered to be the boundary for closed world assumptions. This boundary is equivalent to that of the store instance. It is equivalent to all the named graphs within it and associated with a _default_ graph which is automatically assigned a BNode for an identifier - if one isn't given.

Formulae

RDFLib graphs support an additional extension of RDF semantics for formulae. For the academically inclined, Graham Klyne's 'formal' extension is probably a good read.
Formulae are represented formally by the 'QuotedGraph' class and disjoint from regular RDF graphs in that their statements are quoted.

Persistence

RDFLib provides an abstracted Store API for persistence of RDF and Notation 3. The Graph class works with instances of this API for triple-based management of an RDF store including: garbage collection, transaction management, update, pattern matching, removal, length, and database management . Additional persistence mechanisms can be supported by implementing this API for a different store. Currently supported databases:
Store instances can be created with the plugin function:

from rdflib import plugin
from rdflib.store import Store
plugin.get

'Higher-order' idioms

There are a few high-level APIs that extend RDFLib graphs into other Pythonic idioms. For more a more explicit Python binding, there are , & .

Support

Documentation for RDFlib is online at and is both handwritten by contributors and auto-generated from code.
For general “how do I…” queries, users are encouraged to https://stackoverflow.com and tag question with .
Developers wanting to discuss RDFlib mechanics can use the and anyone can raise Issues or submit code improvements via Pull Requests against the .