Solid client protocol
This page define a Solid client-to-client standard to build DFC compliant Solid applications.
Last updated
Was this helpful?
This page define a Solid client-to-client standard to build DFC compliant Solid applications.
Last updated
Was this helpful?
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.
This section is non-normative.
This section is non-normative.
The Solid Client Protocol specification defines the following terms. These terms are referenced throughout this specification.
Refers to an application that follows this .
The DFC Solid Cient Protocol refers to this specification: the document you are currently reading.
solid
Solid Terms.
dfc-b
Data Food Consortium business ontology.
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.
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.
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.
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.
This section defines how data is paged and sorted.
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
.
When data is created, changed or deleted, applications MUST send a ActivityPub notification.
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.
Should we be able to automatically backup the storage?
An SHOULD save its settings in the .
In the , an 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:
Resources MUST be expressed using the version 1.8 or later and taxonomies. Arities defined by the MUST be respected. An example dataset could be found at .
An 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 for more details.
When users don't know or don't want to choose where to save their data, an SHOULD propose a default location like /datafoodconsortium/
as the root LDP container for DFC data. Following the tree structure defined in the is RECOMMENDED.
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 and MUST be updated whenever a DFC data is created, edited or deleted.
The who creates, edit or delete data MUST update all the appropriate indexes. While updating indexes is its responsibility, an can delegate that work to some agent(s).
MUST advertise their DFC resources, containers and indexes in one or several solid:TypeIndex
.