What would be the expected behavior if some of the expected triples (for whatever reason, might be for eg that user has deleted it himself) is missing.
For example, my application needs a link to preference file, and let’s say that the link is missing from the user’s profile. Should I just inform the user about the problem and that is it, or should my application try and handle this problem and “repair” user’s pod?
on the above mentioned page, the writer talks about things like: owl:sameAs and rdfs:seeAlso links
I didn’t quite understand what those are, I mean, I know what same as and see also means, but I didn’t quite understand what info these links are providing. What should my app do with them?
A small question for clarification:
we have public type index and private type index, as it comes from the names the app should link to public data in public type index and to private data in private type index.
I would guess that so called “shared data” ie, a data that some set of users can access, is still considered to be private data? Am I right?
Thank you in advance
A team of us is in the process of re-writing that document and should have a draft specification out for review next month. This new spec covers exactly the questions you ask.
Most apps should not have read/write/control over the user’s extended profile, only a few trusted apps. Those apps that have the control and are trusted SHOULD repair a broken profile, e.g. supply a preferences file if missing. The spec will explain how to do that. The SolidOS databrowser is being patched as we speak to do that.
We will be dropping recommendations about owl:sameAs, but keeping rdfs:seeAlso. It is useful for exactly the situation you mention in question #3. Restricted information that should be available only to a named set of agents should go in a see:Also file. So suppose you only want some people to know your phone number. In your profile you have an rdfs:seeAlso triple pointing to a file with the statement <#me> vcard:phone "MYNUMBER". in it and then restrict access to the seeAlso file (using ACL) such that only the agents you want to can see. Now your phone number is in your profile but only the people you want to can see it. The way an app is expected to treat the seeAlso file is this - treat all triples that have the WebID as subject as if they were written in the main profile document. Other triples can be use but it is not a requirement of the spec that they be used.
See answer #2.
Great questions, if you have more , keep 'em coming.
The word “private” in private TypeIndex means "only an app authenticated as the WebID owner themselves can see it. For restricted files - ones that a named set of agents can access but not the public, see above about rdfs:seeAlso.
Another use for rdfs:seeAlso is the ability to organize your profile. Instead of putting a bunch of foaf:knows triples in the main profile, you can create friends.ttl that has all of your foaf:knows triples. That way you have a separate friends list usable for other purposes. When you use <#me> rdfs:seeAlso <friends.ttl>. in your profile, that alerts apps to include the foaf:knows triples as if they had been put in the main profile.
Thank you very much, as always your answers are very clear and detailed, I appreciate the efforts you put.
I have some further questions based on your replies:
as I understood (correct me if I am wrong) while solid:publicTypeIndex would point to a file, that lists links to files with data and the data is strictly public.
so it will contain a triple like: {someUserUri}/settings/publicTypeIndex.ttl schema:TextDigitalDocument {someUserUri}.{filename}.ttl
now if my app needs to store a file, that only user himself would have access to (and as you have mentioned apps that the user has granted permission to) would be able to see it, I do the same thing but store the link in privateTypeIndex
So, that technically means, that there are separate files that contain all the links to both public and private type of files.
Now for the restricted files we use, we would have in the user’s profile itself a triple of the form: <#me> rdfs:SeeAlso {someUri}.{somefilename}.ttl
before I say what bothers me with that approach for the restricted files, I will explain what functionality I plan to implement in my app for the context:
The user will be able to create a data entry, for simplicity, let’s say that it will a text note and the user will be able to set an access type to that note, choosing between private, public or shared (sharing will be implemented by choosing from the user’s contact list)
now the problems that I see:
If the user will create a lot of notes with “shared” access, it will pollute the user’s <#me> file, as it will be stacked with SeeAlso links.
his data won’t really be reusable by other apps, as (unlike in the case with public and private type indexes) the app doesn’t know what is the data type stored in these seeAlso links and thus will have to fetch every single one and check if it is of a type that it needs.
I can create a file similar to publicTypeIndex, but for the restricted data, but then, other apps wouldn’t know what exactly this file is about as it is not a standard.
you mention SolidOS as an app that will have that “repair” functionality in the future. Is there some existing app that already has this kind of behavior?
As I want to give a user a link to fix the issue, rather than leaving him with an error message with some content like: “Error your POD doesn’t have a link to preferences file”
You haven’t quite got the syntax of the typeIndex. It’s also important to know that it can point to containers or files. So a typeIndex can contain statements like these (there is no subject, they should be blank nodes:
[] a solid:TypeRegistration;
solid:forClass vcard:AddressBook;
solid:instance </public/contacts/myPublicAddressBook.ttl>.
[] a solid:TypeRegistration;
solid:forClass bk:Bookmark;
solid:instance </public/myBookmarks/>.
The first looks for all things in the class vcard:AddressBook in the named file. The second looks for things in the class bk:Bookmark in the named container.
So, rather than naming individual resources, you can point to another file which names resources or to a container containing resources and no individual pointers to resources need “pollute” the main profile.
In your example you could put a pointer for something:Note as the class stored by your app and any apps capable of handling something:Note can reuse the data there if it is accessible to them.
You would not store the access information about individual notes anywhere in the profile. It would be stored in the .acl file for the note. Apps that find from the publicTypeIndex that notes are stored in your container still are not guaranteed that the resources in the container are accessible - only that they might be accessible. You have to query the actual resource to know what right you have to it. The only things that would go in the privateTypeIndex are things that only you can access.
I think the next release of SolidOS will have at least the preferenceFile fix, so your warning to users could certainly mention it.
I think you have pointed out the need for us to clarify the terms publicTypeIndex - for data that is potentially available to people other than the WebID owner and privateTypeIndex - for data that is only available to the WebID owner. The data in the publicTypeIndex can have restricted access or fully public access.
