RDF.ex

An implementation of the RDF data model in Elixir.

Features

• fully compatible with the RDF 1.1 specification
• in-memory data structures for RDF descriptions, RDF graphs and RDF datasets
• support for RDF vocabularies via Elixir modules for safe, i.e. compile-time checked and concise usage of IRIs
• XML schema datatypes for RDF literals (not yet all supported)
• sigils for the most common types of nodes, i.e. IRIs, literals, blank nodes and lists
• a description DSL resembling Turtle in Elixir
• implementations for the N-Triples, N-Quads and Turtle serialization formats
  • JSON-LD is implemented in the separate JSON-LD.ex package
• a SPARQL client is implemented in the separate SPARQL.Client package

Installation

The RDF.ex Hex package can be installed as usual, by adding rdf to your list of dependencies in mix.exs:

def deps do
  [{:rdf, "~> 0.4"}]
end

Usage

The RDF standard defines a graph data model for distributed information on the web. A RDF graph is a set of statements aka RDF triples consisting of three nodes:

1. a subject node with an IRI or a blank node,
2. a predicate node with the IRI of a RDF property,
3. an object node with an IRI, a blank node or a RDF literal value.

Let's see how the different types of nodes are represented with RDF.ex in Elixir.

IRIs

RDF.ex follows the RDF specs and supports IRIs, an internationalized generalization of URIs, permitting a wider range of Unicode characters. They are represented with the RDF.IRI structure and can be constructed either with RDF.IRI.new/1 or RDF.IRI.new!/1, the latter of which additionally validates, that the given IRI is actually a valid absolute IRI or raises an exception otherwise.

RDF.IRI.new("http://www.example.com/foo")
RDF.IRI.new!("http://www.example.com/foo")

The RDF module defines the alias functions RDF.iri/1 and RDF.iri!/1 delegating the resp. new function:

RDF.iri("http://www.example.com/foo")
RDF.iri!("http://www.example.com/foo")

Besides being a little shorter than RDF.IRI.new and better importable, their usage will automatically benefit from any future IRI creation optimizations and is therefore recommended over the original functions.

A literal IRI can also be written with the ~I sigil:

~I<http://www.example.com/foo>

But there's an even shorter notation for IRI literals.

Vocabularies

RDF.ex supports modules which represent RDF vocabularies as RDF.Vocabulary.Namespaces. It comes with predefined modules for some fundamental vocabularies defined in the RDF.NS module. Furthermore, the rdf_vocab package contains predefined RDF.Vocabulary.Namespaces for the most popular vocabularies.

These RDF.Vocabulary.Namespaces (a special case of a RDF.Namespace) allow for something similar to QNames in XML: an atom or function qualified with a RDF.Vocabulary.Namespace can be resolved to an IRI.

There are two types of terms in a RDF.Vocabulary.Namespace which are resolved differently:

1. Capitalized terms are by standard Elixir semantics module names, i.e. atoms. At all places in RDF.ex where an IRI is expected, you can use atoms qualified with a RDF.Namespace instead. If you want to resolve them manually, you can pass a RDF.Namespace qualified atom to RDF.iri.
2. Lowercased terms for RDF properties are represented as functions on a RDF.Vocabulary.Namespace module and return the IRI directly, but since RDF.iri can also handle IRIs directly, you can safely and consistently use it with lowercased terms too.

iex> import RDF, only: [iri: 1]
iex> alias RDF.NS.{RDFS}

iex> RDFS.Class
RDF.NS.RDFS.Class

iex> iri(RDFS.Class)
~I<http://www.w3.org/2000/01/rdf-schema#Class>

iex> RDFS.subClassOf
~I<http://www.w3.org/2000/01/rdf-schema#subClassOf>

iex> iri(RDFS.subClassOf)
~I<http://www.w3.org/2000/01/rdf-schema#subClassOf>

