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: https://github.com/solid/webid-profile/issues/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 #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.

[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 https://github.com/solid/webid-profile/issues/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 ( https://github.com/solid/webid-profile/pull/98#discussion_r1285636569 ). 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.