# 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:

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 : <https://ns.polyneme.xyz/ark:57802/2022/01/dwi/cnc/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

: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 .