Consider usefulness of distinguishing controller and owner of a WebID

[csarven]

I have explored the scenario where a person controls a WebID but not does not have ownership of the URI (as per AWWW). Some suggested reading from 2017 starting at [1] (discussion spanning a week). Explores/implements discovery of additional WebIDs or WebID Profile Documents via properties e.g., owl:sameAs, contact:preferredURI, ex:webid. (Or perhaps something more recently with as:alsoKnownAs.)

Here, control entails that an individual can authenticate and is authorized to update their WebID Profile Document in an implementation defined way or generally not in conformance with Solid specifications.

It is useful to keep in mind degree of control with respect to identifiers [2]. A WebID URI may be owned (AWWW) by an entity different than the entity which controls it (delegated).

The idea was to allow people to help connect their existing WebIDs to WebIDs where they may have more control or ownership. In this case, the context in which control is applied is in conformance with Solid specifications.

To exemplify, I've done some work towards that for ORCIDs (identifies authors/contributors in scholarly communication), e.g., [3] [4] [5] [6]. This was proven to be useful, at least as a proof of concept.

An alternative view of this consideration can be simplified to whether to specify the kind of relationship to a WebID on a storage, essentially an incoming link/reference to a WebID, where the read-write operations are defined by the Solid Protocol.

[1] https://gitter.im/solid/chat?at=59f890fce44c43700a9dc81f (archived)
[2] https://csarven.ca/linked-research-decentralised-web#degree-of-control
[3] curl -iLH'Accept: text/turtle' https://orcid.org/0000-0002-0880-9125 (note sameAs, inbox, storage, outbox statements)
[4] ORCID/ORCID-Source#4398
[5] https://csarven.ca/linked-research-decentralised-web#dokieli-related-contributions
[6] https://twitter.com/csarven/status/991645600402825217 (archived)

[jeff-zucker]

It wasn't until I read solid/specification#376 (comment) that I realized what you are suggesting. Do I have it right that you are suggesting that the ESS style WebID document would point to a Solid Profile Document and the URI of the Solid Profile document would become their SolidID and that statements in the Solid Profile would have the SolidID as subject, not the WebID? What then do we use in an ACL - the SolidID or the WebID? If it's the SolidID, how can it be verified?

[jeff-zucker]

I am opposed to having two separate IDs, I think the WebID should directly denote the Agent, not be something that is the same as something that denotes the Agent.

In NSS , the WebID is the subject of the profile. Do we then say "the WebID is the subject of the profile unless ..."?

So, if WebID dereferences to A not on a Solid Resource Server and has a pointer to B the Solid Profile Document on a Solid Resource Server, the subject of statements in B should be the WebID.

That way only one instruction - the WebID is the subject of statements in the Solid Profile Document.