LogicalDataDescription

The LogicalDataDescription Package contains classes used in the description of data structures, record types and record organizations, but not the instantiated data. Structures such as tables, relational databases, data warehouse structure, big data tables, openEHR archetypes, and other information models.

Namespace URI: 
http://ddialliance.org/ddi4/LogicalDataDescription
Color of objects in the uml graph: 
E9B64D
Include in build?: 
True

Comments

A DataPoint references both an InstanceVariable and a Unit. I replaced InstanceVariable with DataPoint because the DataSetStructure structures a DataPoint, not an InstanceVariable

I moved Represented Variable from the Conceptual View to the Logical Data Description. This is consistent with DDI 3 and will facilitate maintenance because the Represented Variable and Instance Variable are very connected through the Value Domain. Also, it turns out that DataPoint and Datum are pivotal to the Physical Data Description so these objects have been moved from the Logical to the Physical Data Description.

Consider that InstrumentComponent or Capture if we determine that InstrumentComponent is redundant. They have ExternalAids, Instructions and the like. These condition the Observation. In other words the Observation might not be the same with different instructions, external aids and the like. This means that each observation has a context (Hello, Dan!). In consequence to designate one observation we may need many datum.

I have always thought that observations are magical. The current cardinality doesn't do justice to observations. This idea of Observation is borrowed from openEHR where blood pressure, an ECG recording, body mass index, etc are all observations that have context.

An InstrumentComponent can produce multiple Observations each resulting in a Datum which can cluster a measure with various attributes.

I am wondering if ViewpointRoles couldn't be members of a collection. That way could we give structure to a ViewPoint and the record associated with it? In this structure couldn't we organize both measures and attributes? We might, for example, combine measures into a score (like the Apgar score) or circumscribe several measures that together define a concept (like blood pressure). Likewise couldn't we build a classification of attributes just as openEHR does when they put attributes into a set of buckets: state, events and protocol?

I moved Record Relation here, as discussed. Record Relation is mapping between Logical Record Layouts. In addition, we needed the mapping between Instance Variables in those Layouts, which I tentatively called Instance Variable Mapping.

To support the representation of JSON schemas and the embedding of resources in RDF, I added a relation through which a LogicalRecordLayout can nest a LogicalRecordLayout. Otherwise the layout we would support would be flat. Flat is fine for tables but not for other structures.

To support attribute groups I changed the source cardinality of hasAttributeRole from 1..1 to 1..n. Now in the same Viewpoint we can have separate attribute roles for protocol used during an Observation, the state at the time of the observation and so forth.

Package Graph