data workspaces should not be hardwired

[bblfish]

From the current spec it seems that the names of the data-spaces are currently hardwired. This is not good from the point of LinkedData, extensibility, or internationalisation.

Instead we need to have an ontology for the relations from the account to the different resources. The current set of workspaces seem to be determined by Access Control rules, in which case the rights to them is in any case defined in the ACLs of the Containers.

It seems that these ontologies have not been created yet.

[timbl]

Do you mean the names like "Home
", "Work"? If so, it is good to give them human-centric names, obviously should be easy to edit them, but also a list of translations into the user's pref language is clearly necessary yes.

[bblfish]

Well I was thinking that it would be good to have everything be using the "follow your nose" principle, so that from the WebID Profile document one would have something like

<> solid:work <Work/>;  
     solid:home <Home/>; ...

So that a French person could have

<> solid:work <Boulot/>;
     solid:home <Maison/>; ...

and a Japanese have Unicode Characters for the home if needed. I am not 100% sure about the types of containers actually needed. I suppose that solid:work would be a subrelation of ldp:contains...

Btw, currently I am trying to work out how to set app preferences locally for my client.

[deiu]

Follow your nose is also something we currently do. For instance, to discover the user's workspaces, an app will try to find all the relations of type http://www.w3.org/ns/pim/space#workspace. The way we link to workspaces now is from the preferences document, which is a protected resource that extends the WebID profile, and to which the WebID profile points through a relation of type http://www.w3.org/ns/pim/space#preferencesFile (it could also be an owl:seeAlso relation).

In the WebID profile:

<https://bob.example.org/profile/card#me>
    <http://www.w3.org/ns/pim/space#preferencesFile> <https://bob.example.org/profile/prefs> .

In the preferences file:

<https://bob.example.org/profile/card#me>
    <http://www.w3.org/ns/pim/space#workspace> <https://bob.example.org/Public/>, <https://bob.example.org/Private/>, <https://bob.example.org/Shared/>, <https://bob.example.org/Work>, <https://bob.example.org/Friends/>, <https://bob.example.org/Family> .

Of course, i18n support is definitely something we want, but life is too short and we needed to start somewhere.

[bblfish]

Ah ok, so you have a follow your nose just using one relation. So if I understand correctly that <https://bob.example.org/Public/> is public is really just decided by the Web ACLs on that resource (LDPC)? It could be named completely different ways? ( I am not sure that comes out clearly in the SoLiD documentation )

[deiu]

Yes, whether a container called "Public" is public or not is decided by ACLs. I'll take a look at the document and update it to reflect this feature.

[deiu]

I've reworded the section on workspaces. Please let me know if it makes more sense now.

[bblfish]

ok, I understand better now. I'll be able to give more positive feedback once I have implemented preferences myself.

[bblfish]

oh, before you close the issue, it may be helpful to have some links to actually used but non-normative preference files, just to help some of us to tune our intuitions on what is being done.

[deiu]

I've added a full example of a preferences file in the corresponding section. I'll need to have a chat with Tim about the class name ConfigurationFile, which is not quite consistent with the whole preferences theme.

[dmitrizagidulin]

Closing. Related discussion moved to solid/23: Replace Workspaces concept, standardize default account Containers