# Resource-centric layout. This separates resources into separate named
# graphs and follows the graph-per-resource pattern
# (http://patterns.dataincubator.org/book/graph-per-resource.html). This aligns
# quite well with the resource-centrism of LDP and of the SPARQL Graph Store
# Protocol (https://www.w3.org/TR/sparql11-http-rdf-update/) which should be
# used by the software implementation to minimize data structure translation.
#
# A graph identified by the resource UID is the current state of that resource.
# Other resources (graphs) can be present representing various previous states
# of the resource and are identified by the resource UUID with a `:` (colon)
# and the version UID appended.
# E.g. a resource with a UID of `a/b/c` will be internally stored within a
# named graph `info:fcstate/a/b/c`; the subject will be `info:fcres/a/b/c`;
# a previous version could be `info:fcstate/a/b/c:version1` and the publicly
# exposed URL could be http://webroot.org/ldp/a/b/c`.
#
# The relationships between resources and thir versions and other metadata not
# meant to be directly exposed by the LDP API are in one "metadata" graph.
PREFIX dc:
PREFIX fcrepo:
PREFIX fcsystem:
PREFIX foaf:
PREFIX ldp:
PREFIX ns:
PREFIX xsd:
# System root. It cannot be deleted.
fcsystem:__root__ {
a
fcrepo:RepositoryRoot , fcrepo:Resource , fcrepo:Container ,
ldp:Container , ldp:BasicContainer , ldp:RDFSource ;
.
}
# Metadata graphs. Each of these is a "companion" of the content graph.
# All triples that describe the stored resource state go here. Also triples
# used by the application business logic are stored here.
# These are a convenient way to get resource metadata (e.g. with a HEAD
# request) without loading large graphs, e.g. ones with many children
# or many user-provided properties.
{
a fcsystem:CurrentState ;
# This may be redundant if we use naming conventions, but still good LD practice.
fcsystem:stateOf ;
fcsystem:hasVersion
, , ;
.
a fcrepo:Resource ;
# Timestamps are simplified for readability.
fcrepo:created "2017-11-23"^^xsd:date ;
fcrepo:lastModified "2017-11-27"^^xsd:date ;
}
{
fcsystem:stateOf ;
fcrepo:created "2017-11-24"^^xsd:date ;
.
a fcrepo:Version ;
fcrepo:created "2017-11-23"^^xsd:date ;
fcrepo:lastModified "2017-11-23"^^xsd:date ;
.
}
{
fcsystem:stateOf ;
a fcrepo:Version ;
fcrepo:created "2017-11-25"^^xsd:date ;
.
a fcrepo:Version ;
fcrepo:created "2017-11-23"^^xsd:date ;
fcrepo:lastModified "2017-11-24"^^xsd:date ;
.
}
{
fcsystem:stateOf ;
a fcrepo:Version ;
fcrepo:created "2017-11-26"^^xsd:date ;
.
a fcrepo:Version ;
fcrepo:created "2017-11-23"^^xsd:date ;
fcrepo:lastModified "2017-11-25"^^xsd:date ;
.
}
# Pairtree information not passed to the client but used to mimic
# hierarchical structures.
{
fcsystem:stateOf ;
.
a ldp:Container , ldp:BasicContainer , ldp:Resource , ldp:RDFSSource ;
a fcrepo:Pairtree ;
# fcsystem:contains only applies to Pairtrees and is used to mimic path
# hierarchies.
fcsystem:contains ;
ldp:contains ;
.
}
{
fcsystem:currentStateOf ;
.
a fcrepo:Pairtree ;
fcsystem:contains ;
.
}
# Resource graph. These statements are user-provided and not used for any
# application business logic.
# Note that "fragments", i.e. hash URIs, are stored within the same graph.
{
a ns:Book ;
fcrepo:hasParent ;
dc:title "Moby Dick" ;
dc:creator "Herman Melville" ;
dc:subject "Fishing" ;
.
a ns:BookChapter ;
dc:title "Loomings." ;
.
a ns:BookChapter ;
dc:title "The Carpet-Bag." ;
.
}
# Previous states (versions) of a resource.
{
a ns:Book ;
fcrepo:hasParent ;
dc:title "Moby Dick" ;
.
}
{
a ns:Book ;
fcrepo:hasParent ;
dc:title "Moby Dick" ;
dc:creator "Herman Melvil" ;
.
}
{
a ns:Book ;
fcrepo:hasParent ;
dc:title "Moby Dick" ;
dc:creator "Herman Melville" ;
.
}