Solid-client-authn-browser and vocabs list

1

HI playing with solid-client-authn-browser, i’m searching for the vocab to get user sorage :
but i can’t find : SOLID.storage ? PIM.storage SPACE.storage? in which vocabulary ?

vocab-common-rdf A library that provides convenience objects for many RDF-related identifiers, such as the Person and familyName identifiers from the Schema.org vocabulary from Google, Microsoft and Yahoo!
vocab-solid-common A library that provides convenience objects for many Solid-related identifiers.
vocab-inrupt-common A library that provides convenience objects for Inrupt-related identifiers.

is there a list of vocabs and what the offer ?

2

Hi @Smag0 - yeah, the vocab I think you’re looking for is the Workspace Ontology (namespace http://www.w3.org/ns/pim/space#), and Inrupt provides JavaScript constants for it’s terms within the @inrupt/vocab-solid-common bundle, in the WS class
The README for each of the vocab bundles we provide lists the individual vocabs bundled up within them, although in this particular case, I can certainly see how you’d find it difficult to know that the vocabulary you wanted was actually using the ‘ws’ prefix, and was in fact the Workspace Ontology (as opposed to the PIM Ontology, or the SPACE Ontology, or the STORAGE Ontology, etc.).
Just to note on that particular vocab too - we at Inrupt added just a couple of minor extensions to the published vocab, since you might notice that the original is missing rdf:type rdfs:Class triples on a number of classes. So for example, our Inrupt WS.js class does in fact include terms for those vocabulary classes (e.g., on PrivateWorkspace, PublicWorkspace, MasterWorkspace, etc.).

1 Like
3

thxs but could you please point me the repo as the https://www.npmjs.com/package/@inrupt/vocab-solid-common does not give it

i have another question, in the node_modules/@inrupt i have two quite similar folders :

  • vocab-solid-common
  • solid-common-vocab

is it normal ?

4

Sorry @Smag0 , but I don’t follow you - @inrupt/vocab-solid-common does contain the Workspace Ontology, for example:

npm init
npm i @inrupt/vocab-solid-common

…and then creating a trivial index.js file:

const {WS} = require("@inrupt/vocab-solid-common");

console.log(`Term: [${WS.storage}]`);

…displays:

$ node index.js 
Term: [http://www.w3.org/ns/pim/space#storage]
$

With regard to your question about the use of -common, yeah, unfortunately that usage is confusing, and we plan to change that. The word ‘Common’ is meant in two different contexts, e.g., common as in common (or popular) RDF vocabularies, and common utilities as in common across multiple packages. Historically these vocab bundles had a different (non-‘common’-based!) name.

5

thxs, it’s ok for the WS.storage, i know how to use it,
but not really for the doc, I don’t want to ask each time on the forum what vocab must i take for PublicTypeIndex, Inbox or other common things, is there a clear enum of all of them ?

6

Hi @Smag0 - ah ha, so now I think I understand what you were asking, and that’s really good feedback.

The previous iteration of the Solid spec referred to the WebID Profile specification here, which I assume you’re already familiar with, since you reference a few of the terms referred to in there.
We should definitely make sure the new Solid spec explains the relationship between vocab terms used in our specs, and the vocabularies from which they come.
I think perhaps the issue you’re facing is caused by people very familiar with RDF (i.e., the Solid spec authors) taking a little bit too much for granted - i.e., that someone seeing use of a term like http://www.w3.org/ns/pim/space#storage will automatically know that that is referring to the storage predicate defined in the vocab with namespace http://www.w3.org/ns/pim/space#, and so they’ll know to dereference that namespace IRI if they want to find out more about that vocabulary, and expect (hopefully!) to get back descriptive meta-data about that vocabulary (in at least ‘readable’ RDF, but perhaps nice friendly HTML).
One middle-ground approach I’ve seen commonly is for specs to at least list out the vocabularies they refer to (e.g., like here for the GConsent vocabulary).

That still isn’t the clear enumeration of individual classes and properties that I think you’re asking for though, and it also doesn’t help with the question you raise of, “What is the JavaScript classname I can expect to see this particular term defined in, and in which published vocabulary bundle might that JavaScript class exist?”.
I’ll take your feedback to the current spec authors, and see what they think about incorporating a bit more information to help close that (now obvious!) gap.
The only guidance I can offer you right now is that the JavaScript class names that Inrupt provide use the upper-cased vocabulary prefix (e.g., the FOAF vocabulary is in a JavaScript class named FOAF (because the commonly used prefix for FOAF is foaf:), the LDP vocabulary is in a JavaScript class named LDP, etc.), and that Inrupt currently only offers 3 vocab bundles, one for ‘common RDF vocabs’, one for ‘Solid-related vocabs’ and one for ‘Inrupt-specific vocabs’, so hopefully it’s obvious which bundle contains what (although the Workspace Ontology is a great example of potential confusion - i.e., is it Solid-related, or just another Common RDF vocab? I’ve only ever seen it used within the context of Solid, so I put it in the Solid-related bundle, but arguably it should really be in the Common vocab bundle!).

1 Like