Open KyraAssaad opened 3 years ago
Here is my preliminary list of acronyms and common terms to include, please add any I've missed:
CSS. ESS. NSS,
Solid, WebID, ACL, WAC, OIDC, TLS, CORS,
RDF, JSON-LD, RDFa, N3, N-Triples,
Pod, LDP, LDN, PR, issue, WiP, DEI,
triple, quad, subject, predicate, object graph,
ontology, namespace, prefix,
resource, container
Maybe add common ontology prefixs like FOAF or PIM?
Spec, Auth, Authn, Authz, DPoP, URI, IRI, JWT, dcterms, OWL, REST, SPARQL, ttl, SSL, SSH, kb, wss, npm, git, curl, fs,
...
if this is too general (not Solid-specific) excuse me, I just made a brainstorm.
That's great Mathias - you definitely caught some that belong in the list. When I see how many terms there are in total, I can begin deciding if some are too general. But best to start with a big list , so thanks!
Server, Server implementation, Tech stack, public/private keys, library, W3C, X.509 Certificates, Cert Ontology, Vocabulary, Certificate Authority, Basic Access Control Ontology, Identity Provider, webhook, user-story, Turtle, Social working group.
Vocab, knowledge graph
Linked Data, Semantic Web
Maybe ACP?
Just adding this here as an example because I really like it, maybe we could sometime attempt to do something like this?
Nice example, @VirginiaBalseiro, I am starting to categorize the terms into things like Identity/Semantics/Servers so the terms appear in the context of other related terms. There may need to be two separate pages - one a quick-lookup page where you just want to know what LDP stands for and move on and a more detail page similar to that example with diagrams and a narrative flow rather than a list. Both kinds of pages are, I would think, helpful to beginners.
solid-namespaces has some additional acronyms on the documentation.
Potentially also useful: https://docs.inrupt.com/developer-tools/javascript/client-libraries/reference/glossary/
Could we transpose this list to a public Roamresearch page for Solid?
Here is my first go at an acronyms page. I am working on some ideas for diagrams for each thematic section. I'd appreciate any and all feedback. I'll also need help in providing the links for "basic activities" and "deep dives" - I see this page as a springboard for both beginning and advanced users.
Thematic Index
Alphabetic Index
To Be Done
Solid gives you control of your personal data by letting you store it where you choose; by enforcing your ability to manage who accesses it; and by not requireing use of large centralized sevices that have their own data agendas. At the center of Solid is your Pod.
A Pod is a personal on/offline data storage space that you control. When logged in, you can modify the data and make any part of it private, public, or available to specific audiences. Personal data includes things like social media postings - in Solid, those belong to you, not to the social media company.
A Pod Provider is a host service that provides you Pod storage space and maintains Solid Server software that enforces the privacy rules you have defined. You are free to switch pod providers at any time.
A Self-Hosted Pod is a pod that you install and host yourself. It may either be totlly private or public-facing with access rules you set.
A Solid Server is the software used to provide access to Pods. It is maintained by the Pod Provider, or by you if you self-host. In either case, it enforces the access rules you set for your own Pod and serves your data in a way that makes its semantic relationships accessible.
Current implementations of Solid Servers include CSS - Community Solid Server, ESS - Enterprise Solid Server, NSS - Node Solid Server, the Trinpod Solid Server, the Nextcloud Solid Server and the PHP** Solid Server. Each server has its own features but all should follow the basic Solid rules for access control and semantic linking.
Solid Servers are organized using portions of the specifications for the Linked Data Platform (abbreviated LDP). One of LDP's organizing principles is containment - a Container contains Resources. You can think of a container as a folder and a resource as a file or sub-folder, but they could be implemented as a database or other mechanism rather than on a physical file system and can, unlike the file/folder analogy, have [semantic relationships]((#semantic_linking) other than containment.
Solid provides single-sign-on without tying your sign-on to an email provider or social media company. Your WebID is your passport anywhere in the Solidverse.
A WebID is a universal identifier that uniquely identifies you wherever you go. After getting a WebID, you can login once and have that login and WebID recognized anywhere that uses Solid. It's easy to have more than one WebID and they are anonymous by default.
An IdentityProvider, abbreviated as IdP is a host service that provides Solid identity authentication. When you register with an IdP, the IdP assigns you a WebID. Each time you login to the IdP, you are authenticatd as owning that WebID. Identity Providers are also often Pod Providers but it does not matter if you get your WebID from one provider and store your Pod data with a different provider.
Advanced terms : OIDC (OpenID Connect standard), DPoP (Demonstration of Proof of Possession), JWT (Javascript Web Token). See deep dive for details.
Solid gives you the ability to limit access to specific parts of your data. You control not only who can read your data, but also who can collaborate with you in creating and editing shared resources.
An Agent is a person, social entity, or software requesting access.
An Access Mode is a permission to read, create, modify, or share data. For each resource in your Pod, you can specify which Access modes you grant to specific Agents or classees of Agents. The roles below explain some of the basic options.
Role | Access Modes | Access Granted |
---|---|---|
Owner | Read + Write + Control | can read, write, and control sharing |
Editor | Read + Write | can read and change information |
Poster | Read + Append | can add new information, and read but not change existing information |
Submitter | Append | can add new information but not read any |
Viewer | Read | can read but not change information |
Solid is not just about storing data, it is about linking data from different sources in ways that usefully enhance our understanding of the data.
The Semantic Web is a web based on Linked Data - meaningful relationships between resources. The link between the pages "The Color Purple" and "Alice Walker" is not just any link, it is an authorship link that holds meaning.
RDF (Resource Description Framework) is a language for describing the semantic web in ways that both humans and computers can understand. RDF can be represented using a number of syntaxes including Turtle (Terse RDF Triple Language), JSON-LD (JSON for Linked Data), RDFa (RDF in HTML attributes), N3, and others. OWL (Web Ontology Language) is a language to create RDF vocabularies. SPARQL (SPARQL Protocol and RDF Query Language) is a language to query RDF data sources.
A Triple is an RDF statement. RDF statements take the form of short sentences asserting that thingA is in some relationship with thingB. Each statement (triple) has three parts : a subject (thingA), a predicate (the relationship), and an object (thingB).
RDF Triples may be grouped together in a named graph. A triple with the URL of the graph it occurs in is called a quad.
s/RDFa (RDF in HTML attributes)/RDFa (RDF in markup languages)
This sooner this can become a PR, even a Draft PR, the better. Collaborative content creation and editing does not work well in issue comments!
Consider PR to solid/solidproject.org (and published at /terminology
?)
It'd be great to have the document human- and machine-readable. Consider using HTML+RDFa with SKOS eg. https://solidproject.org/TR/protocol#terminology , https://solidproject.org/TR/wac#terminology for the concepts / concept schemes..
(I'd prefer it be published at /glossary
, but /terminology
would be livable.)
I also prefer glossary. This is intended to be an onboarding path for newcomers, not a technical last word on proper terminology.
I thought of "vocabulary" but that would cause confusion with ontologies.
glossary is even better!
naming things is hard but they can also be fun when people agree :)
@aksanoble @jeff-zucker @ewingson @bourgeoa As much as "acronyms can be a barrier for entry and understanding to newcomers", so too are multiple options.
I'm back to Solid after a long absence. Two years ago there was just the NSS (if I remember correctly). I had trouble getting a NSS server up and running back in 2020 but eventually I succeeded. Now there are more choices. This week I initially jumped on CSS which I then jettisoned when I couldn't by default reproduce the multi-user feature that I remembered from NSS (and that is obviously an option with NSS).
Thanks to @bourgeoa Alain Bourgeois's reply to my comment about a 502 Gateway issue, and his help on Gitter, I'm a little clearer on what's possible and preferable.
Perhaps there should be not just a glossary but a recommended on-boarding path, e.g., first start with ... then ... or ... skip NSS and go straight to CSS.
Anyway, several days of grappling with error messages led me to this issue so I figured I'd add my two cents for what they're worth.
@aksanoble
Sorry to have not seen your comment earlier. Others share your concern for building an onboarding process. You might want to talk to @YetAnotherJonWilson who is leading an effort to consolidate onboarding materials for app development and your input would be welcome.
Hello @aksanoble ,
Yes, as @jeff-zucker mentioned, I am trying, but in the very early stages, of creating a good resource for newcomers, for getting started (whether using a Solid pod, building apps, or running a server), and for documentation more generally. We have a repo (at https://github.com/solid-contrib/getting-started), and I've created a Readme there that outlines the goals of the project.
The project is currently hosted as a Github page, but it doesn't yet have links to documentation, just an outline of next steps for getting started.
The next step for the project is to create an organized and filterable list of links to documentation. And then to begin the real work...iterating by adding to the list while making it more interactive and useful for both getting started, and for finding the right docs for working in any part of the Solid stack/ecosystem.
At the same time, I'd like to make it simple for anyone who's interested to be able to join the project itself. Eventually, we can create "good first issues", and things like that. Until then, please feel free to send me a message, watch the project, read the Readme--everyone who has an interest in this topic is more than welcome to join, and I'll try to make it easier to contribute as we get going.
Hope this is helpful!
Hello all,
I have been following Solid for a long time. Your approach to use the Diataxis framework seems very interesting.
My actual occupation does not allow me to spend much time in helping out but all information is welcome to digest the many possibilities and I will keep monitoring your development.
Sincerely,
Dick Van Gelder Secretary General World creators Society www.creafree.org
Hi, is there an update on when the glossary will be published?
Hi, is there an update on when the glossary will be published?
The Team is in the process of revamping solidproject.org and I would expect the glossary to be implemented alongside or soon after that happens, probably sometime this fall.
Hi @DickVG, thanks for the feedback, I'm still in the early phases of the getting-started project, but I'm excited about applying the Diataxis ideas, they make a lot of sense to me, so we'll see if I'm able to apply them to Solid in a useful way.
Client-to-client standards, client-to-server standards, and server-to-server standards
Some of the feedback we've received in the survey state that the acronyms can be a barrier for entry and understanding to newcomers. The DEIT Chairs suggest creating a glossary of common terms and acronyms, and pinning that to the top of the forum for easy access.