-
Notifications
You must be signed in to change notification settings - Fork 19
Description
The specs do not mandate any triples in a profile except those related to OIDC. That means that triples using predicates like ldp:inbox, pim:storage, pim:preferencesFile, solid:account, solid:*typeIndex are optional and the specs, AFAIK, have nothing to say about them in relation to the profile. I believe that there should be a non-normative best practices section describing recommended uses of these predicates and descriptions of some of the reasons why a user might want to include or omit them.
These predicates would remain optional, so apps would need a fallback if they are not found. But an app could also have a "first port of call", a place that is easy to find (we know the webId so can find it's profile) and likely (though not certain) to find the scents needed to follow its nose.
Due to the use of these predicates in NSS profile provisioning and in the SolidOS databrowser discovery, there is already a defacto convention in use. But I believe we should have some more official best practices. To me it is an open question as to whether these should be for apps and users only, or whether there should be some aimed at pod providers.
The typeIndexes are probably the most controversial as the Interoperability Panel will be finalizing a more robust method soonish. I'm not sure if this means that there be no best practice for the existing typeIndexes or whether we can support them as an alternate method for those not requiring the full power of the coming Data Registraion methods.
Do others agree this kind of best-practice document is a need? If so, what's the best way to go about tackling this? In this panel or in some other team?
See also this related forum discussion.