Create containers starting from the root until the given identifier corresponds to an existing container. Will throw errors if the identifier of the last existing "container" corresponds to an existing document.
Identifier of the container which will need to exist.
Generate a valid URI to store a new Resource in the given container. URI will be based on the slug header if there is one and is guaranteed to not exist yet.
Identifier of the target container.
Metadata of the new resource.
Optional metadata of the parent container.
Generates a new URI for a resource in the given container, potentially using the given slug.
Parent container of the new URI.
Does the new URI represent a container?
Slug to use for the new URI.
Generates the minimal representation for an empty container.
Identifier of this new container.
Returns the metadata matching the identifier, ignoring the presence of a trailing slash or not. This is used to support the following part of the spec: "If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource."
First the identifier gets requested and if no result is found the identifier with differing trailing slash is requested.
Identifier that needs to be checked.
Returns the result of getNormalizedMetadata or undefined if a 404 error is thrown.
Verify if the incoming data for a container is valid (RDF and no containment triples). Adds the container data to its metadata afterwards.
Container representation.
Checks in a list of types if any of them match a Container type.
Checks if the given metadata represents a container, purely based on metadata type triples. Since type metadata always gets generated when writing resources this should never fail on stored resources.
Metadata to check.
Checks if the given metadata represents a (potential) container, both based on the metadata and the URI.
Metadata of the (new) resource.
Suffix of the URI. Can be the full URI, but only the last part is required.
Verifies if this is the metadata of a root storage container.
Verify if the given identifier matches the stored base.
Write the given resource to the DataAccessor. Metadata will be updated with necessary triples.
In case of containers handleContainerData will be used to verify the data.
Identifier of the resource.
Corresponding Representation.
Is the incoming resource a container?
Should parent containers (potentially) be created?
ResourceStore which uses a DataAccessor for backend access.
The DataAccessor interface provides elementary store operations such as read and write. This DataAccessorBasedStore uses those elementary store operations to implement the more high-level ResourceStore contact, abstracting all common functionality such that new stores can be added by implementing the more simple DataAccessor contract. DataAccessorBasedStore thereby provides behaviours for reuse across different stores, such as:
Currently "metadata" is seen as something that is not directly accessible. That means that a consumer can't write directly to the metadata of a resource, only indirectly through headers. (Except for containers where data and metadata overlap).
The one thing this store does not take care of (yet?) are containment triples for containers
Work has been done to minimize the number of required calls to the DataAccessor, but the main disadvantage is that sometimes multiple calls are required where a specific store might only need one.