Solid GSP

1. Terminology

1.1. Namespaces

Prefix	Namespace	Description
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	[rdf-schema]
foaf	http://xmlns.com/foaf/0.1/	[foaf]
dfc-b	https://github.com/datafoodconsortium/ontology/releases/latest/download/DFC_BusinessOntology.owl#	Data Food Consortium ontology

2. GSP

A Solid Goods and/or Services Provider (GSP) is a object in a Solid storage which holds data about an entity that provides goods and/or services.

A Solid GSP is all built inside a single folder (LDP Container) in a Solid storage. Let us call the URI of that folder -- less its final '/' -- $ROOT. It could be say, https://alice.example.org/myBusiness/. Developers must never make assumptions about where a Solid GSP is stored as users should be able to choose the location they want.

The GSP object is defined in the $ROOT/index document. The RDF type of the GSP is dfc-b:Enterprise.

EXAMPLE: A GSP document in turtle

@prefix dfc-b: <https://github.com/datafoodconsortium/ontology/releases/latest/download/DFC_BusinessOntology.owl#>.

<>
    a dfc-b:Enterprise;
    dfc-b:name "My enterprise".

Other properties can be defined like listed in the GSP shape below (TBD).

2.1. Access rights

By default, the GSP container is private. When one wants to make the GSP public, private properties can still be defined in a separated private document, let’s says $ROOT/index-private, linked with the public $ROOT/index document using the rdfs:seeAlso predicate.

2.2. Discovery

Type indexes is the recommended mechanism to discover Solid GSP. The RDF class to register an instance of a Solid GSP is dfc-b:Enterprise. Type indexes MUST only register the GSPs owned by the WebId owner. See [type-indexes].

3. Products and services

Solid products are defined in [solid-goods-services].

Supplied products are stored in the $ROOT/supplied-products/ container.

4. Catalogs

Supplied products are stored in the $ROOT/catalogs/ container.

5. Third parties

Supplied products are stored in the $ROOT/third-parties/ container.

6. Orders

Supplied products are stored in the $ROOT/orders/ container.

Conformance

Document conventions

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]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.