In day-to-day language, we use the term “document” to refer to many different things: an official record, a collection of different documents, a report, an official letter, etc. to list just a few. The dictionary definition of documents goes:

“any content whatever its medium (written on paper or stored in electronic form or as a sound, visual or audio-visual recording) that provides information or evidence or that serves as an official record”.

Here we are not particularly interested in the medium, instead we would like to make the distinction between what we call:

“Document”: the "physical" document as it appears to the readers in whatever medium it may be, whether on paper, electronic format, etc. Please note that here we use “document” in its more generic meaning of the action of making something generally known, by publishing it to an audience;

and

“Logical Component”: any logically and functionally distinct component of a “document”.

Let’s take the typical life-cycle of a resolution to explain this with a concrete example.

The first appearance of a resolution may be in a letter that the proponent sent to a deliberative body, or its members, to inform it of his/her intention to submit a resolution.

Subsequently, the resolution may be issued in a publication series as “draft resolution” or in documents of a different nature, e.g. committee reports.

When eventually the resolution is discussed in a deliberative body, if approved, it may be published as an adopted resolution in a publication series or in the official records of the relevant meeting.

In the last stage of a resolution life-cycle, it may be published in the official compilation and that may become its “authoritative version”.

The whole life-cycle of a resolution actually takes place through a series of “documents” in which the resolution takes different “forms” as you may see in the table below.

Table 7. Lifecycle of a Resolution

As we may see from the table above, the resolution, as a logical component, may appear in any of the following forms: in the body of the hosting document, as an attachments of a hosting document or as a component of a container of other documents, etc.

In order to trace the path of a resolution from its first draft till the end of its lifecycle, there is a need to make the very critical distinction between the “document”, as it appears to the readers, and the “logical component”, which is any functionally distinct component of a “document”.

The “logical resolution” is a structurally distinct component that persists across the different “documents” where a resolution may appear in its lifecycle, as we show in the table below.

Table: Lifecycle of a resolution: distinguishing between document and logical component

The distinction between “document” and “logical component” is very critical and used throughout the Guidelines.

NOTE: In the context of these Guidelines “document” and “logical component” will be used to mean respectively “physical document as it appears to the readers in whatever medium it may be” and “any logically and functionally distinct component of a document”.

A survey of the different parliamentary, normative, judicial and official documents used by all participating organizations was carried out by the HLCM Working Group on Document Standards (WG) late in 2016.

The UN Document Classes are meant to represent different typologies of documents across their complete lifecycle by identifying commonalities and patterns in function and structure. The UN Document Classes do not aim to represent any specific typology of documents of an organization. They are designed to represent:

The core feature of UN document types. They are meant to describe classes of documents that, to a large degree, have the same function, play the same legal role and have the same content structure across UN organizations.

The whole lifecycle of documents, from when they were drafted until when its workflow has been completed in all its forms and not just a specific state.

The different UN Document Classes represent abstract typologies of documents because they do not refer to any specific stage of their workflow or specific publications form in which documents may be disseminated.

The Document Classes identified by the HCLM WG are listed in the table below.

Caveat: the definitions below are to be considered only as a general description with the sole purpose of providing an indication of the types of documents that may belong to each class and subclass.

Please see Annex I for a detailed list of AKN4UN Document Classes.

Table: UN Document classes identified by the HLCM-WG

Please note that “Publication Document Class” is essentially meant to be used as “container” of “logical components”. The subclass “publication” is used for standalone physical documents; while “official compilation” is meant for document containing several authoritative versions of documents, and “collection” is more a kind of “folder” containing even quite different documents.

Before we go through the list of AKN documentTypes we have to keep in mind that, in Akoma Ntoso, documentTypes have the following properties:

They are abstract categories, like UN Document Classes. They do not model any specific document, but only categories of documents that share broadly the same functions, legal roles and content structures.

Their names are just labels, and do not have to be taken literally. For example, the AKN documentType <act> is not meant to model only “acts”, but all documents that are considered normative and structured in hierarchies.

They uniquely identify different types of documents via the attribute @name, e.g. <act name=”{local name}”>.

NOTE: AKN4UN Document Classes are meant to model “logical components” that make up a physical document. Physical documents may so be modelled by one or more AKN4UN Document Classes.

The table below presents the correspondence between the UN Document Classes and the Akoma Ntoso documentTypes. An AKN4UN compliant document must use:

The mandatory documentType, which must be set to one of the prescribed values indicated in the table below.

The mandatory @name in all document type elements. The value of the attribute @name is left open for the individual organization to choose what best fits the name of their specific document. The list below should be considered only as indicative but every effort should be made to keep it updated and when possible reuse existing values.

The mandatory subtype value, which must be set to one of the prescribed values as indicated in the table below, to be used as value of <FRBRSubType> and for the subtype component of document IRI.

For example, a treaty document type would be:

<act name=”treaty”> while its document IRI would be /akn/{jurisdiction}/act/provision/{actor}/{date}/{docNumber}

See AKN4UN Naming Convention section for more details.

Mapping of UN Document Classes to AKN Document Types