# 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" ; . }