Default Storage Location Determination
Currently, dokie.li uses the object of a pim:storage relation from the WebID-Profile document of an authenticated user to determine his/her default storage location preference.
A more flexible approach, bearing in mind that different protocols will introduce different defaults (e.g., as:outbox for Linked Data Notifications), is as follows (exemplified by Markbook Solid App):
Create a Type Registry/Index using pattern: <{URL_OF_YOUR_SOLID_POD}>/settings/publicTypeIndex.ttl :
Add the following:
@prefix as: <https://www.w3.org/ns/activitystreams#> .
@prefix solid: <http://www.w3.org/ns/solid/terms#> .
<#Activity> a solid:TypeRegistration ;
solid:forClass as:Collection ;
as:item <{URL_OF_YOUR_SOLID_POD}/{URL_OF_PREFERRED_FOLDER}/activities.ttl> .
/cc @csarven @RubenVerborgh @melvincarvalho
The spec for it is at https://github.com/solid/solid/blob/master/proposals/data-discovery.md . See also: https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#type-registry-index-discovery
My old apps used to use pim : storage which I would crawl. Newer apps I'm using the type registration. I quite like the type registration way, so far.
Yea, it makes sense for higher specificity. pim:storage can serve as a fallback if no type index and suitable type registration.
We may need to decide which of the (public or private) indexes should take precedence, if at all. And, how that's reflected in the UI (if at all).
@csarven,
Yes re fallback suggestion. As for precedence, bearing in mind the privacy and acls orientation of Solid, the private inbox would be the default. That way folks won't accidentally publishing something for public viewing that they may have intended to be private i.e., the default is to be private leaving ACLs to control access scope.
Sure re private, and I think public is quite useful too. For instance, 'Activities' in dokieli can help public annotations to be discoverable, without getting in the way of private annotations. So, the UI should take that into account (see eg https://github.com/linkeddata/dokieli/issues/115 )