LogicalDataDescription

Logical Data Description has evolved into a description of data structures, not data. Data is described separately in FormatDescription. Of course, the description of data leverages the description of data structures found in Logical Data Description.

The data structures described in Logical Data Description are largely based on Instance Variables.

Logical Data Description is able to represent a very rich variety of record types and record organizations. For example, it can provide a table definition and describe the organization of tables in a relational database. However, Logical Data Description can also describe information models like those used in medical informatics that describe structured objects like blood pressure and even electronic health records.

All this is possible because of the collections model that Logical Data Description uses. In Logical Data Description the basic structure is the LogicalRecord. Two very different organizations of Instance Variables are supported by the LogicalRecord and its descendants the UnitDataRecord and eventually the DataCube. One organization is the SimpleCollection. The other is the StructuredCollection. The SimpleCollection yields things like table definitions. The StructuredCollection (InstanceVariableRelationStructure) is actually a graph. It yields the hierarchical definitions that correspond to information models. However, because a graph need not have a single root, the StructuredCollection is also able to represent data networks, social networks and so forth.

Namespace URI: 
http://ddialliance.org/ddi4/LogicalDataDescription
Color of objects in the uml graph: 
E9B64D
Example: 
Examples include a relational database definition, a data warehouse definition, various big data table definitions, an openEHR archetype definition, an electronic health record definition and a data network definition.
Explanatory Notes: 
DDI4 structures differ a whole lot from GSIM structures because of the adoption of the DDI4 collections model. Nodes in GSIM are a precursor to the DDI4 collections model. So far we have been able to road test Logical Data Description with use cases that exercise both the SimpleCollection and the StructuredCollection. SimpleCollection use cases include both the relational database schema and the star schema (data warehouse). A StructuredCollection use case is the openEHR observation archetype. Here we leveraged not just instance variables but also concepts. Instance Variables are extensions of Concepts in both DDI4 and GSIM. In this way we were able to create structures that interleave concepts and variables.
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