We define a grouping of RDF triples based on the URL fragment:

Fragment Graph

Given a base subject \(s\) that is an IRI without a URL fragment part, the Fragment Graph of the base subject \(s\) is the union of:

• All triples of form \((s,p,o)\) where \(o\) is either an IRI or a literal
• All triples of form \((f,p,o)\) where \(f\) is an IRI that is a fragment of the base subject \(s\) and \(o\) is either an IRI or a literal

For example http://example.com/something does not have a fragment part and could be the base subject of a Fragment Graph. https://example.com/something#that-thing is a fragment of http://example.com/something and would be included in its Fragment Graph.

In the example above there are three Fragment Graphs with base subjects:

• https:/test.example/notes/1
• https://test.example/alice
• https://circus.show/performance-in-funky-town

Note that https://test.example/images/1.jpg does not have a fragment part but is never in subject position.

This grouping reflects how RDF content is commonly published on HTTP servers. A single request to the base subject will return the base subject and all fragments.

The concept of Fragment Graph is very similar to the Minimum Self-Contained Graph (MSG) introduced by Tummarello et. al. [Tummarello_2005]. However we follow URL fragments instead of blank nodes. Blank nodes are not permitted in an Fragment Graph.

Blank Nodes are special nodes that act like existential variables in mathematical logic [Mallea_2011]. In practice they tend to make things complicated [Cyganiak_2011,Carroll_2003] and we follow previous suggestions to not use blank nodes [Bizer_2007].

In order to use existing RDF data that does contain blank nodes we use Skolemization - we replace blank nodes with fresh IRIs. We suggest replacing blank nodes with random UUID URNs [Leach_2005] that can be readily generated locally.

The problem is that existing content that contains blank nodes will not receive the same identifier as replacing blank nodes is not a deterministic process. See the section on caching existing RDF data on how this can be handled.

The proposed serialization of a Fragment Graph has 5 different forms:

rdf

Top-level form identifying RDF statement. Elements of an rdf-form are s-forms or fs-forms. There is only one rdf form per representation of Fragment Graph.

s

A statement form represents a triple with the base subject of the Fragment Graph as subject. It contains exactly two elements:

• The predicate which may be an IRI as string or a f-form.
• The object which may be an IRI, a f-form or a l-form.

l

A literal form represents a literal node. It contains either two or three elements:

• The canonical lexical form [Peterson_2012] of the value.
• The datatype IRI
• If an only if the datatype IRI is http://www.w3.org/1999/02/22-rdf-syntax-ns#langString a third element is present which is the language tag.

f

A fragment reference form represents an IRI to a fragment. It contains exactly one element which is the fragment identifier.

fs

A fragment-statement form represents a triple with a fragment as subject. It contains exactly three elements:

• The fragment identifier
• The predicate which may be an IRI as string or a f-form.
• The object which may be an IRI, a f-form or a l-form.

Given a base subject \(s\), every s and fs form can be translated to a RDF triple. The set of RDF triples in the rdf form is the Fragment Graph for \(s\).

The canonical representation of an rdf form is the UTF-8 encoded Canonical S-Expression [Rivest_1997] where the s and fs forms in the rdf form are sorted based on their (binary) Canonical S-expression representation.

The Canonical S-expression is a binary format. Strings and symbols (as strings) are encoded as sequences of UTF-8 bytes. Every sequence of bytes is pre-pended with the length of the sequence and a colon (this encoding is called Netstrings [Bernstein_1997]). Lists are encoded with surrounding parenthesis.

For readability purposes we will show the string representation in the following examples and not the UTF-8 encoded binary representation which is the canonical representation.

The string “Hello World” is encoded as following:

11:Hello World

An s form is encoded as following:

