Overview

From client eyes, here is the model in a nutshell:

• codelists are versioned bags of codes;
• codes are described by attributes;
• codes have links to other codes, their attributes, or their links;
• links and attributes follow definitions;

That's it, no conceptual shocks. Rather, a few highlights:

• links as pointers, links as relationships.

Links let us avoid redundancies: "don't repeat it, point to it". A bit like linking Excel cells, really (with the added value of transforming the targets). When we specify target transforms in link definitions, we align with this "editorial" viewpoint: links as 'by-ref' attributes, description pointers. Yet names gives links some "semantic reach": squint enough and they look like domain relationships: 'has-a', 'is-a', 'is-in', 'generalises', 'specialises', etc...you name it. When we specify occurrence constraints in link definitions we align with this semantic viewpoint.

• attributes (almost) everywhere.

Attributes on codes serve as classic descriptors, a bit like relational columns, form fields, and object properties. On entities like codelists, links, and definitions they feel more like annotations. Some annotations originate from the application: Cotrix makes heavy and varied use of attributes. Even more annotations come from users. The model assumes we work on codelists as we work on paper documents, rather than on entry forms: scribbling away "at the margins". Even attributes can be annotated. We can't use attributes themselves for this, but we do make room for a little note to record the contextual why-when-what of an attribute.

• definitions as (soft) schemas.

With attribute definitions we factor out names, types,and languages of individual attributes. With link definitions we do the same for names, targets, anchors, and transforms of individual links. Hence definitions look a bit like schemas: vantage points to understand the data, handles to make sweeping changes in one go, homes for defaults. They even host constraints, again like schemas. But this remains "informative" in spirit, not "prescriptive". Validation flags problems, editing goes on. And we allow attributes without definitions for custom tags, one-off comments, description outliers.

There is also something work talking about in the implementation of the model, peculiarities like:

• reified updates
• separate APIs
• persistence ignorance
• code reuse with traits and containers