Clean http Slug to be compatible with the server. Makes sure there are no unwanted characters e.g.: cleanslug('&%26') returns '%26%26'
the slug to clean
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.
Metadata of the parent container.
Generates a new URI for a resource in the given container, potentially using the given slug.
Solid, §5.3: "Servers MUST allow creating new resources with a POST request to URI path ending /.
Servers MUST create a resource with URI path ending /{id} in container /.
Servers MUST create a container with URI path ending /{id}/ in container / for requests
including the HTTP Link header with rel="type" targeting a valid LDP container type."
https://solid.github.io/specification/protocol#writing-resources
Parent container of the new URI.
Does the new URI represent a container?
Slug to use for the new URI.
Extracts the identifiers of all auxiliary resources contained within the given metadata.
Returns the metadata matching the identifier, ignoring the presence of a trailing slash or not.
Solid, §3.1: "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." https://solid.github.io/specification/protocol#uri-slash-semantics
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 (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.
Deletes the given array of auxiliary identifiers. Does not throw an error if something goes wrong.
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?
Identifiers of resources that were possibly modified.
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.