(1:s43:https://www.w3.org/ns/activitystreams#image(1:f5:image))

Canonical S-Expressions are very easy to parse and for every S-Expression there is an uniquely defined Canonical S-Expression. The representation is not optimized for being pretty or human readable.

The Canonical S-expression of the Frament Graph for https://test.example/notes/1 is (as UTF-8 string):

(3:rdf(1:s10:as:content(1:l37:The clowns just went trough the loop!53:http://www.w3.org/1999/02/22-rdf-syntax-ns#langString2:en))(1:s10:as:context45:https://circus.show/performance-in-funky-town)(1:s15:as:attributedTo26:https://test.example/alice)(1:s8:as:image34:https://test.example/notes/1#image)(1:s8:rdf:type7:as:Note)(2:fs5:image6:as:url33:https://test.example/images/1.jpg)(2:fs5:image8:rdf:type8:as:Image))

To compute the Canonical S-Expression it is necessary to sort the Canonical S-expressions of the s and fs forms. Note that sorting is done on the UTF-8 encoded sequence of bytes.

The presented serialization is optimized for easy parsing, having a unique canonical representation and being usable for content-addressable RDF.

To illustrate the advantage of an optimized serialization format consider the Turtle [Becket_2014] serialization of the Fragment Graph for the note:

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

<>
   a as:Note ;
   as:attributedTo <https://test.example/alice> ;
   as:content "The clowns just went trough the loop!"@en ;
   as:image <https://test.example/notes/1#image> ;
   as:context <https://circus.show/performance-in-funky-town> .

<#image>
    a as:Image ;
    as:url <https://test.example/images/1.jpg> .

The serialization is readable and fairly easy to parse and understand for humans. Note also that the base subject IRI is not part of the serialization. When parsing the Turtle document it needs to be specified as “base IRI”.

However this is not the only representation of the same set of statements: The choice of prefixes is arbitrary, the nesting of statements and the order of statements can be changed.

It is possible to clearly define rules on how to do make these choices and define a canonical Turtle representation for a set of RDF statements [Carroll_2003,Longley_2019]. However, this is complicated. Furthermore existing implementations of Turtle encoders can not be used as they usually do not provide fine control for exactly tuning how the statements are encoded.

We believe that the serialization based on Canonical S-Expressions is simpler, efficient and can be straight-forwardly implemented.

An S-Expression based serialization of RDF has previously been proposed [Prodromou_2006].

Plenty of content is already published using location-addressed identifiers (URLs). Such content can be grouped appropriately and made content-addressable (as shown with the ActivityStreams note).

However, it makes sense to keep track of the original source of the content. We propose doing this by adding some more information describing how and when the content was cached.

Consider following vocabulary for describing cached content that builds on the Dublin Core ProvenanceStatement:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix voaf: <http://purl.org/vocommons/voaf#> .

<>
    dcterms:title "Cache Vocabulary"@en ;
    a voaf:Vocabulary .

<#Cache>
    a rdfs:Class ;
    rdfs:label "Cache" ;
    rdfs:subClassOf dcterms:ProvenanceStatement .

<#creator>
    a rdf:Property ;
    rdfs:label "Creator" ;
    rdfs:comment "The entity that created the cache" ;
    rdfs:subPropertyOf dcterms:creator .

<#cachedAt>
    a rdf:Property ;
    rdfs:label "Date Cached" ;
    rdfs:subPropertyOf dcterms:created .

<#source>
    a rdf:Property ;
    rdfs:label "Source" ;
    rdfs:comment "The source of the cache." ;
    rdfs:subPropertyOf dcterms:source .

The URN of the vocabulary is:

urn:erisx:AAAABDK5YTJKPC4O4AHTEDQBRLZXYCZO6E2NW6E5GCY4SRAQ5FLHI4BRZTILMJMLRA6VBDJ5XK7NGYSBJV47GKZTZXHTPV73THA2C4FLQJMA

Note that we used the ERIS encoding to compute an identifier instead of simply computing the hash.

We can add cache information to existing RDF data:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <https://schema.org/> .
@prefix as: <https://www.w3.org/ns/activitystreams> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix cache: <urn:erisx:AAAABDK5YTJKPC4O4AHTEDQBRLZXYCZO6E2NW6E5GCY4SRAQ5FLHI4BRZTILMJMLRA6VBDJ5XK7NGYSBJV47GKZTZXHTPV73THA2C4FLQJMA#> .

<>
   a as:Note ;
   as:attributedTo <https://test.example/alice> ;
   as:content "The clowns just went trough the loop!"@en ;
   as:image <https://test.example/notes/1#image> ;
   as:context <https://circus.show/performance-in-funky-town> ;
   dcterms:provenance <#cache> .

<#image>
    a as:Image ;
    as:url <https://test.example/images/1.jpg> .

<#cache>
    a cache:Cache ;
    cache:created "2020-06-07"^^<http://www.w3.org/2001/XMLSchema#date> ;
    cache:creator <https://inqlab.net/pukkamustard> ;
    cache:source <https://test.example/note/1> .

We can compute the hash of this Fragment Graph to get a URN:

urn:blake2b:L4X4DH7Q3UD5ZQIVES7CNNPL7KUPCIQU43SVX56G4RDPPG4GVJJQ

Note that the URN has changed because we added the information about how the content was cached. The URN will change again when we cache the content tomorrow. This reflects the fact that the original content (at https://test.example/note/1) can change at any time and an immutable content-addressable version of it is only a cache that may be outdated.

Considering the fact that location-addressed content can never be brought into a single canonical form deterministically (it depends at least on when content is accessed) makes the problem that RDF data containing blank nodes cannot be deterministically skolemized (see On Blank Nodes) not so bad.

Location-addressed content that is made content-addressable is always a view of the original data at a certain time from a certain perspective - a cached version. Adding this information to the cached version seems to be a good idea.

The scheme presented can also be used for content-addressable ontologies (definition of classes and properties).

For example the Lingvoj Ontology defines classes and properties to describe languages and their use.

The entire vocabulary is a Fragment Graph (with base subject https://lingvoj.org/ontology). We can compute the hash from the canonical representation to get a URN that identifies the vocabulary:

urn:blake2b:AKG576SYQJAY7RY3EGZ3KZQG37NDTCJMZTH7IT4YWXYTW36WVNWQ

This URN can be used instead of the URL http://www.lingvoj.org/ontology:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix lingvoj: <urn:blake2b:AKG576SYQJAY7RY3EGZ3KZQG37NDTCJMZTH7IT4YWXYTW36WVNWQ> .
@prefix as: <https://www.w3.org/ns/activitystreams> .

<https://test.example/alice>
    a as:Person ;
    lingvoj:nativeLanguage <http://www.wikidata.org/entity/Q143> .

We have implemented a JavaScript web application demonstrating how existing RDF content can be made content-addressable: Encoding for Robust Immutable Storage (ERIS).

The example uses ERIS, an encoding of content that improves on naive content-addressing.

The demo also shows how existing decentralized networks (e.g. IPFS) can be used to robustly store content-addressed RDF.

Proving authenticity of content-addressed RDF reduces to signing the identifier. We propose a vocabulary for describing Ed25519 keys and signatures that can be used to sign Fragment Graphs.