ISO/TS 13582:2015
(Main)Health informatics — Sharing of OID registry information
Health informatics — Sharing of OID registry information
ISO/TS 13582:2015 specifies the mandatory and optional information to be recorded in any registry of OIDs, using an information model. It specifies which parts of that information are to be regarded as public and which parts are to be subject to security and privacy requirements. All registries support the recording of mandatory information, but the recording of any specific object identifier in one or more repositories is always optional. In some cases, security and privacy requirements are more stringent for e-health applications. In detail, this Technical Specification: - specifies an information model and a corresponding XML format for the export of the contents of an OID registry, suitable e.g. for import to a different OID registry; - references common Use Cases for OID registries/repositories; - references an Object Identifier Resolution System (ORS) which provides a look-up mechanism for information related to an object identifier, with guidance on the use of that facility.
Informatique de santé — Partage des informations de registre des identifiants d'objets (OID)
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 13582
Second edition
2015-12-15
Health informatics — Sharing of OID
registry information
Informatique de santé — Partage des informations de registre des
identifiants d’objets (OID)
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Explanation of terms . 2
4.1 OID registry and OID repository . 2
4.2 Registration Authority (RA) . 2
4.3 Responsible (Managing) Authority (MA) . 3
4.4 Submitting Authority (SA) . 3
4.5 Current Registrant . 3
4.6 First Registrant . 3
4.7 First Registration Authority. 3
4.8 Rec. ITU-T X.660 | ISO/IEC 9834-1 . 3
5 Object identifiers in healthcare . 4
5.1 General . 4
5.2 Additional descriptions . 5
5.3 Related work . 5
6 Approach . 5
6.1 Requirements analysis . 5
6.2 Preparatory work . 6
7 Information model . 6
7.1 General . 6
7.2 Agenda of tables and symbols . 7
7.2.1 Class attribute and associated tables . 7
7.2.2 Conformance statements . 8
7.3 XML exchange format . 8
7.4 Registry. 8
7.4.1 Attributes . 8
7.4.2 Associations . 9
7.4.3 Example . 9
7.5 Oid . 9
7.5.1 Attributes .10
7.5.2 Associations .12
7.6 RegistrationAuthority .12
7.6.1 Attributes .12
7.6.2 Associations .13
7.7 ResponsibleAuthority .13
7.7.1 Attributes .13
7.7.2 Associations .13
7.8 SubmittingAuthority .13
7.8.1 Attributes .14
7.8.2 Associations .14
7.9 HistoryAnnotation .14
7.9.1 Attributes .14
7.10 Reference .15
7.10.1 Attributes .15
7.11 AdditionalProperty .15
7.11.1 Attributes .16
7.12 Person .16
7.12.1 Attributes .16
7.13 Organization .16
7.13.1 Attributes .17
8 List of codes and enumerations .17
8.1 CountryCodes .17
8.2 LanguageCodes .18
8.3 OIDcategories .18
8.4 OIDstatusCodes .18
8.5 ReferenceType .18
8.6 RoleCodes .19
8.7 RoleStatus .19
9 Datatypes .19
9.1 Address AD .19
9.2 Coded simple value CS .19
9.3 Encapsulated data ED .19
9.4 Entity name for a person EN.PN.20
9.5 Entity name for an organization EN.ON .20
9.6 Instance identifier II .20
9.7 Interval of time stamp IVL_TS .20
9.8 String ST .20
9.9 String ST.NT .21
9.10 Object identifier (dot notation) ST.OID .21
9.11 Object identifier (asn1 notation) ST.ASN1 .21
9.12 Object identifier (iri notation) ST.IRI .21
9.13 Symbolic name ST.SYMB .21
9.14 Telecommunication TEL .21
9.15 Locatable resource TEL.URL .21
9.16 Time stamp TS .21
Annex A (informative) OID types and sub trees.22
Annex B (informative) Use cases and object identifier resolution system (ORS) .23
Annex C (informative) W3C Schema for XML representation and information model .26
Bibliography .27
iv © ISO 2015 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 215, Health informatics.
This second edition cancels and replaces the first edition (ISO/TS 13582:2013), of which it constitutes
a minor revision.
Introduction
OID (Object Identifiers) are unique identifiers for any kind of objects. A globally unique identifier for
each of these concepts will help to ensure international exchangeability of objects within different
applications (e.g. healthcare information systems).
In the exchange of healthcare information, additional information about the object being identified is
generally very beneficial but typically not contained in a transaction of data between systems. Such
information (responsible organizations, a human readable name, a description of the object, etc.) is
referred to as the OID metadata and is housed in an OID Registry.
Today, due to lack of standardization of the set of metadata (both content and structure), existing OID
registries are not compatible.
vi © ISO 2015 – All rights reserved
TECHNICAL SPECIFICATION ISO/TS 13582:2015(E)
Health informatics — Sharing of OID registry information
1 Scope
This Technical Specification specifies the mandatory and optional information to be recorded in any
registry of OIDs, using an information model.
It specifies which parts of that information are to be regarded as public and which parts are to be
subject to security and privacy requirements.
All registries support the recording of mandatory information, but the recording of any specific
object identifier in one or more repositories is always optional. In some cases, security and privacy
requirements are more stringent for e-health applications.
In detail, this Technical Specification:
— specifies an information model and a corresponding XML format for the export of the contents of an
OID registry, suitable e.g. for import to a different OID registry;
— references common Use Cases for OID registries/repositories;
— references an Object Identifier Resolution System (ORS) which provides a look-up mechanism for
information related to an object identifier, with guidance on the use of that facility.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 3166, Codes for the representation of names of countries — The International Organization for
Standardization, 3rd edition, part 1 ISO 3166‑1
ISO 21090, Health informatics — Harmonized data types for information interchange
ISO/HL7 21731, Health informatics — HL7 version 3 — Reference information model — Release 4
ITU-T X.660 | ISO/IEC 9834-1, Information technology — Open Systems Interconnection — Procedures
for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object
Identifier tree
IETF RFC 3066, Tags for the Identification of Languages
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21090 and the following apply.
3.1.1
property
inherent state- or process-descriptive feature of a system including any pertinent to a component
being determined or set of data elements (systems, component, kind-of-property) common to a set of
particular properties
3.2 Abbreviated terms
The following abbreviated terms are used for the terms defined in this Technical Specification and its
annexes.
HL7 Health Level Seven Inc
IETF Internet Engineering Task Force
OID Object Identifier
OMG Object Management Group
W3C World Wide Web Consortium
XML Extensible Markup Language
ITU International Telecommunication Union
IEC International Electrotechnical Commission
4 Explanation of terms
4.1 OID registry and OID repository
An OID registry maintains a list of OIDs. Typically additional information (metadata, such as responsible
organizations, a human readable name, a description of the object, and other information that is needed
for any meaningful use of the object identified) associated with the OID is stored also. With that, a
registry is then an OID repository at the same time.
Maintaining the list (and associated metadata) happens regardless whether it is an official register for
allocations of new OIDs under a given OID arc, or just a copy of information from other registries.
Official OID registries/repositories responsible for allocations of new OIDs under a given OID arc are
Registration Authorities.
4.2 Registration Authority (RA)
An RA is responsible for allocating child arcs to the OID that it manages (issuing authority). It ensures
that an integer is used once among the subsequent arcs (child OIDs). As much as possible, it avoids the
same identifier (beginning with a lowercase letter) being used for multiple sub-arcs. Such information
is typically stored in the OID registry/repository but it is important to understand that an OID first
needs to be officially allocated by an RA before it can be described in an OID repository
For each child OID, the RA also keeps a record of additional information (like the name of a contact
person, postal address, telephone and fax numbers, email address, etc.) about the Responsible Authority
for that child OID. A responsible authority for a child OID must formally become an RA for the child OID
in order to allocate sub-arcs under it.
2 © ISO 2015 – All rights reserved
4.3 Responsible (Managing) Authority (MA)
An MA is used to indicate the person (if known) and organization who is currently in charge of managing
the OID. Once a responsible authority is allocating sub-arcs and registering information on these sub-
arcs, it also becomes the Registration Authority for these sub-arcs.
Discussion: simply managing an OID (for example, for a code system) is the task of a Responsible
Authority MA. Potentially, a responsible authority may become a Registration Authority (RA) for a sub-
arc if it allocates sub-arcs.
4.4 Submitting Authority (SA)
This information is optional and reflects the person or organization that submitted the original OID
allocation request.
4.5 Current Registrant
In some OID registries, Current Registrants are stored. The Current Registrant is used to indicate the
person (if known) who is currently in charge of managing the OID, allocating sub-arcs and registering
information on these sub-arcs.
4.6 First Registrant
In some OID registries, First Registrants are stored. The First Registrant is used to indicate the very first
person (if known) who was responsible for managing the OID and who created it in the first instance.
This Technical Specification strongly suggests distinguishing between:
— a Registration Authority (RA) (person, if known, and organization) who issued (=allocated the
instance of) an OID and
— a Submitting Authority (SA) who submitted the OID allocation request (which may be the same instance).
In this sense, the First Registrant is the Registration Authority (RA).
4.7 First Registration Authority
The first Registration Authority of an OID is the very first person or company to whom the OID was
allocated by the RA of the superior OID. According to Rec. ITU-T X.660 | ISO/IEC 9834-1, the first RA
cannot be changed (if the responsibility is transferred to someone else, the information is recorded in the
“Current Registration Authority” section, without changing the “First Registration Authority” section).
Discussion: this is the Registration Authority (RA) that allocated the OID.
4.8 Rec. ITU-T X.660 | ISO/IEC 9834-1
In ITU-T Recommendation X.660, the following definitions are given.
— 3.6.8 registration authority: An entity such as an organization, a standard or an automated facility that
performs registration of one or more types of objects (see also International Registration Authority).
— 3.6.2 administrative role (of a registration authority): Assigning and making available unambiguous names
according to the Recommendation | International Standard defining the procedures for the authority.
— 3.6.14 technical role (of a registration authority): Recording definitions of the objects to which names are
assigned and verifying that these definitions are in accordance with the Recommendation| International
Standard defining the form of the definition.
This Technical Specification does not use administrative or technical roles.
5 Object identifiers in healthcare
5.1 General
OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec.
ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable
electronic information exchange possible. Administration and Registration is regulated by a set of rules.
The precise designation of objects and concepts is a pre-requisite for the standardized exchange of
information. A globally unique identifier for each of these concepts will help to ensure international
exchangeability of objects within different applications (e.g. healthcare information systems). For
example, OIDs are often used within HL7 messages and documents and Rec. ITU-T X.509 certificates to
provide this unique identification.
In the exchange of healthcare information, especially between loosely coupled systems, additional
information about the object being identified is generally very beneficial; this is information that is
typically not contained in a transaction of data between systems but is reference information about the
objects contained in the transaction. There is a minimal set of such information, such as Responsible
Organizations, a human readable name, a description of the object, and other such information that
is needed for any meaningful use of the objects identified. Since such information may not be locally
available to a system examining the communicated objects, it makes sense to have such information
available in a standardized form and accessible by using the OID to identify this information. Such
information, referred to as the OID metadata, is the bulk of the information housed in an OID Registry.
Today, due to lack of standardization of the set of metadata (both content and structure), existing OID
registries are not compatible. Contents, attributes, and rules of the assignment of OIDs of existing
registries are incompatible and often dissimilar. Many registries still distribute OIDs in a form only
suitable for direct text processing (like spreadsheets) that is error prone and hard to automate. There
is a need to store and transfer collections of OIDs and also to keep some registries completely in sync,
maintaining the contents and the structure of metadata of each of the registered OIDs, e.g. descriptions,
comments, versions, links, relations, responsible organizations, and persons.
Data exchange can be facilitated by a standardized representation of a required minimum set of
metadata as an XML structure together with the associated checks of underlying constraints and
business rules. This XML structure for importing and exporting OIDs among different registries
should be achieved for supporting eHealth applications. In addition, the failure to have a standard for
the operations needed to coordinate and synchronize the contents of disparate OID registries leads to
confusion and ambiguity for the community that uses eHealth information containing references to
objects identified by OIDs.
There are currently at least hundreds of OID registries in active use throughout the world. These
are sponsored and operated by disparate entities, ranging from national governments to individual
companies or standards organizations, to individuals in a specialized area or industry. In many cases,
more than one of these registries address the same industry segment, and have overlapping content,
i.e. specific OIDs exist in both, or worse, different OIDs identifying the same object exist in both. This
distributed set of disparate registries servicing a particular industry (specifically Healthcare IT) has
led to awkward and error prone searching processes. To get information about existing OIDs, a search
within all existing registries is needed, for example, to avoid duplicate assignment of multiple OIDs
to one and the same concept. In order to standardize the activities to synchronize all existing OID
registries and to ensure further interoperability, it is essential to have a defined exchange format and
business rules for maintenance of the OID registries that must cooperate in a particular industry.
Some OID registries are operated by essential volunteer organizations, such as standard
bodies/facilities. The burden of administrative tasks is such that multiple individuals, often in different
geographical locations, need to participate to share the workload. Thus, in addition to distributed
registry instances, administrative functions need to also be distributed, both on single and potentially
across multiple registries. There is a need for the standardization of a minimum set of administrative
access and operational functions such that developers of registries can deploy standard mechanisms to
streamline and increase accuracy and productivity of these maintenance operations.
4 © ISO 2015 – All rights reserved
This Technical Specification describes a generic exchange format that will cover the minimal set of
metadata and associated rules for OIDs of existing registries. It specifies principles and processes that
should be explored/implemented by developers and data administrators of OID registries and their
applicant bodies. The primary target group for this Technical Specification are those establishing OID
registries and those (industry, government bodies) using the services maintained by such organizations.
5.2 Additional descriptions
In this Technical Specification, Annex A gives a description of possible sub trees reflecting OID
categories for e-health related OIDs is given.
Annex B specifies the Use Cases of an OID registry/repository and an Object Identifier Resolution
System (ORS) for e-health related OIDs based on restful Web Services.
Annex C references a W3C schema for the XML representation.
5.3 Related work
This work is related to discussions about OID in the work programme of ISO/TC 215, HL7 International,
ISO/IEC JTC 1/SC 6, ITU-T SG 17 and other organizations dealing with OIDs and OID registries.
6 Approach
6.1 Requirements analysis
Following an extensive analysis of the currently available international OID registry for health care
systems, a basic data set and a corresponding XML representation as an exchange format needed to
be created for registering and exchanging OID-related data. To collect the very basic requirements for
such a format an analysis of several registries, e.g. HL7 International registry at hl7.org and several
European OID repositories (France Telecom-Orange, see http://www.oid-info.com, German OID
registry at DIMDI, see http://www.dimdi.de) was performed so far in 2009 (see Table 1). The analysis
included the contents, attributes, and even the rules of the assignment of OID.
Table 1 — Analysis of some data elements of different OID registries and repositories
(analysis as of 2009)
DIMDI France Telecom-Orange OID re- HL7 International
pository
DESCRIPTIONENGLISH DESCRIPTION, INFORMATION OBJECT_DESCRIPTION
DESCRIPTIONGERMAN
ASN1NOTATION ASN1-NOTATION COMP_OID
MODIFICATIONDATE MODIFICATION-DATE
CREATIONDATE CREATION-DATE DATE_FINALIZED
APPLICATIONDATE
TYPE OID_TYPE
FAMILY LAST-NAME NAME
GIVEN FIRST-NAME NAME
Only a few of the registries specified an (XML-) exchange format. Due to lack of a common understanding
of OID registry requirements, data fields needed to be mapped (manually) when OID information
needed to be exchanged.
6.2 Preparatory work
This Technical Specification has been prepared by Technical Committee ISO/TC 215, in collaboration
with HL7 International, ISO/IEC JTC 1/SC 6 and ITU-T SG 17.
The draft of this Technical Specification has had multiple public comment phases (started in April 2010)
with the submission and reconciliation of about 80 comments and has undergone a proof-of-concept
phase in OID registry/repository projects in several European countries.
7 Information model
7.1 General
In order to exchange OID and their metadata between different registries and applications, the
following additional data items beyond the OID itself need to be taken into consideration (see also
Recommendation ITU-T X.667 | ISO/IEC 9834-8, http://www.itu.int/rec/T-REC-X.667/en, and FAQs at
oid-info, http://www.oid-info.com/faq.htm#iri):
— descriptions;
— status information;
— categorization;
— time information;
— comments;
— versions;
— links;
— relationships to other OIDs and external sources;
— registering and responsible organizations;
— associated persons.
An information model with all classes, attributes, and their properties aiming for a common
understanding of the requirements of an OID registry/repository has been created (see Figure 1).
Additional remarks are as follows.
— The colours are taken from ISO/HL7 21731, the light green classes “Person” and “Organization” are
exact copies of the definitions of the green classes “Person” and “Organization” to avoid repeating
the class attributes. Boldface associations names reflect mandatory associations (see also 7.2.1).
— A coded attribute may have a vocabulary binding denoted by the symbol “<=”, e.g. in the registration
authority class RegistrationAuthority, the code is bound to use the vocabulary defined in value
set/enumeration “RoleCodes”.
6 © ISO 2015 – All rights reserved
Figure 1 — Information model for OID registries and repositories
7.2 Agenda of tables and symbols
7.2.1 Class attribute and associated tables
The Class Attribute Tables (information model) make use of the following table headline:
Class Attribute Description DT Card Conf Length
Class Attribute = class attribute name
Description = description (meaning) of the attribute
DT = datatype (or datatype flavour) conformant to the ISO 21090 datatypes,
Card = cardinality, e.g. 0.1 or 1.*
Conf = conformance, either
— mandatory, which means that the information SHALL be present in every instance of an extract of
an OID registry/repository,
— required, which means that the information SHOULD be provided if there are no privacy reasons for
masking that information, or
— optional, when information is optional.
Length = recommended length (as an implementation hint, e.g. for database string lengths).
In addition, the Association Tables (information model) make use of the following table headline:
Association Description Class Card Conf
Association = the association name to the associated class
Class = the associated class name
7.2.2 Conformance statements
Some class attributes or associations may have additional constraints, denoted by a paragraph
starting with “CONF” with an abbreviated identifier of that rule as a suffix (e.g. “rg-vt”) followed by the
conformance statement.
EXAMPLE
CONF rg-vt: A validTime element SHALL be present and of datatype IVL_TS with at least the low child
element populated.
7.3 XML exchange format
Data exchange can be facilitated by a standardized representation of the complete set of information
as an XML structure together with the associated checks of underlying constraints and business rules.
This XML structure for importing and exporting OID among different registries and other healthcare
applications is dependent upon the availability of reliable information about OIDs.
The following subclauses summarize and explain classes and their attributes.
7.4 Registry
This is the basic information about the OID registry/repository hosting the OIDs (see Figure 2).
Figure 2 — Registry
7.4.1 Attributes
Class Attribute Description DT Card Conf Length
validTime validity time interval IVL_TS 1.* mandatory -
scopedOIDs List of scoped root OIDs ST.OID 0.* optional 64
name Official name of the OID registry ST 1.1 mandatory 64
description Description of the OID registry, ST 0.* optional -
possible in multiple languages
lastModifiedDate date of last modification TS 0.1 optional -
8 © ISO 2015 – All rights reserved
7.4.1.1 validTime
This is the validity time interval, i.e. the begin (and end) time when this registry is/was responsible for
registering OIDs. This can be a list of intervals.
CONF rg-vt: A validTime element shall be present and of datatype IVL_TS with at least the low child
element populated.
7.4.1.2 scopedOIDs
List of scoped root OIDs, i.e. the OIDs for which this OID registry is responsible for registration. OIDs
listed here should be those under which this registry creates child OIDs, but this entry is only the top
OID of the tree; more than one entry may be here if this registry creates OIDs under more than one
disjoint root.
CONF rg-so: If the OID registry is responsible for issuing/registering a root OID, this OID should be
listed in scopedOIDs.
7.4.1.3 name
Official name of the OID registry.
7.4.1.4 description
A description of the OID registry, possible in multiple languages.
CONF rg-ds: If at least one description element is present, one of the description’s language codes shall
be English (“en”, “en-US”, etc.).
7.4.1.5 lastModifiedDate
The lastModifiedDate is used to describe when information in the OID registry was last modified.
7.4.2 Associations
Association Description Class Card Conf
person Contact person(s) Person 1.* required
hostingOrganization Hosting organization(s) Organization 1.* mandatory
oid List of OIDs Oid 0.* required
7.4.3 Example
.
.
.
7.5 Oid
This class contains the registered OID and the associated metadata (see Figure 3).
Figure 3 — OID
7.5.1 Attributes
Class Attribute Description DT Card Conf Length
dotNotation registered OID, dot notation ST.OID 1.1 mandatory 128
asn1Notation ASN.1 notation ST.ASN1 0.1 optional 128
iriNotation IRI notation ST.IRI 0.1 optional 128
symbolicName symbolic name ST.SYMB 0.1 optional 128
category OID category CS 1.1 required -
status OID status CS 1.1 mandatory -
creationDate date of creation TS 0.1 optional -
lastModifiedDate date of last modification TS 0.1 optional -
realm Countries CS 0.* optional -
description textual description ED 1.* mandatory -
7.5.1.1 dotNotation
The OID in dot notation of SNMP or ASN.1/XER.
EXAMPLE 2.16.528
7.5.1.2 asn1Notation
The OID in ASN.1 notation with (optional) identifiers and numbers.
EXAMPLE {joint-iso-itu-t(2) country(16) nl(528)} {itu-t(0) recommendation(0) a(1)}
NOTE 1 The surrounding curly brackets can be omitted.
NOTE 2 This information is not necessarily entered by a human; this item maybe populated algorithmically.
7.5.1.3 iriNotation
The OID in Internationalized Resource Identifier (IRI) notation.
EXAMPLE oid:/Country/528
NOTE This information is not necessarily entered by a human; this item maybe populated algorithmically.
10 © ISO 2015 – All rights reserved
7.5.1.4 symbolicName/Secondary arc identifier
A symbolic short name, unique among the siblings of the arc of the OID.
The ISO rules on Secondary Arc Identifiers, as laid out in Rec. ITU-T | ISO/IEC 9834-1:2012, 6.2.2, apply:
— identifiers of an arc are required to commence with a lowercase letter and to contain only letters,
digits, and hyphens;
— the last characters shall not be a hyphen;
— there shall be no two consecutive hyphens in the name.
EXAMPLE nl
7.5.1.5 category
The type/category of the OID; enumeration, values see enumeration OIDcategories.
There are actually two main types of OIDs: leafs (id of an object), and nodes representing an
ontological branch.
The type
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...