As this example shows, the namespace modules can be easily aliased. When required, they can be also aliased to a completely different name. Since the RDF vocabulary namespace in RDF.NS.RDF can't be aliased (it would clash with the top-level RDF module), all of its elements can be accessed directly from the RDF module (without an alias).

iex> import RDF, only: [iri: 1]
iex> RDF.type
~I<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>

iex> iri(RDF.Property)
~I<http://www.w3.org/1999/02/22-rdf-syntax-ns#Property>

This way of expressing IRIs has the additional benefit, that the existence of the referenced IRI is checked at compile time, i.e. whenever a term is used that is not part of the resp. vocabulary an error is raised by the Elixir compiler (unless the vocabulary namespace is non-strict; see below).

For terms not adhering to the capitalization rules (lowercase properties, capitalized non-properties) or containing characters not allowed within atoms, the predefined namespaces in RDF.NS and RDF.Vocab define aliases accordingly. If unsure, have a look at the documentation or their definitions.

Description DSL

The functions for the properties on a vocabulary namespace module, are also available in a description builder variant, which accepts subject and objects as arguments.

RDF.type(EX.Foo, EX.Bar)

If you want to state multiple statements with the same subject and predicate, you can either pass the objects as a list or as additional arguments, if there are not more than five of them:

RDF.type(EX.Foo, EX.Bar, EX.Baz)
EX.foo(EX.Bar, [1, 2, 3, 4, 5, 6])

In combination with Elixirs pipe operators this leads to a description DSL resembling Turtle:

EX.Foo
|> RDF.type(EX.Bar)
|> EX.baz(1, 2, 3)

The produced statements are returned by this function as a RDF.Description structure which will be described below.

Defining vocabulary namespaces

There are two basic ways to define a namespace for a vocabulary:

1. You can define all terms manually.
2. You can extract the terms from existing RDF data for IRIs of resources under the specified base IRI.

It's recommended to introduce a dedicated module for the defined namespaces. In this module you'll use RDF.Vocabulary.Namespace and define your vocabulary namespaces with the defvocab macro.

A vocabulary namespace with manually defined terms can be defined in this way like that:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    terms: ~w[Foo bar]
    
end

The base_iri argument with the IRI prefix of all the terms in the defined vocabulary is required and expects a valid IRI ending with either a "/" or a "#". Terms will be checked for invalid characters at compile-time and will raise a compiler error. This handling of invalid characters can be modified with the invalid_characters options, which is set to :fail by default. By setting it to :warn only warnings will be raised or it can be turned off completely with :ignore.

A vocabulary namespace with extracted terms can be defined either by providing RDF data directly with the data option or files with serialized RDF data in the priv/vocabs directory using the file option:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    file: "your_vocabulary.nt"
    
end

During compilation the terms will be validated and checked for proper capitalisation by analysing the schema description of the resp. resource in the given data. This validation behaviour can be modified with the case_violations options, which is by default set to :warn. By setting it explicitly to :fail errors will be raised during compilation or it can be turned off with :ignore.

Invalid characters or violations of capitalization rules can be fixed by defining aliases for these terms with the alias option and a keyword list:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    file: "your_vocabulary.nt"
    alias: [example_term: "example-term"]

end

The :ignore option allows to ignore terms:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    file: "your_vocabulary.nt",
    ignore: ~w[Foo bar]
    
end

Though strictly discouraged, a vocabulary namespace can be defined as non-strict with the strict option set to false. A non-strict vocabulary doesn't require any terms to be defined (although they can). A term is resolved dynamically at runtime by concatenation of the term and the base IRI of the resp. namespace module:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    terms: [], 
    strict: false
end

iex> import RDF, only: [iri: 1]
iex> alias YourApp.NS.{EX}

iex> iri(EX.Foo)
~I<http://www.example.com/ns/Foo>

iex> EX.bar
~I<http://www.example.com/ns/bar>

iex> EX.Foo |> EX.bar(EX.Baz)
#RDF.Description{subject: ~I<http://www.example.com/ns/Foo>
     ~I<http://www.example.com/ns/bar>
         ~I<http://www.example.com/ns/Baz>}

