So I’ve been interested in this concept ever since my career started in software development. I’m so interested in building POD software in PHP and am just having a hard time with finding data about the requirements for creating a POD implementation.
How I will introduce PODS to PHP
I just need some help being pointed in the right direction to get started on gathering requirements for the POD software I’m building.
Ontowiki is a semweb application in PHP. Just my 2¢, but if someone could adapt it to Solid that would be awesome.
So, I definitely appreciate the link. I took a look, but am missing a huge chunk of knowledge that is keeping me from understanding how Linked Data and Solid Apps are supposed to work together?
I understand there is a set of objects/structures that Solid Apps will rely on, but I’m missing the standards that define these data structures and which ones are aloud to exist. Can someone help me with that?
You might already know, but there is a lot of information at https://github.com/solid/information . The standards for data interoperability are still being defined in the data interoperability panel, which is at https://github.com/solid/data-interoperability-panel . You might want to join there to get the latest info.
Yes! This is helpful! Where I’m having a problem is what is the pod server expecting to return, and what is the standard url structure?
Sounds like what you are looking for is in the Solid spec and the related LDP (Linked Data Platform) spec.
Unless… you are wanting to know what the structure of the pod storage itself should be? The latter isn’t specified AFAIK (though in the past there were some guidelines, I think these are no longer current). So you will find some conventions, such as a top level folder called ‘public’, but that is not mandatory.
One way to explore what the structure of a pod might be would be to look at example profiles. A profile is an RDF resource which says things about a particular entity, referred to by its WebID. The profile is the document retrieved at the URL of the WebID, and you find information about the entity being described by de-referencing the ‘#’ fragment part of the WebID.
So if my WebID is ‘https://thewebalyst.solid.community#me’ you’ll find a profile document (in RDF) at https://thewebalyst.solid.community and information about me at the node in the document referred to by the ‘#me’. Along with information about me, there may be information about where I store my data is stored. You may or may not have access to that - that will depend on what permissions I have set for the storage in my pod.
Hope that helps a bit!
It’s starting to…
So If I want to build a pod and all of my responses are JSON-LD format, is that compliant with standards?
To implement a POD you follow the Solid spec (this is being refined right now and you can follow that process here https://gitter.im/solid/specification), and which makes use of LDP.
For most LDP responses you must provide at least Turtle, with other serialisations optional and made available if the client asks for them, although there are some exceptions which require a response in JSON-LD. I might be a bit wrong there, often happens 
, so don’t take that as gospel. I always struggle reading w3c style specs myself and its a while since I looked.
I’ve been implementing a small subset of LDP as a client side emulation (JS in the browser) rather than implemented a pod server, so there are large parts of the spec I haven’t looked at thoroughly. I found it easier to look at the code for node-solid-server and follow that, but this of course is not definitive and may not be compliant (almost certainly isn’t in some areas!).
With apologies for necro-bumping this thread, but for the sake of completion: we are working on various implementations of Solid Servers in PHP under PDS Interop · GitHub (Standalone PHP and Nextcloud already implemented, others planned for the future).
Server-side components have been created in separate packages (adhering to PSR-7 standards and using FlySystem for filesystem interactions) which should make it easier to understand and (re)use our code.