Proposed Conformance Model #40
Description
[EDIT - updated based on Editor's meeting of 2022-09-06, but not including all the comments since last update. This model is likely to change]
Given that IdPs may wish to restrict how WebID Documents behave, including limiting the ability of the WebID owner to write to the document, we need to support the ESS-like model in which the WebID document is not the same document as the Profile document.
If we proceed as I've outlined below, we would have two shapes which can occur in one document or in two documents. In the NSS-like instance where the same document is both the WebID document and the Profile document, it would need to conform to both shapes. In the ESS-like instance the WebID Document could be very minimal and the Solid Profile Document would conform to the same shape as all other Solid Profile Documents.
I also propose a solid:profileDocument predicate. We can add a note that, for backward compatibility, developers may wish to also check for the foaf:primaryTopicOf predicate.
Solid Profile Data Model Conformance
The Solid WebID Document
This document should follow the rules set forth in the WebID Specification including (TBD:get exact wording)
And it should follow this rule, introduced by this spec
- it MUST either conform to the rules listed below for a Solid Profile Document or else have a triple equivalent to
<?WebID> solid:profileDocument <?SolidProfileDocument>.. For backward compatibility, the predicate can be foaf:primaryTopicOf instead.
In order to be usable for purposes of verifying identity, a WebID document should also contain predicates mandated by the identity protocol in use. For example if the Solid-OIDC protocol is in use, the WebID document MUST include a triple equavent to <?WebID> solid:oidcIssuer <?Issuer>. See the Solid-OIDC specification for details
The Solid Profile Document
- there MUST be exactly one Solid Profile Document for any given WebID URI
- it MUST have exactly one
space:preferencesFiletriple - it MUST be writable by the WebID owner or those they designate
- it SHOULD have exactly one
ldp:inboxtriple - it SHOULD have one or more
space:storagetriples - it MAY have zero or more triples with the
solid:communitypredicate - it MAY have zero or more triples with the
rdfs:seeAlsopredicate - it can be the same document as the WebID Document or it can be a separate Document. In the case in which the Solid Profile Document and the Solid WebID Document are the same, the document MUST conform to the rules listed above for both types of documents.
The Preferences Document (space:preferencesFile)
- there MUST be exactly one Preferences Document
- it MUST be writable by the WebID owner or those they designate
- it MUST NOT be readable or writable by anyone other than the WebID owner or those they designate
- it MAY have zero or more triples with the
rdfs:seeAlsopredicate
Extended Profile Documents (rdfs:seeAlso)
- there MAY be zero of more extended profile documents
- they MAY be accessible to public, restricted, or private audiences
Note: Apps can be expected to examine triples in seeAlso documents with the WebID as subject. They are free to but not required to examine other triples.
Note: Apps are free to but are not required to examine triples in seeAlso documents using the rdfs:seeAlso predicate.