Inrupt common vocabularies returning undefined

I’m trying to build a Solid app that reads and writes data to pods, and I’m using the vocab-common-rdf and solid-client libraries to do that.
The problem is that vocab-common-rdf returns undefined values for certain properties(for example VCARD.givenName), and there’s no documentation at all to understand what I’m doing wrong. If I try typing the URL in maunally(, I get an invalid URL error.

Hi @nicomedia,

So yeah, I think the problem is that the term in the vCard RDF vocabulary has a ‘minus-sign’ (or hyphen) in it’s name (i.e., ‘given-name’), and of course that character is not valid in a variable or object property name in JavaScript, which is why our generator converts it to an underscore instead.
So if you try VCARD.given_name (with an underscore instead of a hyphen) it should work fine for you.
Thanks for the feedback on the lack of documentation to highlight this general issue though - we’ll look into fixing that (although if you’re using a modern IDE, then typing just VCARD.give should have prompted you with the code completion option of VCARD.given_name) :slight_smile: !

BTW, I don’t know what you mean by “typing the URL in maunally (sic)” - can you show a quick code-snippet of what you were trying exactly (as the string value for the term you provided is indeed correct)?

Hi, I mean using a string with the URL instead of the convenience object, so for example instead of typing this:

let something = getStringNoLocale(profile, VCARD.given_name);

I use this:

let something = getStringNoLocale(profile, "");

I solved the problem by typing the URL out, it probably was a cache problem with the browser, but for some fields, for example the uid field in vCards, it still won’t work, so for now I’m stuck using URLs.
I use VS code and it’s not giving me suggestions, should it?

Hi @nicomedia,

So firstly, yeah, VS Code indeed isn’t picking up code completion suggestions for terms in a vocab (we tend to use IntelliJ, and it works fine there, so we never noticed this problem!). We’ve a fix for that already - so it’ll be in the next release of the bundled vocab artifacts.

But basically the names of all constants in the vocab classes that we generate will always match precisely the term names in the original RDF, except of course if the RDF term name happens to be illegal as a variable name in the programming language you’re working in. So for example, in Java or JavaScript, all hyphens that appear in a vocab term name will be converted to underscores to make them valid variable names. Terms that are default keywords in the language (like ‘const’, of ‘if’, or ‘class’, or ‘export’ in JavaScript) will have an underscore appended to the variable name (so, they’ll become ‘const_’, ‘if_’, ‘class_’ and ‘export_’ respectively).

So secondly, we’re actively updating our documentation to explain these issues - so hopefully these things won’t trip people up in the future.

As for the ‘uid field’ in vCard, do you mean ‘hasUID’? VCARD.hasUID works fine (i.e., there is no ‘uid’ term in the vCard vocabulary, that I can see anyways. If you do really mean ‘uid’, can you link to a reference (or even just a screenshot)?)

So I’d generally only use a term’s full IRI as a string as a last resort. Our generated vocab classes do include a convenience function to at least provide you with the vocabulary namespace part (called NS()), so your example could have been shortened to:

let something = getStringNoLocale(profile, VCARD.NS("given-name"));

This makes your code more readable, but also, it can be handy if, for instance, a new term is added to an existing vocabulary, but we haven’t published updated versions of our generated vocab bundles yet. So if vCard added a new term for twitterHandle tomorrow, you could use that new term in your code today by simply using:

let something = getStringNoLocale(profile, VCARD.NS("twitterHandle"));

Hopefully that clarifies everything for you - and thanks so much again for the extremely helpful feedback.



Hey all – as an FYI – the docs have now been updated to explain the naming scheme.

As Pat mentioned, the next release of the bundled vocab artifacts should have the code-completion, so that people don’t have to look at the dreaded documentation :grinning_face_with_smiling_eyes: