The following are the steps of the normative procedure for extending the UDEF.
The submitter shall develop the applicable data element concept based on the existing UDEF object classes and properties and qualifier terms (as applicable) in the context of the affected enterprise. If the existing UDEF object classes are inadequate for the data element concept, then the submitter should propose a new UDEF object class as a part of the submittal.
Note: Although not impossible, it is unlikely that new UDEF object classes will be approved. In nearly all cases, the existing UDEF object classes will be adequate – simply requiring new qualifier terms. In the unlikely event of a new object class or property being needed, its name and description must avoid the use of terms that are specific to particular products or that might give commercial advantage to any individual or organization.
In nearly all cases, the proposed extension to the UDEF will identify new qualifier term extensions – either to the UDEF object class and possibly portions of existing qualifier terms and/or to the UDEF property and possibly portions of existing qualifier terms.
The complete data element concept with proposed new UDEF extensions shall be included in the submittal. If built properly (following the UDEF naming convention), the submitted data element concept should be self-explanatory and will not require a separate definition. The submitted data element concept shall also include the enterprise context.
The submitter shall use existing UDEF object class qualifier terms and UDEF property qualifier terms where possible to minimize the chances of semantic redundancy within the existing UDEF.
The submitter shall select qualifier term words that are a specialization (sub-type or role) of the word above.
The submitter shall select qualifier term words that do not include trademarks, are not product-specific, and do not in any way give any commercial advantage to any individual or organization.
Prior to submitting a data element concept, the submitter shall verify that the UDEF property word is last and any qualifier terms modify the preceding word. Similarly, the submitter shall verify that any qualifier terms to the UDEF object class modify the preceding word. When the object class string (object class plus any qualifiers) is combined with the property string (property plus any qualifiers), the submitter shall verify that the resultant data element concept accurately describes the intended meaning within the context of the affected enterprise.
The following conventions shall be applied to all proposed qualifier term extensions to the UDEF.
The first letter of each word in a proposed qualifier term extension to the UDEF shall be capitalized.
In many cases it is not practical for the sake of re-usability to extend the UDEF by placing each qualifier word at a different level. If a single word (qualifier term) can stand alone and conveys meaning when combined with the words above, then that is the preferred approach. However, in some cases it is not practical and in those cases the multi-word extension shall be hyphenated between each word at the same level.
The submitter shall avoid the use of conjunctions such as Òof, and, orÓ. For example, rather than ÒColor-Of-HairÓ the proposed UDEF extension submittal could be ÒHair-ColorÓ if the two words are at the same level or ÒHair.ColorÓ if the two words within the qualifier term are at different levels.
Since the UDEF source is in XML format and since XML does not accept an apostrophe, the convention for expressing an apostrophe within the UDEF shall be ÒWord-sÓ. For example, to express ÒSellerÕsÓ within UDEF, the submitter shall use ÒSeller-sÓ instead.
This non-normative section describes the process for submitting a proposed UDEF extension and the general approval procedure. The process is summarized in Figure 7.
UDEF Extension Submittal Process
The following sub-sections provide additional details and examples for each major step in the process.
Each enterprise needs to manage data relevant to the enterprise. The challenge is to establish a common vocabulary that conveys shared meaning across all users (people and system applications) of the data. Recognized experts within a domain typically define the terminology used within a given enterprise. For example, those in the engineering discipline commonly use terminology that is taught in engineering schools. However, most applications used within an enterprise do not have a common vocabulary foundation.
If a given application is expected to share data with one or more other applications, then a key first step is to identify the shared data element concepts between the applications. The lack of a shared vocabulary between the applications can be overcome by applying the UDEF to each data element concept that needs to be shared between the applications.
Follow the six basic steps for mapping data element concepts to the UDEF:
To leverage the advantages that the UDEF can provide, the UDEF ID should as a minimum be recorded as an optional alias for the data element concept. If the enterprise has multiple applications, then a metadata registry should capture the UDEF name and ID for each data element concept that is shared between applications. The UDEF name and ID pair provides a simple but effective indexing mechanism for discovering re-usable data element concepts across the enterprise.
To extend the UDEF, develop a data element concept with proposed UDEF extensions that adheres to the requirements, following the normative procedure. Be certain that the enterprise context for the data element concept is also established.