Enhancing Table Schema with resource's rdfType and filed's rdfType-property


About the Rich Field Types of the “Table Schema specification v1.0.0”. There are a rdfType field descriptor, that must be the a RDF Class. It is not enough when we are using a relevant vocabularies, as Schema.org or Wikidata, that predicts class+property to get semantics…
Examples of fields and its descripttions:

  • person.csv table, column name: the file itself has the semantic of the class Person, so we can underline that name is a person’s name, but ideal is to use explicit reference, so a rdfType at resource. The field name in the context of Person class is exactly the property https://schema.org/name , so ideal is to assingn a property not only classes.

  • organization.csv table, column name: … same idea tham Person, see http://schema.org/Organization.

  • member.csv table, columns name and memberOf: the name field is the Person’s name, the memberOf field is the company’s department name.

  • … more examples at this datapackage.json, see url, about, etc.

Summarizing, it is a proposal to,

  1. add an optional rdfType in the resourse level, to be used as “default class” of all fields that has no local rdfType.
    It is like to use the Microdata’s itemscope/itemtype to define a context to many fields.

  2. add an optional rdfType-prop (or rdfProp) for property references in fields (or define the field value as a property).
    NOTE: when a field use both, rdfType and rdfType-prop, it is an usual specialization of rdfType (the class), as Schema.org do. When using only rdfType-prop, is the “usual meaning”, as https://schema.org/about or https://schema.org/url that not need a class to contextualize it.


@ppkrauss this is excellent! I fully agree that the current proposal is insufficient. However, is it possible for you to repost this question, exactly as is, to the specs issue tracker and, afterward, paste a link here?

I think this proposal has a much better shot of being answered there.

You may also leave a quick comment here, but your proposal deserves its own new issue.


Hi @danfowler, thanks!

To “plug” a proposal for enhancing Table Schema, I need to understand the roadmap and objectives of the Frictionless Data project… So, before specific discussions/proposals, I am only posting this issue at frictionlessdata/specs, to check your aims about semantic and dataset connectedness.


Of course! Thanks for your thoughtful consideration.