BUG: Respect and follow http://www.w3.org/ns/pim/space#preferencesFile if it exists in profile card

[hexagon6]

Dear Noel,

I've tried Media Kraken with my solid profile.

It looked like this before using the application:

@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.

<https://solid.example.org/profile/card> a foaf:PersonalProfileDocument;
    foaf:maker <#me>;
    foaf:primaryTopic <#me>.
<#me> a foaf:Person;
    solid:oidcIssuer <https://solid.example.org/>;
    solid:publicTypeIndex <https://solid.example.org/publicTypeIndex.ttl>;
    <http://www.w3.org/ns/pim/space#preferencesFile> <https://solid.example.org/settings/prefs.ttl>.

after a PATCH request with

        INSERT DATA {
            <https://solid.example.org/profile/card#me> <http://www.w3.org/ns/solid/terms#privateTypeIndex> <https://solid.example.org/settings/privateTypeIndex> .
        }

It looks like this:

@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.

<https://solid.example.org/profile/card> a foaf:PersonalProfileDocument;
    foaf:maker <#me>;
    foaf:primaryTopic <#me>.
<#me> a foaf:Person;
    solid:oidcIssuer <https://solid.example.org/>;
    solid:publicTypeIndex <https://solid.example.org/publicTypeIndex.ttl>;
    <http://www.w3.org/ns/pim/space#preferencesFile> <https://solid.example.org/settings/prefs.ttl>;
    solid:privateTypeIndex <https://solid.example.org/settings/privateTypeIndex>.

Also after the PATCH request media kraken created a new https://solid.example.org/settings/privateTypeIndex with PUT, which overrides the existing one, that was listed in the preferencesFile. (actually no, the existing one had a .ttl extension)

This means:

The existing /settings/privateTypeIndex was overridden and I lost links to other documents which were in there!
Interestingly https://solid.example.org/settings/privateTypeIndex.ttl (with extension) already existed (but not https://solid.example.com/settings/privateTypeIndex - without extension), so no information was lost, just another solid app can't find the private type index anymore due to the change...

Hint: My Profile was set up like this https://solid.github.io/type-indexes/#type-indexes:

[NoelDeMartin]

Hi there, thanks for opening an issue!

I'm aware that Media Kraken (and all of my apps) are not using pim:preferencesFile. The reason why is that the spec is still a draft, and I was waiting to have an official version before committing to anything. However, it's been a draft for years at this point... So maybe I should go ahead and implement what's specified for now. Thanks for bringing attention to this :). I'll use this issue to track the progress on that.

Regarding the creation of a new type index, when I read the issue before you updated it I was surprised because, indeed, it shouldn't be possible for the document to be overridden. If my apps are trying to create a document that already exists, what happens is they create one with the same name and add a uuid at the end. This is to prevent data loss, and as far as I'm aware there hasn't been anyone losing data using my apps. But if that were to happen, of course, I'd take it very seriously.

The whole .ttl vs not specifying the extension in the url thing, I believe the turtle format is just an implementation detail of the POD. Maybe the POD you're currently using stores data in .ttl files, but other PODs may be using a triple store or other RDF formats. So IMO the proper extension to use for RDF documents is none. In any case, if you want to keep using a url with .ttl at the end that's fine, you just need to update the triple that was added on the profile and it should work (until I add support for pim:preferencesFile, I'm afraid there isn't an alternative).

In other apps, such as Umai, I am looking at the public type index as well. But that isn't implemented in this app yet. If you're worried about advertising the url of your private type index in the public profile, it should be fine as long as the document itself has the proper permissions. You'd only be revealing the fact that you have a private type index, which shouldn't be too problematic.

I'm curious, which POD provider are you using that created this profile structure for you? Or did you do it by hand? If there is some POD provider in production that creates this profile for users, maybe I'll prioritize getting this done. But if you just created this structure yourself, I don't think it's so urgent because users who are doing that can also amend the profiles themselves.

[hexagon6]

Hey Noel!

Regarding the creation of a new type index, when I read the issue before you updated it I was surprised because, indeed, it shouldn't be possible for the document to be overridden. If my apps are trying to create a document that already exists, what happens is they create one with the same name and add a uuid at the end. This is to prevent data loss, and as far as I'm aware there hasn't been anyone losing data using my apps. But if that were to happen, of course, I'd take it very seriously.

I apologize for making a false statement the first time. No data was ever lost and I was also wondering why I did not see my data anymore. In the end my algorithm for discovering preferencesFile did not recognize the privateTypeIndex entry in the webId document, as it expected it in a preferencesFile document, so if you know a better way to follow the graph, maybe I could improve to cover both cases.

The whole .ttl vs not specifying the extension in the url thing, I believe the turtle format is just an implementation detail of the POD. Maybe the POD you're currently using stores data in .ttl files, but other PODs may be using a triple store or other RDF formats. So IMO the proper extension to use for RDF documents is none. In any case, if you want to keep using a url with .ttl at the end that's fine, you just need to update the triple that was added on the profile and it should work (until I add support for pim:preferencesFile, I'm afraid there isn't an alternative).

Okay, cool. I never had the issue with the extension, will try to not use one at some point. Thanks for the hint.

I'm curious, which POD provider are you using that created this profile structure for you? Or did you do it by hand? If there is some POD provider in production that creates this profile for users, maybe I'll prioritize getting this done. But if you just created this structure yourself, I don't think it's so urgent because users who are doing that can also amend the profiles themselves.

I am hosting an instance of CSS myself (7.X), but started with 5 or 6 2 years ago, but don't remember exactly.

And yes, I did it all by hand, just following the spec draft as linked above. (as you know later I made a app to automate it with a click on buttons).

[NoelDeMartin]

if you know a better way to follow the graph, maybe I could improve to cover both cases.

The way I'm doing it, essentially I read the profile document and the "extended profile" (using foaf:isPrimaryTopicOf and foaf:primaryTopic, not the preferences file yet). But instead of paying attention to which document defines which triple, I just store all the triples together and then try to see if there is any triple defining the user's type index.

I think that's the best way of doing it, because it should cover all use-cases for people defining their type indexes in different documents :). The only thing I need to do in order to fix my apps, is to also look for pim:preferencesFile when I'm loading the extended profile.

[bourgeoa]

The whole .ttl vs not specifying the extension in the url thing, I believe the turtle format is just an implementation detail of the POD. Maybe the POD you're currently using stores data in .ttl files, but other PODs may be using a triple store or other RDF formats. So IMO the proper extension to use for RDF documents is none.

Well true for a machine there is no need for an extension at the end of a document resource name.
It is just a human user friendly way to tell to the user that it is most likely (not 100%) the contentType.

This is always the @timbl view to be as much as possible understandable both by human and machine and to try to map document Resource to file. The machine don't mind but human yes.

This is also why he has strong preferences to serialize as pretty turtle, what CSS do not do but PIVOT and NSS do

[NoelDeMartin]

Well true for a machine there is no need for an extension at the end of a document resource name. It is just a human user friendly way to tell to the user that it is most likely (not 100%) the contentType.

But that's the thing, how do you know that it is most likely turtle? If you are working with a specific server implementation you may know, but from the point of view of an application, you don't know what server the person is using.

And about serializing as pretty turtle, I'm not sure I agree with that either. I do agree about returning it as pretty turtle, but that doesn't mean the data has to be serialized as pretty turtle :).

In any case, websites nowadays don't use .html urls and I'm grateful for that, because whenever I have to type a url it's easier to remember without the extension. Same thing for document ids, if I have to type a document's url (for example, using Umai's viewer) it's easier to just ignore the extension.