Okay, so we’d have say WebID Profile Document → Extended Profile Document (in pod) → Restricted Profile Document (limited to certain WebIDs)
Would it make sense to have a separate method, but same algorithm for discovering preferences? e.g., preferences might be keyed by the application IRI or client identifier or application’s WebID.
So you’d go WebID Profile Document → pim:preferencesFile → [ WebID, Application Identifier ] → triples, or if the Application Identifier is an IRI then load that document and return it as preferences.
An owner-operated app that wants to store preferences can simply put them in the preferences file or a seeAlso file pointed to from the preferences file. If appX creates appX.prefs.ttl and puts a seeAlso pointer to that in the preferences file, it can access those prefs whenever it needs to. Not sure what would be added by your suggestions.
I’m thinking more of “how does a specific application discover it’s settings”, which I doubt would be desired to be reusable across apps. Hence thinking the app would look for a triple where the app’s client identifier is the subject.
This would potentially leak data between apps as to which other apps you use, though.
I don’t think it needs to leak anything. You create a file called AppXConfigs.ttl but since you don’t want anyone to know that you use AppX, you create a file FooConfigs.ttl. You make this file readable only when AppX is being operated by you, not any other app by anyone else. You place a seeAlso pointer to that file in your pim:preferencesFile. Now any app operated by you can see that there is a link to FooConfigs.ttl and will try to load it (apps are required to try to load all seeAlso files in the preferences file or main profile) but only AppX will succeed in loading it. Now the triples in that file will be known by AppX but no other app. Make sense?
After all that ^^ … the public knows nothing about your app or FooConfigs.ttll; apps operated by you know there is a seeAlso file called “FooConfigs.ttl” but not what it is in it or what app it applies to. When you are operating AppX, it will be able to see the prefs in FooConfigs.ttl. There is no need to put AppX’s WebID in any triple or to name the seeAlso file anything special, or for AppX to do anything special to read it. All apps operated by you will try to load the config file but only AppX will succeed. This will happen because of the permissions on the file, not because of a WebID triple or other naming convention.
And because FooConfigs.ttl can only be read by a given WebID & Client, you’re golden.
I think an SDK would only follow automatically as far as "FooConfigs.ttl", not further (have to limit depth at some point), and then your app would have to manually go "okay, we got this rdfs:seeAlso on FooConfigs.ttl and know to follow it.
That’s all how I see it except FooConfigs.tll would be the config file for AppX, not pointer to it. The spec will say apps should follow all seeAlsos that are in the WebID Profile Document or the pim:preferencesFile but is NOT required to read seeAlso’s located in seeAlso files.
Right, so if FooConfig.ttl is AppXConfig.ttl, then that could leak to another application that you use AppX — I think it’d be a good idea to recommend that clients don’t name their applications’ preferences file after their application, but instead use a random identifier (e.g., a uuid) to avoid this sort of information leak.
Then to figure out which file is for your application you’d use either the subject to indicate it, or a predicate that you know you need. (Though loading N documents just to find 1 is pretty horribly inefficient)
loading N documents just to find 1 is pretty horribly inefficient
If you have 10 apps, each with their own private seeAlso, yes the app needs to try to load all 10 but each app will only end up loading 1 because that is the only one they have permission on. Yes, inefficient but not to the extent of having to actually load all of that information.