Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve Solid compatibility in WebID implementation #372
I've been looking into the experimental WebID implementation to understand how I can use this to demonstrate Solid applications using the SAFE Browser WebID drop down. I think I can do this without changes, but not in the typical way of Solid, where pod storage is present at the base URI of the WebID, and both storage and profile are accessed via paths based on the same subdomain and host.
For example, for the WebID
The experimental APIs cannot replicate this as things stand, so this issue is a request for these to follow Solid conventions (and so allow the above), unless there are good reasons not to.
At the moment I think the best I can do is to require Solid apps to use storage at a separate URI, which I think will work, but will not make as good a demo, or case for people to try Solid apps on SAFE. So ideally I'd like to try and replicate the above.
I've explained below, what I think the current implementation does, and the options for changing the implementation. I think the options are a) long term: include www service storage in a way that allows default APIs to follow the Solid conventions, and b) short term: fork the WebID Manager to create a Solid WebID manager that I think will allow the behaviour, while bypassing the RDF serialisation we have right now.
I'd appreciate feedback on the following, advice and suggestions for alternatives etc, before I embark on the option b) above
1) Current Experimental WebID Implementation
If the WebID is present, it will have as its service container a Mutable Data containing RDF, which is incompatible with the SAFE www service. Instead:
Long Term (option A)
To support storage based on the WebID URI itself would need the current implementation to change so that the storage for a web service and for the WebID profile use a common approach. This would mean that the profile document would appear within storage located at the URI of the hostname used in the WebID, as is the convention with Solid (e.g.
2) Bypassing the Experimental WebID Implementation
If there were both WebID and normal public name entry using the same name (e.g.
Short Term (option B)
So I propose making a WebID is changed to create the RDF entries as now and create a regular public name and 'www' service on the same name, then store the WebID profile as an NFS Turtle file in the www container. Then I think this implementation will be able to follow Solid conventions. If so this would be a useful short term way to demonstrate maximimum compatibility with Solid UX and applications, pending changes to allow this in the exising WebID/RDF serialisation APIs (option A).
Note: I've assumed that the SAFE Browser WebID drop down feature would not be broken by the presence of both a regular public name and a WebID using the same name, and have not looked into that. I think that provided we keep both copies of the profile in step, there should not be an issue (so ok for demos and Solid developers wishing to evaluate SAFE). Any comment on this would be useful.
To achieve this interim solution, all that I think is needed is a fork of the WebID manager and calling it a Solid WebID manager to reduce confusion.
I'm not entirely sure option B) will work, so would appreciate some eyes on the idea before I test it out, and as noted welcome any comments and feedback, and corrections.
The way we imagined back then when we started with the PoC of WebIDs was that:
Thus, if you try to fetch
Thanks @bochaco that's very helpful. Assuming those changes are months away, in the interim do you think option b) will fly? I'm not planning to implement that initially, but it would be good to have it sanity checked while I do the other approach (NFS storage on a separate NFS URI).
EDIT: can you explain why you are creating entries in both
If I understand correctly, you plan to serialise a WebID and store it as an ImmutableData file using the NFS API, and map it to a subname/service name?
If so, yes I'd consider it a valid path, moreover, I'd consider it not only in the short term, it's just about the use case. If you think about it, the only difference there with what I described (apart from the new data types and RDF representation of this data) is that your WebID cannot be edited that's all, well, you can by uploading a new ImmD file and update the NFS entry, while in my description you'd edit the WebID profile doc itself and therefore wou'd be able to version it and so for. What I mean is that in the future different tools may implement different ways according to what they try to cover, if I want to be able to have versions on my WebID profile doc I won't use this approach you are going for now, but other may prefer that for XYZ reason...?...
The _publicNames is your private inventory of public names you own, so you can find them even if you forgot you created them.
@bochaco Thanks for the explanations, helps a lot. BTW my short term plan is only meant as a way to get the feature working for demos and evaluation. I don't see a reason to have multiple mechanisms at this time, so once the RDF APIs support storage as you anticipate I'd go back to using that.
Do you think that my creating a regular public name as well as the existing RDF API WebID would still allow the WebID browser drop down to work properly? From the sound of it so long as I am not messing with the entries in
I think you may not need to do much really, if you take a WebID doc, serialise it with ...Turtle? I think you like it :D , then you store that turtle file as a text file using the NFS API with the path
Yeh, I was already happy with that part. My question relates to not wanting to break the Browser WebID UI or the WebID API by adding in a public name entry alongside the one for the WebID.
So my forked WebID manager will do what the WebID manager does now, and create a public name identical to the name of the WebID (as well as adding the duplicate profile as you just described).
I can't see a problem, but was asking if you think there's anything that might be broken by having WebID RDF entries and regular public name entry in
Don't worry about digging further, I will do a test when I get to this, but will start with separate storage and implement this later.
ahh I'm sorry, we tried to make the code to support entries in _publicNames which are not RDF, this is how we assured compatibility with what WHM creates, so it should be fine, in fact I think what you'd be doing is the same as WHM does, so all good.
I also was thinking you could even use the WHM to pusblish a WebID in this form, create a text file with the Turtle and upload it as part of a website with WHM, if you then try to fetch it with the browser it should offer you to download the Turtle file (it won't recognise it as Turtle but just as an octet stream).
I've coded the support in a fork of
I see that to publicise the storage URI (e.g. using
If I add support for 'storage' in
I'm wondering how the approach might / might not change going forward, in order to provide a simple API without limiting it to a small subset of what might be held in a WebID profile. Is it always going to be either a fixed set of properties on a JS profile object, or go directly to RDF? Or do you anticipate a more flexible but still simpler API (than the RDF emulation)?