Currently, due to the different emphasis and guidance following, the WebID profile initialized by different servers may not always be consistent. Some left different parts unspecified in the profile. Thus, some Apps may expect some “common” triples in the profile would not function correctly.
Some Apps will correctly handle these scenarios and fix that (e.g. write to the profile within the App’s logic). But this requires the App developer to be contious enough, which is rearely the case.
A typical example is the pim:storage which specifies the root of the Pod(s). The WebID profile created by CSS does not have it, which is in fact compliant with the spec: the spec says it SHOULD, but not MUST, be in the profile. However, most, if not all, Apps do require it.
It would make the situation much better if a library or App can be there for dealing with such cases. In particular, one can use an App (e.g. WebID-Fixer) to automatically “fix” the WebID profile and maybe Pod content (e.g. the preference file, type index) based on common expectations (or other alternatives, as options).
This could also deal with WebID standard updates. For example, a WebID profile created by an older version of service does not have type index, but at some point all new Apps expect type index.
It would be ideal if this is implemented as a library as well, so App developers no longer need to check these manually, but could just call a “check_and_repair()” function (or a wrapper function) and be confident to proceed.
can use an App (e.g. WebID-Fixer) to automatically “fix” the WebID profile and maybe Pod content
One important consideration here is that your WebId is not necessarily an LDP Resource and is not required to live within your storage; and will often be read-only.
For instance, WebIds issued by the Inrupt Podspaces deployment live at https://id.inrupt.com/ and can only be edited through the UI there. Whilst the user storage lives at https://storage.inrupt.com/.
So a library like this would be useful in the short term; we just need to make sure that applications still work if they cannot edit the WebId, and in the long term I would hope that the WebId profile spec removes the need for such a library.
Also note that it may not always be possible to automatically fix; there might be no way to discover the Pod root with a given level of access. The recommendation I’ve seen is to then ask the user to provide the URL of their Pod root, which is both terrible UX (in my opinion), and can’t just be done by a library. (And from that it follows that the same would hold for e.g. a type index, which can only really be created anew if the Pod root is known. And then there would still be access challenges, and needing to deal with the different authorisation protocols for Solid.)
So yeah, my hope would be that the spec does turn it into a MUST, or CSS users run into so many broken apps that it becomes a de facto standard and CSS does add it by default. And maybe for the standards to be more normative in general, or at least the different implementations to be more aligned.
Wait a second… This contradicts with my understanding, and I did not see this anywhere in the spec. Did I miss anything?
Sure. That is not really an issue. I reckon that automatically determining the Pod location in general may be an issue. The App does not have to be fully automated. Asking the user’s input is not a serious issue.
For library, maybe. But a similar way to ask for input is not a big issue.
Surely that is not ideal. But I would say it is A LOT better than unable to use Solid “at all” just because of incomplete/unexpected profile contents initialized by the Pod provider. The worst UX is unusable.
Thanks for bringing up the Inrupt Podspaces. I have very limited experience with it, and did not notice that. In that case, this is a problem; while on the other hand, the same/similar functionality should be provided by Inrupt’s UI to edit profiles. So, ironically, we will have such an App for Podspaces if it is the case.
In another case, where the WebID belongs to an advanced user (and the WebID is on an arbitrary location on the Internet), this should not be a problem at all. Advanced users always have their own ways out, and they will not need this App.
I like that too. But that requires quite a lot of steps, and I don’t feel it is something we will see in 0.5-1 years. This really blocks newcomers. Several people in our team faced with these kinds of issues I described, and that left really bad impressions.
Just to name a few things I feel needs to be addressed before that long term comes into reality:
Automatically creating and managing Type Index
And fixing inconsistency if by any chance
“Standard”/“Official”/“Reference” library support to retrieve content based on Type Index
A mechanism to “advertise” resources created and managed by Apps, without relying on modifying WebID
This feels to me a weird thing in fact, and has exactly the same result as using an extended profile. I do not really understand why modifying (extended) WebID profile is not an option for Apps.
It feels to me that most of them are not being worked on or widely discussed at all. Please let me know if otherwise, so the expectation of this “long term” can be shortened.
We do expect to include in the specification how a “fixer-app” should and, in some cases, must behave to create a full profile. Work on such an app is being carried on in the SolidOS group among other places.
I do not really understand why modifying (extended) WebID profile is not an option for Apps.
The whole purpose of extended WebID profile documents is for apps to write to them. Can you point me to where you got the impression they should not? Because that needs to be corrected.
It feels to me that most of them are not being worked on or widely discussed at all.
Take a look at the Webid-Profile Github Repo - lots of discussion and lots of people working on this. You’re welcome to join us, the kinds of questions you are asking are definitely ones that need answers.
What I meant to say is it is not necessarily an LDP Resource, does not necessarily live in your storage, and so cannot necessarily be modified in the same way as other RDF Resources according to the Solid spec.
I have edited my original comment to avoid confusion for newcomers to the thread.
To be perfectly clear, it must be an RDF Document (in particular a turtle serialization must be offered).
Ah, maybe I misunderstood. That’s further derived from jeswr’s reply above related to Inrupt Podspaces. It’s:
For instance, WebIds issued by the Inrupt Podspaces deployment live at https://id.inrupt.com/ and can only be edited through the UI there.
So, if an App cannot modify WebID profile, it will not be able to create an extended profile for itself. If it needs to “advertise” some resources it creates and manages, an extended profile must have been created already, otherwise unusable. We are back to the original question that WebID profile was not “correctly” populated.
In addition, this “read-only” leaves the situation that all Apps write to the same extended profile doument, which will be messy and involves permission issues…? Using separated extended profile documents would solve this, but that results in, well, bad UX if Apps cannot edit WebID profile – the user needs to return to the manage UI to add an extended profile for the App.
So, if an App cannot modify WebID profile, it will not be able to create an extended profile for itself.
This is absolutely a critical issue. My solution to this was to say that the ESS WebID document can point to a Solid Profile but is not itself a Solid Profile. In other words you go there, get a link to the actual profile which could be edited. It would mean another hop in the discovery but things could then work on both kinds of servers (with the WebID doc on a Solid server and editable or with it ineditable on a non-Solid server). My idea was painfully trounced in public (see https://github.com/solid/webid-profile/issues/40 for the gory details).
Basically, as I see it, “fixer apps” will not work on ESS and the only option is to ask the user to manually create a rdfs:seeAlso link to your extended profile document. Other solutions are incredibly messy. E.G. we could demand that there be at least one rdfs:seeAlso link to an editable document in all profiles and you could create a link from that to your extended profile document. But that means reading rdfs:seeAlso links inside documents obtained through rdfs:seeAlso links which becomes recursive.
PLEASE come to the spec meetings on Tuesdays and put this point forward. I have tried a number of ways to emphasize it, so far with no luck.