Make decisions regarding default vocabularies for footprints

@RubenVerborgh wrote:

Long term

Since we’re using Linked Data, in the long term, whether data pods use foaf:name , vcard:fn , or schema:name shouldn’t really matter.

Current issue

However, in the short term, app developers need clear expectations about what kind of properties to ask for. If one application writes foaf:name , another reads vcard:fn , and a third writes schema:name , not only will we fail at interoperability, we will also have data inconsistencies.


Having a default choice is important, because while everything is possible, only one thing can be made easy. E.g., in a JSON-LD context, there can only be one firstName ; the rest will have to be prefixed names or fully qualified URLs. So which one should it be? Since the dev kit is starting to take shape, this discussion is becoming urgent.


This decision might need to be made per domain, i.e., different for people, photos, etc.
Maybe a good first question is how to model profiles. I see three broad choices:

Call for input

Good arguments can be made for each one, and please make yours below (I will). But the more important one is that we make a decision and document it.


In LDflex for Solid, we currently support;


However, there can only be one name :


and this currently is .
But what should it really be?

There has been some discussion on with @csarven, @codenamedmitri, and @kjetilk and would like to invite more here.


Any consent on this? I guess not :slight_smile:

Right now I am looking for the “right” way to label my items (either RC models or geographic locations).

This topic mentions foaf:name, vcard:fn and schema:name. But what about rdfs:label ( and dcterms:title(

It really is a jungle, trying to find standard ways of describing resources. What about, for instance, related photos of an item … a thumbnail, a preview and the full size? Or a comment about something, or a description of an item?

1 Like

And a follow up on the above, should anyone look for inspiration, is a great place to find standards for al sorts of “things” one might want to store, which seems a bit better or just more concrete than using the abstract dctertms.

Can’t we have here a fallback system? First try foaf, next try schema, next try vcard. And ideally you can configure that yourself. That’s how I would write my SPARQL query if I know that multiple ontologies can be used.

Important to note here is that there no “right” away in any case. In the sense that it’s the right way for everybody. It’s all fitness-for-use.