Blank nodes

Blank nodes are nodes of an RDF graph without an IRI. They are always local to that graph and mostly used as helper nodes.

They can be created with RDF.BlankNode.new or its alias function RDF.bnode. You can either pass an atom, string, integer or Erlang reference with a custom local identifier or call it without any arguments, which will create a local identifier automatically.

RDF.bnode(:foo)
RDF.bnode(42)
RDF.bnode

You can also use the ~B sigil to create a blank node with a custom name:

import RDF.Sigils
~B<foo>

Literals

Literals are used for values such as strings, numbers, and dates. They can be untyped, languaged-tagged or typed. In general they are created with the RDF.Literal.new constructor function or its alias function RDF.literal:

RDF.Literal.new("foo")
RDF.literal("foo")

The actual value can be accessed via the value struct field:

RDF.literal("foo").value

An untyped literal can also be created with the ~L sigil:

import RDF.Sigils

~L"foo"

A language-tagged literal can be created by providing the language option with a BCP47-conform language or by adding the language as a modifier to the ~L sigil:

import RDF.Sigils

RDF.literal("foo", language: "en")

~L"foo"en

Note: Only languages without subtags are supported as modifiers of the ~L sigil, i.e. if you want to use en-US as a language tag, you would have to use RDF.literal or RDF.Literal.new.

A typed literal can be created by providing the datatype option with an IRI of a datatype. Most of the time this will be an XML schema datatype:

RDF.literal("42", datatype: XSD.integer)

It is also possible to create a typed literal by using a native Elixir non-string value, for which the following datatype mapping will be applied:

Elixir datatype	XSD datatype
boolean	xsd:boolean
integer	xsd:integer
float	xsd:double
Time	xsd:time
Date	xsd:date
DateTime	xsd:dateTime
NaiveDateTime	xsd:dateTime
Decimal	xsd:decimal

So the former example literal can be created equivalently like this:

RDF.literal(42)

For all of these known datatypes the value struct field contains the native Elixir value representation according to this mapping. When a known XSD datatype is specified, the given value will be converted automatically if needed and possible.

iex> RDF.literal(42, datatype: XSD.double).value
42.0

For all of these supported XSD datatypes there're RDF.Datatypes available that allow the creation of RDF.Literals with the respective datatype. Their new constructor function can be called also via the alias functions on the top-level RDF namespace.

iex> RDF.Double.new("0042").value
42.0

iex> RDF.Double.new(42).value
42.0

iex> RDF.double(42).value
42.0

The RDF.Literal.valid?/1 function checks if a given literal is valid according to the XML schema datatype specification.

iex> RDF.Literal.valid? RDF.integer("42")
true

iex> RDF.Literal.valid? RDF.integer("foo")
false

If you want to prohibit the creation of invalid literals, you can use the new! constructor function of RDF.Datatype or RDF.Literal, which will fail in case of invalid values.

A RDF literal is bound to the lexical form of the initially given value. This lexical representation can be retrieved with the RDF.Literal.lexical/1 function:

iex> RDF.Literal.lexical RDF.integer("0042")
"0042"

iex> RDF.Literal.lexical RDF.integer(42)
"42"

Although two literals might have the same value, they are not equal if they don't have the same lexical form:

iex> RDF.integer("0042").value == RDF.integer("42").value
true

iex> RDF.integer("0042") == RDF.integer("42")
false

The RDF.Literal.canonical/1 function returns the given literal with its canonical lexical form according its datatype:

iex> RDF.integer("0042") |> RDF.Literal.canonical |> RDF.Literal.lexical
"42"

iex> RDF.Literal.canonical(RDF.integer("0042")) == 
     RDF.Literal.canonical(RDF.integer("42"))
true

Note: Although you can create any XSD datatype by using the resp. IRI with the datatype option of RDF.Literal.new, not all of them support the validation and conversion behaviour of RDF.Literals and the value field simply contains the initially given value unvalidated and unconverted.

