Hi there! We are a team interested in building a Solid app based on Solid principles, the use case and context is better defined in this post: Seeking Collaboration and Guidance for Our Conceptual SOLID-based Project. The thing is that for building that proof of concept, we have some doubts related with solid servers and custom ontologies.
We have seen that there are several approaches to the solid server (NSS, CSS, ESS, use.id, Trinpod, etc.). Which one better fits our needs for building a PoC? It would be useful at the beginning just implementing a simple flow:
Write to a pod
Read from a pod
Authenticate a user
Which programming language is more supported to develop the whole functional app within the PoC?
When it comes to trying to standardise the way individuals represent their personal career information, we have seen that there exist some ontologies like vcard, foaf or doac. What is the process of enriching those ontologies with our own proposal? At which point in development do you think it may have more importance? How is it the process of creating your own ontology?
In theory, the servers should work alike enough that it shouldn’t matter. In practice, there are still some important ways they diverge. Personally, I’d recommend testing you app against the https://solidcommunity.net server, to get a relatively stable environment (its behaviour hasn’t changed significantly over time) that’s also pretty representative of what many people will use.
As for programming language, the ecosystem has provided most tooling for JavaScript / TypeScript, so that’s probably the safest bet if you know it.
As for ontologies, I know people will have different opinions, but in my personal view, I’d just make something that works first. If you get to that point, you’re already way ahead of pretty much everything else, and whatever comes after (if anything) can make itself compatible with what you’re doing. So I’d just come up with new terms/URLs as you need them, without even going through the effort of creating/extending an existing ontology.
Servers : while ESS and Trinpod offer more features and security, they also have features unique to their own server so CSS may be a better choice for PoC - easy to setup, there are online versions, sticks close to current specs.
Ontologies: you should check out the WebID Profile Specification especially the shape section which covers some of the predicates and ontologies. Also, I am working in the Practitioners group to create shapes/ontologies for nonprofit organizations to describe themselves and to describe the services and products they offer. Builiding/expanding ontologies will definitely be a topic within Practittioners, as it is something we all face.
ESS using the Inrupt provided server may be the simplest, as you don’t have to go through the configuration of running your own server, and it has standards-compliant read write and authenticate. CSS is better for local development, as you can play with it yourself, though it has some drawbacks in the form of complexity.
The most popular language is Javascript, as that is what many servers are written in, though you can also use Python, Java, and Scala to some degree. Any language with a robust RDF and web capabilities packages should suffice.
For my development workflow I use constants rather than picking out an ontology initially. This may differ in a more professional workflow where you model a more specific domain. As I experiment, I change the information I record or need to convey and the relationships between it, then find a suitable ontology to match it. In a real app, you would probably want to pick an ontology that closely fits your requirements, and then apply extensions to it. Though, I know less about that.
I think one of the most common mistakes with ontologies is the idea that you need to pick ONE. Ontologies are meant to be mix and match. If there are several ontologies that each have some things you need, use them both! You can create shapes which basically describe which ontologies and terms are expected. Some tools - https://prefix.cc helps pair prefixes like foaf: with ontologies and Linked online Vocabularies which lets you search for terms.
For a uni project we’ve used NSS to manually test and develop all features and CSS for the automated E2E testing.
We encountered nearly no differences in the way our app works with NSS and CSS (except for CSS not adding a storage link to the WebID Profile per default, iirc). So for the programming part, it should make no difference between NSS and CSS (which is good, as it should be interoperable with any Solid server). However, some servers use ACL WAC (eg NSS and CSS) for managing access permissions, while others use WAC ACP (eg ESS), this is something you should be aware of (there is a library that tries to abstract this away).
For the developer experience, there could be some differences, as everything that’s not part of the Solid standards can be different. The main differences are the UI of registering and logging in, the default folders and WebID document when creating a pod. Depending on the setup, they could also serve different applications when you directly visit a document in the browser, but you can always use any application you want to manage your documents (such as Penny or SolidOS).
My advice would be, to pick one where you’re comfortable and from time to time test it with other providers too. If you have enough time to setup automated tests, maybe do manual development against ESS and automated E2E tests against a local CSS instance¹, then you would notice if your app works with pods using WAC and ACP or not.
It’s not important for the larger point, but to be accurate: Node Solid Server and Community Solid Server use WAC (“Web Access Conrol”, which is a specification that describes how to structure Access Control Lists, aka ACLs), whereas Inrupt’s Enterprise Solid Server uses ACP (“Access Control Policies”).
Just in case people come across this later and get confused.
I could suggest one of the ways to enrich existing ontologies:
Start with extracting terms of your subject area, their names as close to real names as possible, don’t think about existing terms in other ontologies (e.g. “Employment History” → “EmploymentHistory a owl:Class”)
When ready, make a dictionary part in your vocabulary Turtle file: connect your terms to the terms in external ontologies via owl:equivalentClass, owl:equivalentProperty, owl:sameAs, rdfs:subClassOf, rdfs:subPropertyOf depending on semantics of each case.
