Specify or agree the class of an Agent

[webr3]

Following on from #17 and my superset/subset proposal, the most important part remains unhandled.

WebID broadly defines a <uri> which dereferences to an RDF response that asserts <uri> a webid:Agent, is a webid.

We need to agree on and finalise a single identifier for the class of Agents. Other types can subtype this.

Then it can be used in range or domain statements.

There can be no webid protocol or specification without being able to assert <uri> a webid:Agent - it is the foundation, all else is secondary.

[jacoscaz]

/chair hat off

Definitely +1 on this. Even if I personally do not consider it absolutely necessary, I can't see how having the following minimal set of triples would hurt anything:

<http://example.org/#me> a webid:Agent .
<http://example.org/> foaf:primaryTopic <http://example.org/#me> .

I actually find it adds more clarity.

[csarven]

My response is in the context of including this kind of information towards a Data Model (or towards a Shape):

I don't see the benefit of bringing both foaf: and webid::

If webid:Agent is deemed to be required by the model, it would suffice to include something along the lines of what would be intended with webid:primaryTopic.

If foaf:primaryTopic is desired, no need to introduce webid:Agent since foaf:Agent would suffice.

And so suggest aiming to use a single ns, if and only if course the Data Model becomes part of Conformance.

Lastly, introducing webid:Agent would render existing WebID Profile descriptions, with respect to what's intended to date, non-conforming. In contrast, requiring foaf:Agent with foaf:primaryTopic would technically ensure widely deployed WebID Profile Documents to be technically conforming. Both are class 3 changes.

[jacoscaz]

Lastly, introducing webid:Agent would render existing WebID Profile descriptions, with respect to what's intended to date, non-conforming. In contrast, requiring foaf:Agent with foaf:primaryTopic would technically ensure widely deployed WebID Profile Documents to be technically conforming.

IMHO, we should strive to maintain backward compatibility. I do feel that having some kind of <webid> a <Agent> (whether webid:Agent, foaf:Agent, ...) would make things clearer but, in light of the above, perhaps it could be a recommendation.

However, taking a step back... Reading through previous discussion and looking at this issue's opening post under the light of the what is WebID without X question, I feel issue https://github.com/w3c/WebID/issues/22#issuecomment-1878848425 might be touching upon this one and vice-versa.

I suspect some of us - I suspect @woutermont, for one - might see WebID as a way to ensure that URI and the information in that RDF Document are indeed under the control of the Agent we are interacting with. In this case, a WebID implementation must also implement an Extension Profile (i.e. at least one of WebID-TLS, WebID-OIDC, ...) and the combination of that plus foaf:primaryTopic is likely enough of a differentiating factor from any other document.

Some others - I suspect @webr3 and @csarven, for example - might see WebID as something that may stand on its own even without the implementation of an authentication-related Extension Profile. In this case, foaf:primaryTopic would not be enough of a differentiation factor and the additional foaf:Agent might be needed.

Am I wrong?

[melvincarvalho]

WebID does not have a dependency on FOAF, and that was by intention. Indeed the whole purpose of the shift from FOAF+SSL -> WebID was to remove the FOAF dependency, and hence, make it future proofed.

IMHO, we should strive to maintain backward compatibility

There is no backwards compatibility, to speak of. FOAF is only used in examples. That is very deliberate to avoid issues, such as this one.

That said, we have learnt an awful lot from 2014 -> 2024 and are now in a position to make decisions.

[woutermont]

Alright, @melvincarvalho, so you are saying that even though most existing WebIDs use FOAF, and most existing WebID implementations rely on those FOAF statements, we can just throw them out of the boat because it was never a requirement in the spec?

Note that I do not have an unmoving opinion on whether or not to provide backward compatibility. It's just that in this case, it does not matter which vocabulary we choose: as I have tried to point out on multiple occasions, the need for those triples in the WebID is WebID-specific. Only WebID libraries and providers would need to ever use them; anyone can put whatever else they want next to those statements, but software just needs some terms to rely on. And given this, since no one else should care whether we that codes checks for FOAF, SCHEMA, FOO or BAR, we might as well choose in favor of backward compatibility.

[webr3]

I suspect some of us - I suspect @woutermont, for one - might see WebID as a way to ensure that URI and the information in that RDF Document are indeed under the control of the Agent we are interacting with. In this case, a WebID implementation must also implement an Extension Profile (i.e. at least one of WebID-TLS, WebID-OIDC, ...) and the combination of that plus foaf:primaryTopic is likely enough of a differentiating factor from any other document.

Some others - I suspect @webr3 and @csarven, for example - might see WebID as something that may stand on its own even without the implementation of an authentication-related Extension Profile. In this case, foaf:primaryTopic would not be enough of a differentiation factor and the additional foaf:Agent might be needed.

For clarity, I'm more in the same camp as @woutermont on this one - I've observed little implementation of or respect for entailments and inference over the years, but a property with range or domain of Agent can be hard coded fairly and resolves. Consider the keys and details of 100 bots in one doc, each with their own #id - what is the least that can be defined to enable this.. dereferenceable http URIs where each is an Agent, then layer on keys and additional info as required.

I personally view one part of the spec as being relatively stable in time (the part just mentioned), and other parts such as new auths or crypto types or properties as being much more fluid and open to change over the years to come.

Hence bias strongly toward a minimal agreement that facilitates interop, where one can implement if(thing an Agent) then followed by checks and tests for different properties and bits of data to enable features, whatever they may be, or turn out to be in 5-15 years.

@jacoscaz For clarity, I'm happy with MUST :Agent, where it can be either explicit or implicit, as in by either @type Agent, or by a property with domain or range of agent, whether that's something like a profile property, a hasKeySig, whatever it may be, as long the spec forces a way to easily determine the uri identifies an agent. I'd prefer explicit but swapping to MUST be an Agent with this qualification facilitates the primaryTopic approach as a MAY and still satisfied the MUST Agent requirement.

[melvincarvalho]

you are saying that even though most existing WebIDs use FOAF, and most existing WebID implementations rely on those FOAF statements, we can just throw them out of the boat because it was never a requirement in the spec?

Not saying that. I am completely open to FOAF. I am pointing out that the FOAF specificity was at one point removed. Additionally in the two decades since FOAF, new things have come along.

But I would say that whatever is selected, it must be testable.

[jacoscaz]

Closed by #60.