Column-Name Contracts

URIs are great for namespacing terms. However, the local names — after the last / — could be a free-for-all. One common convention — but not typically a contract — is to use upper camel case for rdfs:Class instances and lower camel case for rdf:Property instances. Is it useful to systematize the construction of local names? Emily Riederer argues yes.

I like her general approach, and I think her eight “level 1” measure types are nice examples that could be accepted without discussion by many teams. I often start “count of quanity or event occurrence” terms with n_ and “unique identifer for an entity” terms with id_ in my code.

A pleasant surprise was seeing a concept map at the end of the post, a boxes-and-arrows diagram to help illustrate the concepts from the post, which I have reproduced here:

concept map for column name
Concept map for column name contracts.

I would like to more formally represent the knowledge expressed in my writing. Step one seems to be to draw out a concept map. After this, I can translate such a diagram to RDF. In this way, I might build up a queryable knowledge base. Perhaps more importantly, I will encounter and hopefully overcome many obstacles to doing this effectively, including weaknesses in tooling.

To start, here is a tiny RDF dataset of the above concept map, serialized as turtle:

@prefix : <> .
@prefix owl: <> .
@prefix rdfs: <> .

:Dataframe a owl:Class .
:Column a owl:Class .
:DataType a owl:Class .
:Unit a owl:Class .
:Meaning a owl:Class .
:Name a owl:Class .
:Validation a owl:Class .
:Documentation a owl:Class .
:DataDictionary rdfs:subClassOf :Documentation .
:ERDiagram rdfs:subClassOf :Documentation .

:has a owl:ObjectProperty ; owl:inverseOf rdfs:member .
:shouldEncode a owl:ObjectProperty .
:canSupport a owl:ObjectProperty .
:shouldCheckConsistencyOf a owl:ObjectProperty .
:explainedIn a owl:ObjectProperty .

The most important aspect of this is that the URLs for the new vocabulary resolve. 😊