Statements

RDF statements are generally represented in RDF.ex as native Elixir tuples, either as 3-element tuples for triples or as 4-element tuples for quads.

The RDF.Triple and RDF.Quad modules both provide a function new for such tuples, which coerces the elements to proper nodes when possible or raises an error when such a coercion is not possible. In particular these functions also resolve qualified terms from a vocabulary namespace. They can also be called with the alias functions RDF.triple and RDF.quad.

iex> RDF.triple(EX.S, EX.p, 1)
{~I<http://example.com/S>, ~I<http://example.com/p>, RDF.integer(1)}

iex> RDF.triple {EX.S, EX.p, 1}
{~I<http://example.com/S>, ~I<http://example.com/p>, RDF.integer(1)}

iex> RDF.quad(EX.S, EX.p, 1, EX.Graph)
{~I<http://example.com/S>, ~I<http://example.com/p>, RDF.integer(1),
 ~I<http://example.com/Graph>}

iex> RDF.triple {EX.S, 1, EX.O}
** (RDF.Triple.InvalidPredicateError) '1' is not a valid predicate of a RDF.Triple
    (rdf) lib/rdf/statement.ex:53: RDF.Statement.coerce_predicate/1
    (rdf) lib/rdf/triple.ex:26: RDF.Triple.new/3

If you want to explicitly create a quad in the default graph context, you can use nil as the graph name. The nil value is used consistently as the name of the default graph within RDF.ex.

iex> RDF.quad(EX.S, EX.p, 1, nil)
{~I<http://example.com/S>, ~I<http://example.com/p>, RDF.integer(1), nil}

RDF data structures

RDF.ex provides various data structures for collections of statements:

• RDF.Description: a collection of triples about the same subject
• RDF.Graph: a named collection of statements
• RDF.Dataset: a named collection of graphs, i.e. a collection of statements from different graphs; it may have multiple named graphs and at most one unnamed ("default") graph

All of these structures have similar sets of functions and implement Elixirs Enumerable and Collectable protocol, Elixirs Access behaviour and the RDF.Data protocol of RDF.ex.

The new function of these data structures create new instances of the struct and optionally initialize them with initial statements. RDF.Description.new requires at least an IRI or blank node for the subject, while RDF.Graph.new and RDF.Dataset.new take an optional IRI for the name of the graph or dataset.

empty_description = RDF.Description.new(EX.Subject)

empty_unnamed_graph = RDF.Graph.new
empty_named_graph   = RDF.Graph.new(EX.Graph)

empty_unnamed_dataset = RDF.Dataset.new
empty_named_dataset   = RDF.Dataset.new(EX.Dataset)

As you can see, qualified terms from a vocabulary namespace can be given instead of an IRI and will be resolved automatically. This applies to all of the functions discussed below.

The new functions can be called more shortly with the resp. delegator functions RDF.description, RDF.graph and RDF.dataset.

The new functions also take optional initial data, which can be provided in various forms. Basically it takes the given data and hands it to the add function with the newly created struct.

Adding statements

So let's look at these various forms of data the add function can handle.

Firstly, they can handle single statements:

description |> RDF.Description.add {EX.S, EX.p, EX.O}
graph       |> RDF.Graph.add {EX.S, EX.p, EX.O}
dataset     |> RDF.Dataset.add {EX.S, EX.p, EX.O, EX.Graph}

When the subject of a statement doesn't match the subject of the description, RDF.Description.add ignores it and is a no-op.

RDF.Description.add also accepts a property-value pair as a tuple.

RDF.Description.new(EX.S, {EX.p, EX.O1})
|> RDF.Description.add {EX.p, EX.O2}

In general, the object position of a statement can be a list of values, which will be interpreted as multiple statements with the same subject and predicate. So the former could be written more shortly:

RDF.Description.new(EX.S, {EX.p, [EX.O1, EX.O2]})

Multiple statements with different subject and/or predicate can be given as a list of statements, where everything said before on single statements applies to the individual statements of these lists:

description |> RDF.Description.add [{EX.p1, EX.O}, {EX.p2, [EX.O1, EX.O2]}
graph       |> RDF.Graph.add [{EX.S1, EX.p1, EX.o1}, {EX.S2, EX.p2, EX.o2}]
dataset     |> RDF.Dataset.add [{EX.S, EX.p, EX.o}, {EX.S, EX.p, EX.o, EX.Graph}

A RDF.Description can be added to any of the three data structures:

input = RDF.Description.new(EX.S, {EX.p, EX.O1})
description |> RDF.Description.add input
graph       |> RDF.Graph.add input
dataset     |> RDF.Dataset.add input

Note that, unlike mismatches in the subjects of directly given statements, RDF.Description.add ignores the subject of a given RDF.Description and just adds the property-value pairs of the given description, because this is a common use case when merging the descriptions of differently named resources (eg. because they are linked via owl:sameAs).

RDF.Graph.add and RDF.Dataset.add can also add other graphs and RDF.Dataset.add can add the contents of another dataset.

RDF.Dataset.add is also special, in that it allows to overwrite the explicit or implicit graph context of the input data and redirect the input into another graph. For example, the following examples all add the given statements to the EX.Other graph:

RDF.Dataset.new
|> RDF.Dataset.add({EX.S, EX.p, EX.O}, EX.Other)
|> RDF.Dataset.add[{EX.S, EX.p, EX.O1, nil}, {EX.S, EX.p, EX.O2, EX.Graph}], EX.Other)
|> RDF.Dataset.add(RDF.Graph.new(EX.Graph, {EX.S, EX.p, EX.O3}), EX.Other)

Unlike the add function, which always returns the same data structure as the data structure to which the addition happens, which possible means ignoring some input statements (eg. when the subject of a statement doesn't match the description subject) or reinterpreting some parts of the input statement (eg. ignoring the subject of another description), the merge function of the RDF.Data protocol implemented by all three data structures will always add all of the input and possibly creates another type of data structure. For example, merging two RDF.Descriptions with different subjects results in a RDF.Graph. Or adding a quad to a RDF.Graph with a different name than the quad’s graph context results in a RDF.Dataset.

RDF.Description.new(EX.S1, {EX.p, EX.O}) 
|> RDF.Data.merge(RDF.Description.new(EX.S2, {EX.p, EX.O})) # returns an unnamed RDF.Graph
|> RDF.Data.merge(RDF.Graph.new(EX.Graph, {EX.S2, EX.p, EX.O2})) # returns a RDF.Dataset

Statements added with put overwrite all existing statements with the same subject and predicate.

iex> RDF.Graph.new({EX.S1, EX.p, EX.O1}) |> RDF.Graph.put({EX.S1, EX.p, EX.O2})
#RDF.Graph{name: nil
     ~I<http://example.com/S1>
         ~I<http://example.com/p>
             ~I<http://example.com/O2>}

It is available on all three data structures and can handle all of the input data types as their add counterpart.

Accessing the content of RDF data structures

All three RDF data structures implement the Enumerable protocol over the set of contained statements. As a set of triples in the case of RDF.Description and RDF.Graph and as a set of quads in case of RDF.Dataset. This means you can use all Enum functions over the contained statements as tuples.

RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
|> Enum.each(&IO.inspect/1)

The RDF.Data protocol offers various functions to access the contents of RDF data structures:

• RDF.Data.subjects/1 returns the set of all subject resources.
• RDF.Data.predicates/1 returns the set of all used properties.
• RDF.Data.objects/1 returns the set of all resources on the object position of statements. Note: Literals not included.
• RDF.Data.resources/1 returns the set of all used resources at any position in the contained RDF statements.
• RDF.Data.description/2 returns all statements from a data structure about the given resource as a RDF.Description. It will be empty if no such statements exist. On a RDF.Dataset it will aggregate the statements about the resource from all graphs.
• RDF.Data.descriptions/1 returns all RDF.Descriptions within a data structure (possible aggregated in the case of a RDF.Dataset)
• RDF.Data.statements/1 returns a list of all contained RDF statements.

The get functions return individual elements of a RDF data structure:

• RDF.Description.get returns the list of all object values for a given property.
• RDF.Graph.get returns the RDF.Description for a given subject resource.
• RDF.Dataset.get returns the RDF.Graph with the given graph name.

All of these get functions return nil or the optionally given default value, when the given element can not be found.

iex> RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
...> |> RDF.Description.get(EX.p)
[~I<http://example.com/O1>, ~I<http://example.com/O2>]

iex> RDF.Graph.new({EX.S1, EX.p, [EX.O1, EX.O2]})
...> |> RDF.Graph.get(EX.p2, :not_found)
:not_found

You can get a single object value for a given predicate in a RDF.Description with the RDF.Description.first/2 function:

iex> RDF.Description.new(EX.S1, {EX.p, EX.O1})
...> |> RDF.Description.first(EX.p)
~I<http://example.com/O1>

Since all three RDF data structures implement the Access behaviour, you can also use data[key] syntax, which basically just calls the resp. get function.

iex> description[EX.p]
[~I<http://example.com/O1>, ~I<http://example.com/O2>]

iex> graph[EX.p2] 
nil

Also, the familiar fetch function of the Access behaviour, as a variant of get which returns ok tuples, is available on all RDF data structures.

iex> RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
...> |> RDF.Description.fetch(EX.p)
{:ok, [~I<http://example.com/O1>, ~I<http://example.com/O2>]}

iex> RDF.Graph.new({EX.S1, EX.p, [EX.O1, EX.O2]})
...> |> RDF.Graph.fetch(EX.p2)
:error

RDF.Dataset also provides the following functions to access individual graphs:

• RDF.Dataset.graphs returns the list of all the graphs of the dataset
• RDF.Dataset.default_graph returns the default graph of the dataset
• RDF.Dataset.graph returns the graph of the dataset with the given name

Deleting statements

Statements can be deleted in two slightly different ways. One way is to use the delete function of the resp. data structure. It accepts all the supported ways for specifying collections of statements supported by the resp. add counterparts and removes the found triples.

iex> RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
...> |> RDF.Description.delete({EX.S1, EX.p, EX.O1})
#RDF.Description{subject: ~I<http://example.com/S1>
     ~I<http://example.com/p>
         ~I<http://example.com/O2>}

Another way to delete statements is the delete function of the RDF.Data protocol. The only difference to delete functions on the data structures directly is how it handles the deletion of a RDF.Description from another RDF.Description or RDF.Graph from another RDF.Graph. While the dedicated RDF data structure function ignores the description subject or graph name and removes the statements even when they don't match, RDF.Data.delete only deletes when the description’s subject resp. graph name matches.

iex> RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
...> |> RDF.Description.delete(RDF.Description.new(EX.S2, {EX.p, EX.O1}))
#RDF.Description{subject: ~I<http://example.com/S1>
     ~I<http://example.com/p>
         ~I<http://example.com/O2>}

iex> RDF.Description.new(EX.S1, {EX.p, [EX.O1, EX.O2]})
...> |> RDF.Data.delete(RDF.Description.new(EX.S2, {EX.p, EX.O1}))
#RDF.Description{subject: ~I<http://example.com/S1>
     ~I<http://example.com/p>
         ~I<http://example.com/O1>
         ~I<http://example.com/O2>}

Beyond that, there is

• RDF.Description.delete_predicates which deletes all statements with the given property from a RDF.Description,
• RDF.Graph.delete_subjects which deletes all statements with the given subject resource from a RDF.Graph,
• RDF.Dataset.delete_graph which deletes all graphs with the given graph name from a RDF.Dataset and
• RDF.Dataset.delete_default_graph which deletes the default graph of a RDF.Dataset.

Lists

RDF lists can be represented with the RDF.List structure.

An existing RDF.List in a given graph can be created with RDF.List.new or its alias RDF.list, passing it the head node of a list and the graph containing the statements constituting the list.

graph = 
  Graph.new(
       ~B<Foo>
       |> RDF.first(1)
       |> RDF.rest(EX.Foo))
    |> Graph.add(
       EX.Foo
       |> RDF.first(2)
       |> RDF.rest(RDF.nil))
    )

list = RDF.List.new(~B<Foo>, graph)

If the given head node does not refer to a well-formed RDF list in the graph, nil is returned.

An entirely new RDF.List can be created with RDF.List.from or RDF.list and a native Elixir list or an Elixir Enumerable with values of all types that are allowed for objects of statements (including nested lists).

list = RDF.list(["foo", EX.bar, ~B<bar>, [1, 2, 3]])

If you want to add the graph statements to an existing graph, you can do that via the graph option.

existing_graph = RDF.Graph.new({EX.S, EX.p, EX.O})
RDF.list([1, 2, 3], graph: existing_graph)

The head option also allows to specify a custom node for the head of the list.

The function RDF.List.values/1 allows to get the values of a RDF list (including nested lists) as a native Elixir list.

iex> RDF.list(["foo", EX.Bar, ~B<bar>, [1, 2]]) |> RDF.List.values
[~L"foo", ~I<http://www.example.com/ns/Bar>, ~B<bar>,
 [%RDF.Literal{value: 1, datatype: ~I<http://www.w3.org/2001/XMLSchema#integer>},
  %RDF.Literal{value: 2, datatype: ~I<http://www.w3.org/2001/XMLSchema#integer>}]]

Serializations

The RDF.ex package comes with implementations of the N-Triples, N-Quads and Turtle serialization formats. Formats which require additional dependencies should be implemented in separate Hex packages. The JSON-LD format for example is available with the JSON-LD.ex package.

RDF graphs and datasets can be read and written to files or strings in a RDF serialization format using the read_file, read_string and write_file, write_string functions of the resp. RDF.Serialization.Format module.

{:ok, graph} = RDF.NTriples.read_file("/path/to/some_file.nt")
{:ok, nquad_string} = RDF.NQuads.write_string(graph)

All of the read and write functions are also available in bang variants which will fail in error cases.

All of these read_* and write_* functions are also available in the top-level RDF module, where the serialization format can be specified in various ways, either by providing the format name via the format option, or via the media_type option.

{:ok, graph} = RDF.read_file("/path/to/some_file", format: :turtle)
json_ld_string = RDF.write_string!(graph, media_type: "application/ld+json")

Note: The later command requires the json_ld package to be defined as a dependency in the Mixfile of your application.

The file read and write functions are also able to infer the format from the file extension of the given filename.

RDF.read_file!("/path/to/some_file.ttl")
|> RDF.write_file!("/path/to/some_file.jsonld")

For serialization formats which support it, you can provide a base IRI on the read functions with the base option. You can also provide a default base IRI in your application configuration, which will be used when no base option is given.

config :rdf,
  default_base_iri: "http://my_app.example/"

Caveats

The Date and DateTime modules of Elixir versions < 1.7.2 don't handle negative years properly. In case you're data contains negative years in xsd:date or xsd:dateTime literals, you'll have to upgrade to a newer Elixir version.

Getting help

• Documentation
• Google Group

TODO

There's still much to do for a complete RDF ecosystem for Elixir, which means there are plenty of opportunities for you to contribute. Here are some suggestions:

• more serialization formats
  • RDFa
  • RDF-XML
  • N3
  • et al.
• more XSD datatypes
• improve documentation

Contributing

see CONTRIBUTING for details.

License and Copyright

(c) 2017-2018 Marcel Otto. MIT Licensed, see LICENSE for details.