Distributed UDEF Architecture : Governance

 

Global Naming

Whereas UDEF trees are numbered 0-16 (objects) and 1-18 (properties), SDEV trees are number s0-s999 (objects or object extension) and s1-s999 (properties or property extensions. The tree numbers have global significance across all SDEV registrars, and will be assigned by The Open Group to any registrar in order of establishment of a related connection point in UDEF. The Open Group takes responsibility that all SDEV tree numbers are unique and only assigned to one specific knowledge domain each. Multiple tree numbers may be assigned to the same registrar for different concepts that will be in a common satellite vocabulary.

The trees in any SDEV are extensible by the same extension process that applies for UDEF, except being executed by the Registrar assigned by The Open Group, rather than The Open Group itself.

In a simple UDEF string, consisting of an object part and property part, it is assumed that this string can be analyzed by parsing this string and finding corresponding nodes in the tree from a single registry. In the context of distributed UDEF, the assumption that parsing can be done from a single registry is dropped.

The naming convention of the root of the tree identifies which registry must be used to parse the tree. When the root is a simple numeric, the UDEF must be parsed; when the root is formed by a letter with some number appended (like s23) another registry must be used. It must be noted that for parsing the object part and parsing the property part of a data element concept the choice of registry must be made independently, i.e. an object part of a UDEF tree can be combined with a property part from another registry or vice versa. For Satellite Data Element Vocabularies (SDEVs) the root of the tree will have the form sxxx, where xxx is a number (0-999). All other letters are reserved for other types of distributed trees and for potential use by future versions of UDEF.

Registrars

A satellite registrar is an organization that is globally considered as the neutral focal point of a knowledge domain, and who has been given the authority to define standards with regard to information modeling in that knowledge domain, and to whom the responsibility is delegated by The Open Group to maintain a set of satellite trees.

A registrar will execute the same processes as The Open Group to maintain the satellite trees delegated to it in the same way as The Open Group maintains UDEF. It maintains a strong liaison with the Open Group in order to decide on each extension proposal for a tree, whether this shall be an extension to an existing satellite tree, or an existing UDEF tree, or my be a new  satellite tree.

In addition it may maintain liaisons with other organizations that may be originators or copyright-owners of assets that have been imported in that SDEV.

The Open Group will define all trees of Objects and Properties for the UDEF itself as well as for any descendant satellite trees in the knowledge domains of The Open Group’s own areas of interest and will define the connection points by which UDEF can link to all SDEV-trees. The exclusive privilege of defining trees of Objects and Properties in any other specific knowledge domain will be assigned by The Open Group to the chosen SDEV registrar for that knowledge domain.

All satellite trees have globally unique identifiers that will be assigned by the Open Group to any knowledge domain for which a SDEV has been identified to which the maintenance of trees in their knowledge domain will be delegated. Because different descendant trees may be in different knowledge domains, these may be assigned to different registrars. It is therefore mandatory that uniform governance principles are applied across all registrars, in essence making the handling of a UDEF tag independent of the registrar. The Open Group will maintain a public list of identifiers of satellite trees with the name and URL of the registrar to which each tree is delegated.

Once a registrar has been assigned who has taken responsibility for an SDEV, this organization must implement an extension process similar to the UDEF extension process. The SDEV registrar must however also consider UDEF trees for possible extension. UDEF members must also have a vote in SDEV extension processes, and collectively may exercise a veto.

Extension Principles

With the advent of distributed UDEF, multiple different possibilities exist to extend UDEF, however at any instance only one should be chosen. The current possibilities are described below. In future, when multiple types of distributed tree will be supported, the extension process will be further complicated.

an Existing UDEF Tree

This is the standard approach, which should be chosen unless the 2nd or 3rd approach applies. A Data Element Concept that can be constructed by subclassing an existing UDEF-object with a new subclass leads to the proposal of a new node on a UDEF object tree. A data element concept that can be constructed by describing a more specialized property of existing properties leads to the proposal of a new node on a UDEF property tree. These proposed extensions are subject to the following rules:

  • The semantic rules for extending the UDEF must be strictly adhered to.
  • Subclassing objects may not lead to any brand specific information.
  • Specialization of properties should be applicable to the reference object and also to all of its superior nodes in the object tree.
  • The newly formed Data Element Concept should be relevant for any kind audience and not be restricted in its use by any dependence on domain specific knowledge.

The proposed extension will go through the formal review process before being accepted as part of the next version update of UDEF. The update proposal must be simultaneously available in any absolute majority of languages in which UDEF at the time is published (51% or higher). The versions in other languages must be reviewed by the respectively language teams for internationalization of UDEF. In this review any Base Language can be considered as source of translation.

a New SDEV Tree

This approach is applicable if many related concepts have to be proposed, which by themselves can be organized as single concept with subclasses (in case of an object tree) or specializations (in case of a property tree), and where all of the following is applicable:

  • The detailed knowledge about the specific extensions is common within a specific knowledge domain but rare outside that knowledge domain. It is understood that such knowledge domain typically maps to a domain of industry or business or public administration.
  • Specializations are required that may violate The Open Group principle of vendor neutrality. Obviously in aviation concepts that relate to specifics of types of air planes, do not intend to be vendor specific but cannot avoid this either, as each air plane type typically has one manufacturer. In other branches similar situations might occur: Data Element Concepts in a knowledge domain may be heavily biased by vendor dominated technology choices.

an Already Existing Satellite Tree

This approach is applicable if new concepts are to be introduced in an existing knowledge domain for which an SDEV already has been created. The proposed extensions are subject to the following rules:

  • The semantic rules for extending the UDEF must be strictly adhered to.
  • Specialization of properties should be applicable to the reference object and also to all of its superior nodes in the object tree.
  • The newly formed Data Element Concept should be relevant for the audience of the knowledge domain and not be restricted in its use by any dependence on domain specific knowledge from other knowledge domains.
  • The proposed extension will go through a formal review process, conducted by the designated registrar, before being accepted as part of the next detail version update of the SDEV of that knowledge domain. That extension process must include a step to consult The Open Group's UDEF workgroup on any proposed extension.
  • The update proposal must be simultaneously available in any absolute majority of languages in which that SDEF at the time is published (51% or higher). The versions in other languages must be reviewed by the respectively language teams for internationalization of UDEF. In this review any Base Language can be considered as source of translation.

Registry Switching

By extending UDEF trees with connection points, a mechanism can be created to use a distributed tree as an extension to a UDEF tree. A UDEF node can be reserved as a connection point for a specific distributed tree. The connection point then refers to that tree. Resolution of the referral effectively substitutes the referred tree at the connection point, i.e. the connection point is mapped to the root of the referred tree.

The governance of the referring tree has authority over the connection point definition. Any distributed tree can contain connection points itself to connect to trees of other distributed trees.

Multiple connection points in different object trees can refer to the same distributed object tree. This means that subclasses defined in the distributed tree are made available to multiple parent object types. Applying the semantic rules for Object trees means that it is not required that all subclasses defined in a distributed tree make sense at all connection points. It is sufficient that:

  • The root of the distributed object tree and any selection of subclasses are relevant to all connection points in the parent UDEF-tree; and that
  • All subclasses of the distributed object tree are relevant for any subset of the connection points of the root of the distributed tree.

Registry Switching

Registry Switching

Multiple connection points in different property trees can refer to the same distributed property tree. This means that specializations defined in the distributed tree can be made available to multiple parent property types. Applying the semantic rules for Property trees (see box above) means that is not required that all specializations defined in a distributed tree are valid specializations at all UDEF connection points. It is sufficient that:

  • The root of the distributed property tree and any selection of specializations are applicable to all connection points in the parent UDEF-tree; and that
  • All specializations of the distributed property tree are applicable at any subset of connection points of the root distributed tree.

Connectors

It will be possible to switch parsing to another registry in the middle of a tree at a so-called connection point. A connection point is a special kind of node in a tree that does not contain a subclass or specialization of its parent node, but contains a reference to another tree, that typically belongs to another registry. The form of this reference depends on the format in which the tree is represented.

In the verbose listing of a UDEF code, a connection point is made visible by inserting a switching command in the string.

The switching commands has the form UDEF-S (all capitals), to represent that on this place switching to a satellite registry must take place. The node immediately prior to the UDEF-S literal contains the information about the destination of the switching.  All other literals of the form UDEF-x, where x represent a capital, other than S have been reserved for potential switching to other types of distributed trees or for use by future versions of UDEF.

In the language specific listing of UDEF strings, a connection point is only visible when the switching has not (yet) been executed. The representation of the tree before switching contains at the switching node a verbose reference to the destination tree. After switching has been executed, the referencing node is replaced with the root of the referenced tree. Within the destination tree, parsing can continue as usual.

In the XML format of a UDEF tree a switching point will be represented by replacing the tag for the branch with a tag that will contain the URL of the appropriate distributed tree. In case of a SDEV this URL will use the https protocol and generally have the form: https://SDEV.registrar.org/tree-name.xml. The name of the tree corresponds to the object or property (extension) in the root of the SDEV.