Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
VirginiaBalseiro opened this issue Sep 4, 2023 · 1 comment

Comments

@VirginiaBalseiro
Copy link
Member

          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 #98 (comment)

@langsamu
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants