These are all proposals, so not accepted yet, but useful for us to keep an eye on and perhaps give feedback as we consider how these uses of the WebID profile relate to SAFE (or not):
# Solid application configuration/preferences discovery (Draft)
The following describes app configuration discovery in the Solid framework
using HTTP link following aka "follow your nose". This should not be
confused with [application data discovery](https://github.com/solid/solid/tree/master/proposals/data-discovery.md)
## Starting point -- WebID
### Fetching the Profile
The public profile is what you get when you look up someone's WebID directly.
Strip off any hash and localid part. For example.
```
https://example.databox.me/profile/card#me -> https://example.databox.me/profile/card
```
The starting point of discovery is a
[WebID](http://www.w3.org/2005/Incubator/webid/spec/identity/) user profile,
which is a hash based URI, typically denoting a (FOAF) Agent. From this profile
show original
# Solid Application Data Discovery
The following describes application data discovery in the Solid framework
using HTTP link following aka "follow your nose". This should not be
confused with [Application Configuration
Discovery](https://github.com/solid/solid/tree/master/proposals/app-discovery.md)
or [Storage
Discovery](https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#storage-discovery).
**Note:** The Type Registry is mainly intended as a Library discovery mechanism.
We recommend that coarse-grained library types are registered (usually types
that match containers as opposed to every RDF Class written by an app).
Specifically, the Type Registry provides a way for a client application to
discover where a user keeps data relevant to this app, without either:
a. Prompting the user to select the location of every relevant instance or
container, or
b. Scanning through the entire dataspace/root storage of the user.
show original
5 Likes