8.5. URI of a Manifestation

Characterizing the Manifestation is the specific process that generated an electronic document in some specific format(s). This includes specifications of the data format. Therefore, different manifestations of the same expression generated using different data formats correspond to different manifestations and will have different URIs.

Manifestations are organized in components (the ManifestationComponents), and therefore we need to identify separately the Manifestation as a whole as well as the individual URIs for each ManifestationComponent. All of them are all immediately derived from the baseline, which is the URI for the EXPRESSION.

The URI for the manifestation as a whole

The URI for the Manifestation as a whole consists of the following pieces:

• The URI of the corresponding EXPRESSION as a whole
• The character “.”
• A unique three letter acronym of the data format in which the manifestation is drafted. The acronym can be “pdf” for PDF, “doc” for MS Word, or “xml” for the XML manifestation.
• The akn for the package of all documents including XML version of the main document(s) according to the Akoma Ntoso rules.

• http://www.authority.org/dz/debaterecord/2004-12-21/fra/main.doc
  Word version of the Algerian parliamentary debate record, 21st December 2004., French version
• http://www.authority.org/sl/act/2004-02-13/2/eng/main.pdf
  PDF version of the Sierra Leone enacted Legislation. Act number 2 of 2004.  English version, current version (as accessed today)
• http://www.authority.org/sl/act/2004-02-13/2/eng@2004-07-21/main.akn
  Package of all documents including XML versions of the Sierra Leone enacted Legislation. Act number 2 of 2004.  English version, as amended in July 2004>

The URIs for ManifestationComponents

Each ManifestationComponent is an independent electronic structure (e.g., a file) in a single data format. Every type of manifestation has of course a different data structure and file structure. Therefore the actual format of the URIs of the components of the manifestation depend on the data format and cannot be formalized in general. In this section we therefore provide a grammar but not an exhaustive list of formats, that depends on the data format chosen for the manifestation.

The URI for each ManifestationComponent consists of the following pieces:

• The URI of the corresponding EXPRESSION as a whole
• The character “/”
• Some unique identification of the ManifestationComponent with respect either to the manifestation as a whole or to the ExpressionComponent the component is the manifestation of.
• The character “.“
• A unique extension of the data format in which the manifestation is drafted. The acronym can be “pdf” for PDF, “doc” for MS Word, “xml” for XML documents, “tif” for image formats, etc.

In the next section we will examine the format of the package and the relevant URIs for a specific manifestation of Akoma Ntoso documents, the XML format. 

The URIs for the components in the Akoma Ntoso package manifestation

The Akoma Ntoso package manifestation is a very specific manifestation using a number of data formats (mainly XML but could include other multimedia formats as needed) with a very specific organization of parts and components. Since it makes explicit choices in terms of data formats and reciprocal references, it is important to provide clear and non-ambiguous rules as to the internal naming mechanism and its overall structure.

An Akoma Ntoso package manifestation is a package composed of one or more files organized in a flat fashion. The transportable format is a ZIP file whose extension is “.akn”. Other formats are possible and acceptable as long as they adhere to these rules.

The following are alternative options for the Akoma Ntoso package:

• If the document is just composed of text and does not refer to any multimedia fragment of any form, then the ZIP package contains a single document called “main.xml”.
• If the document is composed of many ManifestationComponents but does not refer to any multimedia fragment of any form, then the zip package is composed of many XML files, one for each ExpressionComponent. Each ManifestationComponent is then called as its corresponding ExpressionComponent, plus the “.xml” extension. The name “main” is reserved for the main component. Numbers are never used.  
• If the document contains multimedia fragments of any kind, then each individual fragment does not have a corresponding ExpressionComponent, but is just a ManifestationComponent referred to in the img or object element. All multimedia components must be stored within an inner structure (e.g., a folder) called “media”. Multimedia components can be called freely, but must use the appropriate extension to refer to their content type. Thus a logo can be called “logo.tif” or any other name, as long as the extension is correctly specifying the content type.

Reciprocal references to ManifestationComponents are necessary within a specific manifestation. For instance, the manifestation of the main document refers to the manifestations of its attachments via the attachment elements, and the schedule showing an image refers to the file of the image via the img element. In these cases, all references MUST be relative to the package (i.e., the manifestation as a whole):

• attachment1.xml
  Manifestation of the first attachment of the current document
• schedule3.xml
  Manifestation of the third attachment of the current document
• media/logo.tif
  Manifestation of an image within the current document

References to ManifestationComponents are rarely, if ever, needed outside of the manifestation themselves. But if needed, they will refer to the file as follows:  

• The URI of the corresponding EXPRESSION as a whole
• The character “/”
• The relative reference to the required ManifestationComponent as specified above.