🚧Solid client protocol
This page define a Solid client-to-client standard to build DFC compliant Solid applications.
Conformance
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Introduction
This section is non-normative.
Terminology
This section is non-normative.
The Solid Client Protocol specification defines the following terms. These terms are referenced throughout this specification.
application
Refers to an application that follows this client protocol.
client protocol
The DFC Solid Cient Protocol refers to this specification: the document you are currently reading.
Namespaces
dfc-f
TBD.
Data Food Consortium facets taxonomy.
dfc-m
TBD.
Data Food Consortium measures taxonomy.
dfc-pt
TBD.
DFC product types SKOS taxonomy.
dfc-t
TBD.
Data Food Consortium technical ontology.
Configuration
An application SHOULD save its settings in the user's preferences document.
In the user's preferences document, an application COULD find a link to one or several DFC dedicated solid:TypeIndex
containing only registrations related to DFC resources. These type indexes can be used to reduce the parsing of general type indexes which can contain a huge amount of registrations. When existing, these DFC specific type indexes MUST be indicated with triples of the form ?preference a dfc-t:typeIndex; solid:instance ?typeIndexFile.
as shown in the following example:
Storage and resources
Resources MUST be expressed using the DFC ontology version 1.8 or later and taxonomies. Arities defined by the DFC ontology MUST be respected. An example dataset could be found at https://github.com/datafoodconsortium/solid-dataset-example.
An application MUST let users to choose where they want to store data on their POD(s). Resources location MUST be defined in one or several solid:TypeIndex
. Each used DFC resource or container MUST be registered in these type indexes. See the TypeIndex section for more details.
When users don't know or don't want to choose where to save their data, an application SHOULD propose a default location like /datafoodconsortium/
as the root LDP container for DFC data. Following the tree structure defined in the example dataset is RECOMMENDED.
Indexing
Applications MUST fill and keep updated several indexes in order to allow quick searching of piece of information. All the following indexes MUST be supported by applications
and MUST be updated whenever a DFC data is created, edited or deleted.
The application who creates, edit or delete data MUST update all the appropriate indexes. While updating indexes is its responsibility, an application can delegate that work to some agent(s).
Orders
Indexing the year and month of orders
This index MUST be registered in one or several type indexes for the class dfc-t:OrderIndex
. All dfc-b:Order
SHOULD be indexed.
Such an index can be used to retrieve orders for a certain period of time like a year or a month of a year.
Persons
Indexing the first letter of the family name
This index MUST be registered in one or several type indexes for the class dfc-t:PersonIndex
. All dfc-b:Person
SHOULD be indexed. It MUST contain a registration for each first symbol used in the family name of all the persons.
Such an index can be used to display quickly a person when the user types the beginning of a family name.
Product types
Indexing the product types contained in a catalog
This index MUST be registered in one or several type indexes for the class dfc-t:ProductTypeIndex
. All dfc-b:CatalogItem
SHOULD be indexed. It MUST contain registrations mentioning product type.
This index MUST contain registrations for inferred product types. For instance, if a registration is created for the dfc-pt:heirloom-tomato
product type, a registration MUST also be created for both the dfc-pt:tomato
and the dfc-pt:vegetable
product types.
Such an index can be used to quickly find all the catalog items referencing a product of a given type. For instance, it can be used to find all the tomatoes listed in a catalog.
TypeIndex
Applications MUST advertise their DFC resources, containers and indexes in one or several solid:TypeIndex
.
Paging and sorting
This section defines how data is paged and sorted.
Access rights
By default all resources are only accessible to the owner of the POD (private).
When a new dfc-b:CatalogItem
is created, it inherits the access rights of its parent dfc-b:Catalog
.
Notifications
When data is created, changed or deleted, applications MUST send a ActivityPub notification.
Error codes
The following table lists the different errors that can occur in applications. When an error happens, applications SHOULD display the error code and the "user description". Applications SHOULD also display the "technical description" if any. User descriptions are intended to provide clear and easy to understand reason(s) about what caused the error so users may find a way to solve the issue by themselves.
404
Profile document not found.
Invalid profile document.
404
Type indexes not found.
Invalid Type Index.
Revisions and automated backups
Should we be able to automatically backup the storage?
Encryption
Appendixes
Last updated