search

solid / webid-profile

Discovery based on Solid Social Agent WebID
https://solid.github.io/webid-profile/
MIT License
12 stars 8 forks source link

Clarify how a Solid resource server can determine a resource is a WebID Profile #100

Open VirginiaBalseiro opened 1 year ago

VirginiaBalseiro commented 1 year ago 
          Since statements with the `solid:oidcIssuer` predicate is defined as *protected* in this spec, I assume it only applies to resources that are WebID Profiles. How the solid storage/resource server is going to determine that a given resource should be handled as a WebID Profile?

_Originally posted by @elf-pavlik in https://github.com/solid/webid-profile/pull/98#discussion_r1280011715_

langsamu commented 1 year ago

As an implementer of clients and servers for Solid and WebID, I would advise against the following mechanisms for a server to identify resources (if resources need to be identified/classified at all). I don't know that any of these have been proposed, so I'm only arguing against myself.

  1. Based on resource URI. At least some Solid servers do not associate any meaning with resource URIs (except what is required by the Protocol). Requiring them to do so might be an unacceptable architectural burden.
  2. Based on content-type. This would be problematic, in my opinion, for several reasons:
    1. Solid servers will have different ways to store the contents of resources. They will support content-negotiation in different ways. If we classified resources based on content-type then we would potentially interfere with these mechanisms.
    2. I think that it is unlikely to have a MIME for these profile documents, so matching on their content-type would preclude that content-type from usage by other resource classes. Even if there was a MIME for some class of resources, it would still be problematic to reuse the content-type property of resources for this purpose of classification.
  3. Based on resource contents. This would be problematic, in my opinion, for several reasons:
    1. There is cost associated with Solid servers reading/accessing/inspecting/parsing/validating the contents of resources. It would be quite a burden for them to have to do this in order to identify a resource as a certain type/class.
    2. Any classification that is based on the content of resources would make it hard or impossible to reuse the patterns used for classification in other contexts like quoting or caching. If we, for example, match on a certain predicate, then that predicate is excluded from all other resources that should not be classified as the given type.