Creates a new resource in the container.
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.
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.
Deletes a resource.
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.
Retrieves a representation of a resource.
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 container has any non-auxiliary resources.
Check if a resource exists in this ResourceSet.
Checks if the given metadata represents a (potential) container, based on the metadata.
Metadata of the (new) resource.
Verifies if this is the metadata of a root storage container.
Sets or updates the representation of a resource, creating a new resource and intermediary containers as needed.
Removes all generated data from metadata to prevent it from being stored permanently.
Deletes the given array of auxiliary identifiers. Does not throw an error if something goes wrong.
Sets or replaces the representation of a resource, creating a new resource and intermediary containers as needed.
Updates the last modified date of the given container
Verify if the given metadata matches the conditions.
Verify if the given identifier matches the stored base.
Validates if the slug and headers are valid. Errors if slug exists, ends on slash, but ContainerType Link header is NOT present
Is the slug supposed to represent a container?
Is the requested slug (if any).
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?
If the resource already exists.
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.