Distinguish different levels of conformity for this specification

Published on: 27/03/2012


Giorgio CANGIOLI raised the following comment:



 suggest to clearly distinguish the different levels of conformity for this specification foreseeing at least the well-known OMG MDA levels of abstractions:

  1. Conceptual viewpoint (Computationally Independent - CIM)
  2. Logical viewpoint (Platform Independent - PIM)
  3. Implementation viewpoint (Platform Specific - PSM)

The advantage of this is that of allowing a good identification of how hard could be for an implementation (and/or a local specification) to get the working semantic interoperability with another one (not only a Yes/No compliance). In fact two trading partners sharing the same concepts and having the same reference model, may quite “easily” exchange information in an understandable way even if they are not interoperable “on-the-wire”, probably accomplishing just a data re-mapping.

Conceptual Viewpoint

Reading the specs I understand that the main focus of the Core Vocabulary is just on the Conceptual Viewpoint: “In particular, consensus can be more easily attained on the semantics of a small set of fundamental concepts, for which less divergent opinions exist [EGOV-CV]. These concepts are what we describe as Core Vocabularies.” <….> “A Core Vocabulary is a simplified, reusable, and extensible data model that captures the fundamental characteristics of an entity in a context-neutral fashion”).

In general the specs are coherent with this approach, but for some attributes it seems that specs go directly to the next abstraction layers (Logical, Implementation), preventing to claim compliance with the most abstract Level (Conceptual).

Examples are the Gender for which specific  coded values seem to be assigned, or the date representation.

As for the Gender, once agreed if the gender should be described using a textual or a coded representation (and this is what has been done), the next step should be that of identifying the set of concepts that need to be used for describing this attribute: e.g. just {“Male”, “Female”}; instead of {Male; Female; Not Known, Other}; either a more extended set like {Male, Female; Transex ; True- Hermaphrodite; Male- Hermaphrodite; etc etc} ; else…. All this INDIPENDENTLY by how these concepts will represented as coded values.

Therefore – assuming that the concepts agreed are {Male; Female; Not Known, Other} – any implementation able to map its data with those concepts should be considered compliant - at the conceptual level - with this specification, regardless Male is coded as “M”, 0 or 1; or that the Not Known Is provided using <sex>0</sex> or <administrativeGender nullFlavor=”UNK” /> (where the actual codes are  instead conveyed with a different attribute  <administrativeGender code=”M”/> )

Hence specs might assert that a Person is optionally described  by an Administrative Gender; that the Gender is a coded information bound to a “Gender” concept domain; and that this concept domain is defined by a set of concepts [for example, taking the current specs as reference :  {not known, male, female, not applicable} ] (As future enhancement it would be nice to have the concepts described and specify when and how they can be used]


Another example can be done with the dates : I think that at this level is important to know if a date requires a defined set or at least a minimum set of information (e.g. year, month and day, time zone, ….)  or if any textual representation of them can be also exceptionally allowed (e.g. "between 1925 and 1932"). This is what have been correctly done, but all that – at this level - should be independently by the fact that they are represented with XSD datatypes or not. (“20120315” instead “2012-03-15” or “15/03/2012” is just a matter of data transformation)


I’m not sure if the currently published RDF is able to specify this level of abstraction, since – for example – the Usage Note for Gender seems to require a specific value set (that included in the specs).

Logical and Implementation Viewpoint

As for the other levels (Logical and Implementation), it is really useful if the specs arrive to give indications also on them, but those conformance assertions should be well separated by the conceptual level ones.

For what concern the compliance with those levels, I think we need to analyze what is better to have in for each level : for example we may suppose that the compliance with the Logical Level is obtained if an implementation is coherent with the model of Figure 1 of specs (the level of abstraction of the datatypes definition need to be provided). At this level the binding with the value set shall be defined together with bindings proprieties (the value set can be extended ?, the binding is dynamic or static ?; etc etc ).

Finally, the implementation level shall define an exact XML representation with specific element and attribute names, well defined datatypes and value sets [ for example (0,1,2,9) instead of (UNK,M,F,NA) ) ]

(Note: I was not able to open the published xsd so I don’t know if the published schema relies on the logical or on the implementation level.)