Should a WebID document behave as a Solid Resource?

[jeff-zucker]

The newest ESS WebID Profile Document is HTML+RDFa being served from something that is not a Solid Resource Server. This means that a simple GET will return HTML unless the Accept header is set. This all mean one needs to take special steps to read a WebID Profile Document on ESS.

I am in favor of a statement in the spec along the lines of :

A Solid WebID Profile Document MUST be publicly readable and MUST return RDF from a GET request unless the request's Accept header specifies a non-RDF format.

[jeff-zucker]

I would amend my suggestion to "A Solid WebID Profile Document must behave as a Solid resource regardless of whether it is located on a Solid server." That would include the requirement to serve turtle as well as address other potential modifications of how profiles are served. It can be a non-Solid resource on a non-Solid server as long as it behaves to Solid clients the same way a Solid resource behaves.

[langsamu]

Regarding ESS behavior only:

Thank you @jeff-zucker for highlighting this.

ESS 2.0 indeed currently responds with an HTML representation when a WebID is dereferenced without an Accept request header.

Inrupt consider this a mistake and are working on a change which will serve a Turtle representation of the WebID instead when Accept is not specified.

[jeff-zucker]

But, on third consideration - this would be a recommendation to servers, not to app developers, and therefore probably does not belong in this spec. Still, it seems quite unstable to have a situation in which the profile document may or may not be readable, may or may not be writable by the WebID owner, may or may not return turtle, etc. and all beyond the scope of any Solid spec.

[langsamu]

Inrupt consider this a mistake and are working on a change which will serve a Turtle representation of the WebID instead when Accept is not specified.

ESS 2.0 now returns Turtle by default.

$ curl -iL https://id.inrupt.com/jeff-zucker
HTTP/2 303
date: Wed, 03 Aug 2022 08:21:15 GMT
content-length: 0
location: https://id.inrupt.com/jeff-zucker?lookup
link: <https://login.inrupt.com>; rel="http://www.w3.org/ns/solid/terms#oidcIssuer"
strict-transport-security: max-age=15724800; includeSubDomains

HTTP/2 200
date: Wed, 03 Aug 2022 08:21:15 GMT
content-type: text/turtle;charset=UTF-8
last-modified: Tue, 19 Jul 2022 10:55:38 GMT
cache-control: must-revalidate, no-transform, max-age=0
etag: "1807129489"
strict-transport-security: max-age=15724800; includeSubDomains

<https://id.inrupt.com/jeff-zucker>
        a       <http://xmlns.com/foaf/0.1/Agent> ;
        <http://www.w3.org/2000/01/rdf-schema#seeAlso>
                <https://storage.inrupt.com/fd43a608-14d2-49bb-8486-1c99823c369a/extendedProfile> ;
        <http://www.w3.org/ns/pim/space#storage>
                <https://storage.inrupt.com/fd43a608-14d2-49bb-8486-1c99823c369a/> ;
        <http://www.w3.org/ns/solid/terms#oidcIssuer>
                <https://login.inrupt.com> ;
        <http://xmlns.com/foaf/0.1/isPrimaryTopicOf>
                <https://storage.inrupt.com/fd43a608-14d2-49bb-8486-1c99823c369a/extendedProfile> .

[pietercolpaert]

Could we standardize an accept header that SHOULD be sent as a WebID client?

[csarven]

I wrote about this in length e.g. (mind the editorial changes in https://solidproject.org/ED/protocol ):

• Requirements for WebID document server specification#376 (comment)
• Requirements for WebID document server specification#376 (comment)

---

A Solid WebID Profile Document MUST be publicly readable and MUST return RDF from a GET request unless the request's Accept header specifies a non-RDF format.

I don't think it is necessary to introduce a protocol level requirement as such into to the WebID Profile spec, especially considering the subject of the requirement is a server. WebID Profile Document is an RDF document and the Solid Protocol describes how servers handle RDF documents. The related interactions are addressed by adherence to underlying RFC 7231.

A Solid WebID Profile Document must behave as a Solid resource regardless of whether it is located on a Solid server.

This can potentially be a contradictory premise or impractical for implementation. If a Solid WebID Profile Document were to behave as a Solid resource, then the server is conforming to the Solid Protocol. The document is "on a" Solid server.

Still, it seems quite unstable to have a situation in which the profile document may or may not be readable, may or may not be writable by the WebID owner, may or may not return turtle, etc. and all beyond the scope of any Solid spec.

A WebID Profile Document may or may not be readable indeed. We already do apply the notion of private (in the general sense) WebID Profiles - data minimisation . (Fun reading / FYN: https://csarven.ca/linked-research-decentralised-web#universal-identity-for-the-web , https://csarven.ca/linked-research-decentralised-web#privacy-considerations ).

If the "owner" is borrowed from https://solidproject.org/ED/protocol#owner and the mechanism to "control" (in the general sense) a resource is provided by the authorization system ( https://solidproject.org/TR/wac#reading-writing-resources ) , writing the WebID Profile Document should be possible.

Could we standardize an accept header that SHOULD be sent as a WebID client?

If a client doesn't send the Accept header, the client must be able to parse a potential Turtle response of the WebID Profile Document.

[jeff-zucker]

I have (hopefully) taken your points into account in #40 so closing this issue now. Ongoing discussion should happen on #40.