Rules for profiling
B.1 Basic rules
Rule 1.: A DMF Profile shall define the resource types (e.g. dataset, series, etc.) in the scope of the profile.
Rule 2.: A DMF Profile shall define the applicable metadata class, as well as the applicable metadata elements, types and properties.
Rule 3.: A DMF Profile shall only define what is specific to the profile implementations: restriction of the cardinality, domain of value of a DMF metadata element.
B.2 Creating inherited metadata elements
A DMF profile may specialize a DMF complex metadata element, in order to create a new metadata element. A specialization means that one of the attribute is fixed.
Rule 4.: When an element is specialized, the specialized value shall be compatible with the Value Domain and contraints defined in DMF.
Example: Within the STANAG NGMP, the Resource Custodian is a specialization of DMF Resource Responsible Party: the role is fixed to custodian, and only the organization name is provided. However, the value that is provided shall respect the Domain Value of the DMF complex type, in order to keep the compliancy with DMF.
Rule 5.: The specialized element shall be registered so that it can be reused in other profiles.
A DMF profile may inherit a DMF complex metadata element, in order to create a new metadata element. In this case new values can be added to the element.
Rule 6.: Inherited metadata elements shall be documented (mandatory Identifier, Title, Description, Cardinality, Value Domain, metadata class, View (D, E, U, M); Optional constraint, default or fixed value).
B.3 Extending DMF
Rule 7.: Any extension of DMF has to be handled in a new metadata class.
A DMF Profile can add a new resource type.
Rule 8.: In this case, it shall specify the DMF Metadata elements applicable to the new resource type, i.e. for each applicable DMF Metadata element, its cardinality, its domain of value, and its specific constraints.
A DMF profile can define new properties of existing DMF Complex Type and implicitly make them applicable to the DMF Metadata elements as part of a profile metadata class.
Rule 9.: In this case, it shall specify for each new property of the complex type, its cardinality, its domain of value and its specific constraints.
A DMF profile can define new codelists.
Rule 10.: Values for this list of codes have to be defined and made accessible to the audience of the profile. As long as the implementation of the new codelist uses either a URI Scheme compatible with the DMF’s one or the DMF generic codelist implementation; it is not seen as an extension of DMF. Thus, any extension of the codelist is not seen as an extension of DMF. However, any restriction of the domain of value or any new constraints applicable to the existing DMF metadata elements have to be expressed as additional requirements in a profile metadata class.
A DMF Profile may define metadata elements which are not in scope with the ISO metadata standards and the DMF/Defence metadata extensions of ISO 19115.
Rule 11.: In this case, the full documentation of the concepts (conceptual schema, data dictionary, etc) and their XML Schema Implementation shall be made available.
B.4 Registration of DMF metadata profile
Each DMF metadata profile and relative XML schemas shall be registered within the DGIWG. This registration mechanism involves the documentation of the relationship between the DMF and the profile with a set of tables:
• The metadata class table defines the DMF metadata classes in the scope of the profile as well as the profile specific metadata classes and their dependencies.
• The metadata element table defines for each DMF Metadata element, the corresponding profile metadata element (there may be many in case of an inherited metadata element), its cardinality, and inheritance criteria when applicable.
The naming of the profile should follow this template:
http://www.dgiwg.org/std/dmf/profile/name[/version]
where name is the name of the template (see Annex F for examples of existing names) and version is the version of the profile, if any.
