Basic Features Missing/Undocumented

Hi all,

I’ve discovered SOLID and it is quite an interesting concept.

It has quite a lot of similarities with SMART on FHIR in the health care industry.

But some things that seem missing or not very well documented, and if someone could point me to some more information that would be great:

  1. Interacting with a Solid server using REST APIs. I can make GET requests to publicly available information, but there is no way to grant access to a server and get a token (as is a common workflow) and make POST, DELETE etc requests.

    • An example use case is that I want to allow a system to update say health information in my pod after i visit the doctor.
    • Or, maybe i want to build a system where all my invoices are sent electronically to my POD. I won’t actually interact with the server, but it should be able to send me data. If i grant it access and permissions once, it should be able to continue updating my profile until i revoke its access.
  2. Why can i not log into this forum with my solid account?

    • How will the solid project get adopted if it doesn’t use it internally?
    • Seems like a no-brainer really.
  3. Why turtle? Even though it’s a good format, it’s too technical or difficult for many people.

    • It’s easy enough to learn, but i do think this might be just another hurdle for anyone learning about the solid project. Surely, for something as new and radical as the solid project, there should as few as possible hurdles for entry as possible.

Thanks

3 Likes

Hi @bobyblue and welcome, I’m not an expert in Solid but I’ll have a go at answering.

  1. You can give others (individuals, apps, groups) write access to files or folders (containers) on you pod, but I’m not sure if that’s the situation you are describing?

  2. Ideally the forum would be implemented using Solid, or you might be able to use the same login (ie your WebID), but Solid and Solid apps are at a relatively early stage in development so many things still have to be done.

  3. Turtle isn’t the only ‘serialisation format’, but the easiest one IMO (others will disagree) for the underlying data format which is Linked Data (aka RDF). RDF is a key innovation required in order to create the web of data (hence ‘Linked Data’), so there really is a good reason for using RDF and hence Turtle. The choice of Turtle is not really important to users who will normally interact via a GUI, and developers can always use a different serialisation format if they wish because one RDF serialisation can be converted to another. The Solid spec mandates that the server must always be able to handle and respond to requests in Turtle, while support for other formats is optional, but can easily be implemented within apps where a server doesn’t provide support by default.

Hope that helps.

1 Like

I think the answer to both 1. and 3. would be that you’d typically use a library that makes interacting with that easier. I have a tutorial in the works that should help getting started.

As for 2., while I can see how it would be useful, there are unfortunately still many other things which I’d consider even more pressing issues in terms of stimulating adoption - documentation being one of them, actually finishing up the spec another.

@bobyblue nice post! I totally agree with you on points 1&3, and I would like to think point 2 will happen at some point in the future.

Any complexities of Solid can easily be abstracted away by wrapper libraries; I’m not sure about the Solid browser, to me it feels like a paint-by-numbers when all I want is a blank canvas and some good quality paints and brushes. :smiley:

How to see the RESTAPI end points for solid server…! Is there any super access which is required for access restapi end point list