Free tutorial

Teach your data
to explain itself.

A guided introduction to building data models that carry their own meaning. It starts where you already are, with the columns of a spreadsheet, and it is written for the person who knows the subject matter rather than the standards.

Start module 1 See the whole curriculum
Free ~2 hours to your first model No account needed to read

What you are going to learn

How to describe a piece of data so completely that somebody can still read it correctly ten years from now, on a system you have never seen, without ever having been around when the data were created.

Most data leaves home half-dressed. A spreadsheet column called bp holds the number 140. Somewhere else, in a document or a database comment or somebody's head, is the rest of it: that this is systolic blood pressure, measured in millimeters of mercury, that the normal range is 90 to 120, that it was taken sitting, that the reading was valid on a particular morning and is not a claim about today. None of that travels with the 140. So every system that receives it has to be told again, by a person, and every new system that is not told guesses or fails.

A Semantic Data Charter model is where all of that gets written down once, attached to the value itself, in a form a machine can evaluate and a human can review. Build the model once and every record made from it carries its own meaning, its own limits, and its own history, wherever it goes.

Who this is for

People who know a subject. Nurses, accountants, logistics planners, laboratory managers, public-health analysts, anyone who can say what a field actually means and when it is wrong. That knowledge is the hard part and you already have it. This teaches you to write it down in a form software can enforce.

Engineers and data people who keep meeting the same problem from the other side: the join that cannot be trusted, the code whose definition nobody can produce, the field that meant something different before the reorganization.

Students and recent graduates building their data skills for the future. The scarce skill here is not programming. It is knowing what the data means, and then being able to model it.

You do not need to be a programmer. You do not need to know XML, RDF, or any standard by name. You will meet the standards eventually, but as tools rather than as a syllabus.

You already know most of this. It is in your spreadsheet.

If you have ever set up a spreadsheet for other people to fill in, you have built a data model. You decided what each column was for, what counted as a valid entry, and what the headings meant. You just had nowhere to write most of that down.

A spreadsheet lets you say what a value looks like: a number, a date, two decimal places, a currency symbol. A model lets you say what a value is. That is the whole shift, and it is the reason the choices below are not the ones you are used to making.

Numbers: the choice you make first, and most often

In a spreadsheet, numbers split into integer, decimal and currency, and the distinction is about display. Here, the distinction is about what is being counted or measured.

  • Counting discrete things? That is a Count. Pallets, visits, employees, shares, doses dispensed. Always a whole number, never negative, and it carries its own unit, so the value is not 17 but 17 pallets. The unit stops being a column heading somebody has to read and becomes part of the data.
  • Measuring something? That is a Quantity. A decimal value with required units: 2.5 kg, 120 mmHg, 37.4 degrees Celsius. If a value can be halved and still mean something, it is a measurement and not a count.
  • Money is a Quantity, and the currency is the unit. 499.00 USD. Your spreadsheet formats a cell as currency, which is a display setting that does not travel when the number is exported; a Quantity carries USD as data, so the amount cannot arrive somewhere as a bare 499 and get read as euros.
  • Do not reach for Float or Double. They exist for scientific calculation and they round in ways that are wrong for anything financial. The rule is short: money and business measures are Quantities.

Lists, yes-or-no, and codes

  • A dropdown with no inherent order (country, department, product line) is a text component with the permitted values bound into it. The list stops being data validation on one sheet and becomes part of the definition everyone inherits.
  • A dropdown that does have an order (mild, moderate, severe; bronze, silver, gold) is an Ordinal, which carries both the label a person reads and the rank a machine sorts by. If "severe" should sort above "moderate," this is the one you want.
  • A yes-or-no column is a boolean, but you name both options rather than storing TRUE and FALSE. Granted and Denied, not 1 and 0. Six months later nobody has to ask what the 1 meant.
  • Codes and identifiers (an SKU, an ICD-10 code, a policy number) are a token type that normalizes stray whitespace, so a trailing space in one system does not make the same code fail to match.
  • Dates get a deliberate granularity. A date of birth is a date. An event timestamp is a date and a time. Saying which one you mean prevents the receiving system from inventing midnight.
  • A reference to another record carries the relationship in words rather than as a bare foreign key: this document is the subject_of that one. Anyone reading the record can see what the link means.

Semantic links: you do not have to build an ontology

Every component you build can carry a link out to a term in a published vocabulary or ontology. If you model systolic blood pressure, you can point it at the SNOMED CT or LOINC concept for systolic blood pressure. A food composition field can point at FoodOn. A business concept can point at a standard business vocabulary, or at your own industry's published terminology, or at a term your regulator defines.

Two things follow, and both matter more than they sound.

  • You are not asked to build an ontology, or to choose one before you start. You build the component, you bind the definition and the constraints that make it correct, and you link out to whichever published vocabularies are useful. You can carry links to several at once, because different consumers care about different ones.
  • The link is how your model meets somebody else's. Two organizations that never agreed on a schema, and never will, can still be pointing at the same concept. That is what makes the record readable outside the system that produced it, which is the whole point of the exercise.

The curriculum goes through each of these in turn, with a worked example you build yourself. What you have just read is the part people usually have to discover by getting it wrong first.

What the path looks like

The first hour or two. Modules 1 and 2 cover what a model is, what the pieces are called, and how meaning gets bound to a value. At the end of module 2 you have built something and can see the difference between a number and a number that explains itself.

Fourteen to sixteen hours, if you continue. Nine modules take you from a first component to a complete, published, reusable data model, including provenance, governance and the semantic links that connect your model to shared vocabularies.

Certification, only if you want it. All of the material above is free and always will be. There is an examination at the end for people who want a credential a client or an employer can check, and that is the only part that costs anything. The exam fee is on the certification page. Passing it issues a numbered credential with a public verification page, which means an employer can confirm it without asking us.

You can stop at any point. Most people who read module 1 will never sit the exam, and that is a perfectly good outcome. The purpose of this material is that more people can model meaning properly, not that more people buy something.

If you are here to build a practice

The same curriculum serves consultants and firms who want to deliver this work to clients, and there is a page written specifically for that case: what the offering looks like, how the credential fits, and what to sell. It is on the practitioners page. If that is not you, ignore it; nothing in the curriculum assumes you have clients.

Where to start

Straight into module 1. If you would rather see the whole shape first, the curriculum index lists all nine modules with what each one covers. If you want to know why any of this matters before you spend an hour on it, the five questions page is the short version of the argument.

Once you have an SDCStudio account

There is a second way to build, and some people prefer it from the first day. SDCBench is our open-source desktop model builder: you assemble a model by dragging components onto a canvas, reusing what is already in the library, and send the result to your SDCStudio account as a draft. It is Apache-2.0, it runs on your own machine, and it is in beta.

If you think better with a diagram than with a form, start there. The modeling decisions are the same ones described above; only the surface is different.

And if you work with an AI assistant, it is worth twenty minutes to ground it properly before you ask it for modeling help, or it will confidently propose a spreadsheet. What to load, and in what order.

Questions as you work through it are welcome at contact@axius-sdc.com.