solid:profileDocument predicate

[jeff-zucker]

I believe that this specification should say that, in order to be consdered interoperable with Solid applications, all WebID profile documents (the ones the WebID URL dereferences to) MUST either a) be potentially writable (possibly with security restrictions) by apps using the Solid Protocol OR b) contain a single solid:profileDocument predicate that points to such a document.

For backwards compatability, the foaf:primaryTopicOf predicate might be considered a synonym of solid:profileDocument.

In my mind, this is the only way to make it unambiguously clear where apps should write things like pointers to a type index. Without it, the app is left to guess if one of the rdfs:seeAlsos is writable.

With this predicate an app looking for a type index can go to an ESS-style server, look for the solid:profileDocument predicate, open it, look for a type index predicate and create one there if none is found.

Without this predicate an app looking for a type index goes to an ESS-style server, looks for a type index predicate and if none is found keep opening all mentioned seeAlso links and looking in them for type index predicates and if none is found, randomly choose one of the seeAlsos to write the pointer to the type index.

Historical note : ESS-style servers have been operating exactly as proposed here (using primaryTopicOf) for almost two years. I originally made this proposal a year ago in #40 but we closed that issue because that issue conflated too many things.

[csarven]

Specifications (or at the very least a group of depending requirements) should aim to be orthogonal. Same goes authn/z mechanisms from the data model used for the Solid WebID Profile.

Ultimately the most basic functional requirement is to be able to read and write the primary Solid profile document using the Solid Protocol. If certain authentication mechanisms are brittle, inadequate, or complicate security, then that shouldn't impose itself on the core data model. On the contrary, it should be view as optional, as with any other authentication mechanism.

For instance, when we were using WebID-TLS, one profile was adequate and efficient. If other mechanisms impose splitting the profile document into multiple ones where one is read-only and the other is for read-write, then we need to see that as one possible approach.

Again, if the primary profile document needs to be "well protected", I don't see that as an issue on the profile data model.

After all.. the whole point of the Solid Protocol is to allow agents (individuals and groups..) to control their own profile. Suggesting that the profile (by dereferencing the primary WebID URI) can't be modified using Solid Protocol pretty much admits defeat. We might as well pack up and go home...

So, I find the general notion of finding complementary or supplementary documents along the lines of seeAlso, and if that comes out as profileDocument or whatever new or additional property (or discovery mechanism), that's fine. But that need not impose the writability of the primary document. Those are separate / orthogonal matters as I see it.

Let me just also add that the W3C CG's Solid WebID Profile can be informed but shouldn't be redesigned because of arbitrary business decisions made by a particular for-profit company with a proprietary system with a particular configuration for a number of specifications (with questionable conformance).