Revise conformance section, add Reading and Writing section

[VirginiaBalseiro]

Closes #89, #93.

This PR revises the conformance section and adds a Reading and Writing profiles section with clear requirements.

Some of the information in this new section overlap with Discovering... section and Extended profiles sections. These will require further revision (see: #92)

Preview | Diff

[elf-pavlik]

I see a few issues related to #97 (and #63), which were discussed during last week's call. I think they can be resolved independently from this specific PR, I will just mention them here since they potentially would have impact further down the road on what comes in this PR.

• There seems to be an assumption that WebID Document (defined in WebID spec) is the same document as WebID Profile. I understand the requirement that WebID (Solid?) The profile would be hosted in Solid Storage, but I don't think it can be required that WebID (Solid?) The profile is the same as WebID Document, which doesn't have to be hosted in Solid Storage.
• As discussed in Loose coupling with specs like Type Indexes, SAI, Solid-OIDC etc. #97 other specifications should be able to extend WebID (Solid?) Profile. I think the Private Preferences should be a separate spec, similar to Type Indexes or possibly combined with Type Indexes. I see the Private Preferences section as very underspecified and appears to make some assumptions about authentication and authorization which may not always be correct. The following should be tracked as an open registry/directory rather than be included in the spec that will be snapshot.
  • solid:oidcIssuer
  • ldp:inbox
  • space:storage
  • space:preferencesFile
• Mentioned registry/directory should also include if the property is protected, for example, solid:oidcIssuer or not.
• The concept of protected properties should be reevaluated altogether. Solid authorization seems to be on the resource, not the triple-based level. This seems especially challenging when there is no closed set of protected properties. If all properties by default are unprotected, a property that is intended to be protected ends up unprotected just because the server implementation didn't have it in the list of protected properties. The strategy of having separate resources for protected and unprotected statements seems more robust when it comes to extensibility. It also follows resource-level access control.

[elf-pavlik]

Since statements with the solid:oidcIssuer predicate is defined as protected in this spec, I assume it only applies to resources that are WebID Profiles. How the solid storage/resource server is going to determine that a given resource should be handled as a WebID Profile?

[csarven]

I agree this needs to be better spelled out.

One way would be to associate (link relation) the data shape (as WIP being specified by this specification) with the resource, e.g., Solid WebID Profile.

One of the products of this specification needs to be something like "SolidWebIDProfileDataShape" (e.g., using SHACL) that we make available from https://github.com/solid/shapes/ .

[VirginiaBalseiro]

Created #100 to follow up on this.

[csarven]

There seems to be an assumption that WebID Document (defined in WebID spec) is the same document as WebID Profile. I understand the requirement that WebID (Solid?) The profile would be hosted in Solid Storage, but I don't think it can be required that WebID (Solid?) The profile is the same as WebID Document, which doesn't have to be hosted in Solid Storage.

This is a bit hard to follow for me. Can you please paraphrase this?

As I see it from this specification and understanding in the community:

The Solid WebID Profile specification specifies the data model of the WebID Profile used in Solid, as well as any additional requirements to a Solid Protocol Server hosting the resource.

The ReaderApplication should be able to read any WebID Profile (conforming to WebID 1.0 ED) but the WriterApplication works against Solid Protocol's Server - to be further clear, WriteApplication is not intended to be able to update any WebID Profile out there, just what's on Solid storage.

As discussed in
#97 other specifications should be able to extend WebID (Solid?) Profile.

I don't have a particular objection to that proposal, after all, it is a legitimate design on its own. However, what I would emphasise on specifying (and requiring) is the minimal Solid WebID Profile Data Model - whatever that may be. If we split off too much with optional/modular specifications, there may not be much to say about the Solid WebID Profile at its core, and that frankly leaves this specification not a whole lot more than the WebID 1.0 ED. So, this is just trying to answer the age old question about what constitutes a Solid WebID Profile. Can a social agent use it to authenticate itself? store stuff at its storage? be contacted? Yes, I'm aware of various cases in which it may not be used for authentication, or to disclose a storage or use it to store anything, or be available for contact - and so the data shape is/should take that into account.

Mentioned registry/directory should also include if the property is protected, for example, solid:oidcIssuer or not.
The concept of protected properties should be reevaluated altogether. Solid authorization seems to be on the resource, not the triple-based level. This seems especially challenging when there is no closed set of protected properties. If all properties by default are unprotected, a property that is intended to be protected ends up unprotected just because the server implementation didn't have it in the list of protected properties. The strategy of having separate resources for protected and unprotected statements seems more robust when it comes to extensibility. It also follows resource-level access control.

Again, no objection... but I think this can be leveraged by server using the shape specified by the specification to protect certain statements. The specifications needs to introduce how that shape association with the Solid WebID Profile document happens ( #98 (comment) ). We have a data model / shape in the works, might as well apply that directly where we need it.

Aside: The above (explicit) approach can be used in the Solid Protocol for container / containment statements as well, but the interaction model or (cough) slash semantics already implicitly indicate that the resource is a container, so the server knows how to protect. We don't have anything equivalent to that for the Solid WebID Profile, so there needs to be a link relation referring to the shape.

[edwardsph]

I mainly checked that the RDFa produced the correct requirements for the test harness and it is essentially correct. The line breaks in text do come through into the RDF and make it look odd e.g.

  spec:statement """Reader
                                Application MAY retrieve a
                            representation of an Extended Profile Document."""@en .

Two other considerations are:

• Does the requirement work as a standalone statement? I think some are a bit too dependent on context for them to make sense but when they appear in test reports, they need to make sufficient sense to be understood without that context.
• Are requirements clearly testable -I have highlighted one that I think isn't as it stands

[edwardsph]

Writer Application MUST use an HTTP PUT or PATCH request targeting the Solid WebID Profile to be updated

Ideally requirement statements should be standalone statements to make them easier to understand in other contexts such as test results. What I think is missing above is the clear purpose - the context is 'update' but perhaps it could be worded as "To update the Solid WebID Profile ...". Is there also something about the body and content type of such requests.

[csarven]

Writer Application is a Solid app (Solid Protocol). But we need to revisit this with respect to the Solid Protocol because it is not currently defined as an independent product class. Writer Application could be a specialisation of Solid Protocol Client but then that would still require us to revisit Solid app in Solid Protocol. The general understanding is that the Solid app issues HTTP requests through the Solid Protocol Client against a Solid Protocol Server. So, Writer Application writes to a Solid WebID Profile on a Solid storage.

Solid WebID Profile is an RDF document. Solid Servers can potentially accept any concrete RDF syntax, but only required to respond to Turtle and JSON-LD. The body of the request includes an RDF representation based on the Solid WebID Profile data model.

---

I agree with the suggestion to have multiple (identifiable) requirements. And doing that for all similar requirements. (It is also okay to leave it as is for the time being - not super urgent per se.)

---

Purpose at the front instead of at the end seems okay too. I would only suggest that the specification should generally be consistent (and boring), so if "purpose" comes first, do it for all similar requirements, e.g., "[purpose] [requirementSubject] [requirementLevel] [behaviour]".

We can look at this from the Solid QA end and make a proposal that could be used across all specs.

[VirginiaBalseiro]

I created #101 to follow up on this.

[TallTed]

Minor