Resource URIs are stored internally in LAKEsuperior as domain-agnostic URIs
with the scheme info:fcres<resource UID>
. This allows resources to be
portable across systems. E.g. a resource with an internal URI of
info:fcres/a/b/c
, when accessed via the http://localhost:8000/ldp
endpoint, will be found at http://localhost:8000/ldp/a/b/c
.
The resource UID making up the looks like a UNIX
filesystem path, i.e. it always starts with a forward slash and can be made up
of multiple segments separated by slashes. E.g. /
is the root node UID,
/a
is a resource UID just below root. their internal URIs are info:fcres/
and info:fcres/a
respectively.
In the Python API, the UID and internal URI of an LDP resource can be accessed
via the uid
and uri
properties respectively:
>>> import lakesuperior.env_setup
>>> from lakesuperior.api import resource
>>> rsrc = resource.get('/a/b/c')
>>> rsrc.uid
/a/b/c
>>> rsrc.uri
rdflib.terms.URIRef('info:fcres/a/b/c')
One of the key concepts in LAKEsuperior is the store layout. This is a module built with a specific purpose in mind, i.e. allowing fine-grained recording of provenance metadata while providing reasonable performance.
Store layout modules could be replaceable (work needs to be done to develop an interface to allow that). The default (and only at the moment) layout shipped with LAKEsuperior is the resource-centric layout. This layout implements a so-called graph-per-aspect pattern which stores different sets of statements about a resource in separate named graphs.
The named graphs used for each resource are:
info:fcsystem/graph/admin<resource UID>
) which stores
administrative metadata, mostly server-managed triples such as LDP types,
system create/update timestamps and agents, etc.info:fcsystem/graph/structure<resource UID>
) reserved for
containment triples. The reason
for this separation is purely convenience, since it makes it easy to retrieve
all the properties of a large container without its child references.info:fcsystem/graph/userdata/_main<resource UID>
).Each of these graphs can be annotated with provenance metadata. The layout decides which triples go in which graph based on the predicate or RDF type contained in the triple. Adding logic to support arbitrary named graphs based e.g. on user agent, or to add more provenance information, should be relatively simple.