csarven on main
Add privacy-principles (compare)
csarven on version-scheme
Add version scheme (compare)
csarven on kjetil-homepage
csarven on require-describedby
csarven on restrict-requirement
csarven on allow-delete
http://www.w3.org/ns/solid/termsis still in use by Solid servers and applications. It is also mentioned in the Solid ecosystem document: https://solid.github.io/specification/#namespaces and used in examples in the spec.
well, RDF representation of PNG is RDF, so you would get what you ask for
Exactly, that's why I don't want to ask for it :) I don't actually want content in a particular format, I want to know what type of content it is (i.e. RDF or not). But I guess this gets particularly problematic when parts of a Resource are RDF and parts aren't :/
@gatemezing Did we already talk about LOV having an inbox to receive notifications about new vocabs or updates to existing ones. You can have a shape for the notification so that can work as a way to register vocabs in LOV
Not yet, but happy to start that discussion - TIA. We just use a "basic bot" for checking some metadata for updates in a vocab and email notification when someone submit a new vocab. BTW, it would be great to have more metadata in the Solid vocab.
foaf:Agentis used if no WebID client cert is present
based on the WAC https://www.w3.org/wiki/WebAccessControl
Servers are required to recognize the class
foaf:Agentas the class of all agents. This indicates that the given access is public. In some cases this will mean that authentication is therefore not required, and may be skipped. When a resource is being written, however, it may be necessary to associate the change with some kind of ID for accountability purposes.
acl:AuthenticatedAgentmakes sense if the server constrains the identity providers that are trusted. In traditional web applications with external identity providers, this tends to be a closed set (e.g. login with Google, FB and Twitter but not any arbitrary identity system), and there,
acl:AuthenticatedAgentmakes sense. If, however, identity in Solid is entirely decentralized and if resource servers need to be able to negotiate auth tokens from an open set of identity providers, then there is effectively no difference between an “authenticated” agent and an unauthenticated agent: I can create an ephemeral identity provider with an ephemeral WebID and call that an
acl:AuthenticatedAgentwhich could get a higher level of access just because I have some scripts running this ephemeral infrastructure