The AKOMA NTOSO naming architecture is built so as not to rely on the existence of a single storage architecture, since the URIs stored within documents are differentiated from the ones physically representing the resource being sought.

The mapping from architecture-independent URIs into accessible architecture-dependent URLs (representing the best ITEM for the document being sought) are realized through specific applications called URI resolvers.

The AKOMA NTOSO naming architecture is also built so as not to rely on the existence of any individual URI resolver, but assumes that all URIs are correctly resolved in the best available ITEM regardless of the resolving mechanisms. In fact, each naming authority is given the same task of resolving all possible Akoma Ntoso URIs, regardless of whether they belong or not to the country or countries they represent.

This implies that the authority-specific details of URIs are purposefully omitted in this specification, and need to be considered only when first accessing a document. For this reason, all URIs in this specification are prefixed with the arbitrary domain name http://www.authority.org/ that stands for any of an arbitrarily large number of equivalent naming authorities.

The URI for the Work as a whole

The URI for the WORK is the baseline for building the URI for the EXPRESSION, which is the baseline for the URI of the MANIFESTATION. All these URIs use the http:// prefix, but the names never refer to physical storage of the documents.

The URI for the WORK consists of the following pieces:

• The base URL of a naming authority with URI-resolving capabilities
• A detail fragment organizing in a hierarchical fashion the additional data:
• Country (a two-letter code according to ISO 3166-1 alpha-2)
• Type of document
• Date (expressed in YYYY-MM-DD format or YYYY if the year is enough for identification purposes)
• Number (when appropriate, otherwise nn

All components are separated by forward slashes ("/") so as to exploit relative URIs in references.

• http://www.authority.org/dz/debaterecord/2004-12-21
  Algerian parliamentary debate record, 21st December 2004.
  
  
• http://www.authority.org/sl/act/2004-02-13/2
  Sierra Leone enacted Legislation. Act number 2 of 2004.
  
  
• http://www.authority.org/ng/bill/2003-05-14/19
  Namibia Bill number 19 of 2003
  
  
• http://www.authority.org/mg/act/2003-03-12/3
  Madagascar. Act 3 from 2003

The URI for WorkComponents

Although components are really belonging to each expression only, it so happens that the legislator quite often makes work-level references to components, which thus need to have a work-level URIs as well. Not only, but it may happen (and it has happened in the past several times) that the component (e.g., an attachment) may change name, or position, or even hierarchical placement, time after time.

For instance, we could have that an original act refers to table A of schedule 1, and after a little time schedule 1 is completely abrogated, and thus table A becomes (implicitly) an attachment of the main document. As such, it is important that all references to table A of schedule 1 are considered as references to table A of the main document after that event.

This brings about the necessity to have URIs for Work Components. These are to be used when referring in a work-level fashion to components that have official names and positions, but may change in name and position with time.

One problem is that a work-level component URI has no expression-level part, and yet the component part is AFTER the expression level part. Therefore, it is necessary to make sure that a work-level URI fragment is never mistaken for an expression-level or a component-level URI fragment.

But since:

1. The number part of the work-level URI (/nn/) is required even in unnumbered documents ("/nn/"  for not numbered).
2. The expression fragment, if present, always has at least the language and the "@" character, and the @ character can only be used for expression fragments.

The absence of a part containing the "@" character indicates a work-level component reference after the 4th component (the number).

• /kn/act/2007-01-01/1/schedule1

Kenya, schedule 1 of act 1 from 2007 (WorkComponent)

URIs for virtual expressions

In some situations the actual enter-in-force date of the expression is not known in advance, and it is necessary to create references or mentions of documents whose URI is now known completely (possibly, because their exact delivery date is not known yet). These are called virtual expressions (i.e., references to expressions that probably do not exist yet or ever, but can be unambiguously deduced once all relevant information are made available).

We must distinguish three cases in such situation:

• the information is not known by the author of the expression (e.g., the legislator), in which case the act of actually retrieving the correct information is an act of interpretation;
• the information is not known by the editor of the expression (e.g., the publisher of the XML version of the document), in which case the information can theoretically be available, but is too much of a burden for the publisher to retrieve it.
• the information is not know by the query system.

In all these cases, the syntax for the URI of the virtual expression uses a similar syntax to the specification of the actual expression, but the character “:” is used instead of the “@” after the specification of the work URI.

For instance, if we need to reference the expression of an act in force on date “1/1/2007”, we will probably need to refer to some expression whose enter in force date was in a previous date to 1/1/2007.

http://www.authority.org/sl/act/2004-02-13/2/eng:2004-07-21

Sierra Leone enacted Legislation. Act number 2 of 2004.  English version, as amended on the closest date before July 21, 2004

The Akoma Ntoso makes no assumption on the physical storage mechanism employed to record actual manifestations. As such, there is NO rule for URIs of the items, which are free to assume any form whatsoever and correspond to whatever storage mechanism has been employed locally.

On the other hand, the actual URL for the item must be provided to a resolution mechanism in order for the hypertextual feature of the Akoma Ntoso publication systems to work correctly and automatically.

The object of all discourses within the Akoma Ntoso framework can be described as a set of abstract classes and their instances and of the relationship among them. Cumulatively, definition of classes, relationships and instances are called an ontology.

The four most important classes of the Akoma Ntoso ontology are surely connected to documents,  Work, Expression and Manifestation, but many more exist, even if they are not connected directly to physical documents. The purpose of this section is to provide a syntax for non-document entities, i.e., instances of non-document classes, such as people, organizations, concepts, etc. Furthermore, the syntax described here can also be used for document entities as an equivalent syntax to the one specified in the previous sections.

Akoma Ntoso entities are always associated to a class, which provides a structure of properties and relationships to other instances of the same and other classes. Classes in the Akoma Ntoso ontology are organized in a complex maze of sub/superclasses. These are useful to give shape and meaning to a domain, and to provide structure to the overall set of instances of a base class. It is important to notice that sub/superclasses do not form necessarily a tree, but can form a more complex structure, namely a directed graph.

For instance, the class of Kenyan judges can be considered a sub class of both Kenyan persons and of persons whose job description is judge. That is, there is a (implicit or explicit) subclass of Judges and a (implicit or explicit) subclasses of Kenyans, both of which are in turn subclasses of Person, and Kenyan Judges is a subclass of both. In fact, we immediately derive the principle that every different value in every different property or relationship implicitly generates a class, that turns into an explicit class only because of our whim or need. For instance, the class of all persons named “Joe” exists implicitly, identifies all persons whose first name is “Joe”, and, if so desired, can be made explicit through the definition of a subclass of Person.

While this is very useful for determining relationships between entities, it affects interestingly the mechanism to associate URIs to such entities. In particular, there being no single hierarchy of classes, it is not appropriate to propose a single path of specifications from the super class to the final class. As such, ideally /person/judge/ke/JoeSmith must point to the same individual as /person/ke/judge/JoeSmith.

In order to maintain meaningfulness, permanence and invariance (which are the main requirements for our naming convention, as specified in the introduction of this document) we need to find a reliable naming mechanism for clearly identifying entities that does not depend on the sub/superclass organization except when strictly necessary.

In particular, we define the concept of Top Level Classes (TLC) that are guaranteed to be a partition of the overall domain of the Akoma Ntoso standard. TLC include Work, Expression, Manifestation, Item, Person, Organization, Concept, Object, Event and Place. The list of TLC may include in future more classes (e.g., Process, Role, Term, and more yet to be determined), as long as they keep on generating a partition (i.e., that they are disjoint and cumulatively describe all possible instance of the Akoma Ntoso domain). Members of the TLC classes can be subclassed at will and with no theoretical constraints.

Given the high number of foreseeable subclasses of the TLC, and the pointlessness of determining a fixed hierarchy in such number, the naming of entities should not depend on the presence or absence of a given class except for TLC. This means that it is necessary that each instance of each TLC is provided with an ID string that is guaranteed to be unique within the TLC. The syntax of this ID is dependent of the TLC class, and the syntax for each of the existing TLC is provided  in the next section.

Therefore, the URI for non-document entities consists of the following pieces:

• The base URL of a naming authority with URI-resolving capabilities
• A detail fragment organizing in a hierarchical fashion the additional data:
• The string “/ontology”
• The official name of the appropriate TLC
• Any number (including none) of slash-separated subclasses of the TLC, as long as they all refer to correct properties of the corresponding instance
• The ID of the instance, guaranteed to be unique within the TLC.

All components are separated by forward slashes (“/”) so as to exploit relative URIs in references.

• http://www.authority.org/ontology/person/ke.joe.smith.1964-12-22
  Joe Smith
  
  
• http://www.authority.org/ontology/person/ke/ke.joe.smith.1964-12-22
  Joe Smith (implying that he is a Kenyan)
  
  
• http://www.authority.org/ontology/person/ke/judge/ke.joe.smith.1964-12-22
  Joe Smith (implying that he is a Kenyan who is a judge)
  
  
• http://www.authority.org/ontology/person/judge/ke/ke.joe.smith.1964-12-22
  Joe Smith (implying that he is a judge who is a Kenyan)
  
  
• http://www.authority.org/ontology/person/kenyanjudge/ke.joe.smith.1964-12-22
  Joe Smith (implying that he is a Kenyan judge)
  
  

Please note that the classes Work, Expression, Manifestation and Item belong to the ontology as much as the other classes. As such, each Work, Expression and Manifestation can also be indicated with an ontology-based URI that refers to exactly the same entity.

Therefore, the following URIs are equivalent pair-wise, and refer to the same entities:

• http://www.authority.org/sl/act/2004-02-13/2
  http://www.authority.org/ontology/work/sle.act.2004-02-13.2
  
  
• http://www.authority.org/sl/act/2004-02-13/2/eng@2004-07-21
  http://www.authority.org/ontology/expression/sle.act.2004-02-13.2.eng@2004-07-21
  
  
• http://www.authority.org/sl/act/2004-02-13/2/eng@2004-07-21/main/schedule1
  http://www.authority.org/ontology/expression.component/sle.act.2004-02-13.2.eng@2004-07-21.main.
  schedule1
  
  
• http://www.authority.org/sl/act/2004-02-13/2/eng@2004-07-21/main.akn
  http://www.authority.org/ontology/manifestation/sle.act.2004-02-13.2.eng@2004-07-21.main.akn
  
  

The IDs for Top Level Classes

As mentioned in the previous section, the hierarchy of path elements is of no use for identifying instances of each TLC, given the fact that there can be no unique hierarchy of subclasses in the Akoma Ntoso ontology.

Thus each instance of the ontology needs to be provided with an ID guaranteed to be unique within the TLC it belongs to. The syntax of the ID depends on the actual TLC, and is briefly explained in the following schema.

TLC Person

A dot-separated string composed of the country of citizenship, the first name, the family name, the birth date in yyyy-mm-dd format, and an optional arbitrary string if ambiguity exists (e.g., if two individuals with the same name and the same birth date exist in the same country).

• ke.joe.smith.1964-12-22
  Mr. Joe Smith, the only Kenyan citizen with that name born on December 22nd, 1964
  
  

TLC Organization

A dot-separated string composed of the country of registration (or the string “int” if international, or the string “unreg” if not registered anywhere), a recognizable form of the organization name and an optional arbitrary string if ambiguity exists (e.g., if two organizations with the same name exist in the same country).

• ke.parliament
  the Kenyan Parliament
  
  

TLC Concept

A unique form of the terms specifying the concept joined with dots. No country specifications are necessary for concepts

• Presidential.election
  the concept of Presidential Election
  
  

TLC Object

T.B.D.

TLC Event

T.B.D.

TLC Place

T.B.D.

TLC Process

T.B.D.

TLC Role

T.B.D.

TLC Term

T.B.D.

TLC Work

The domain-less URI of the work as specified in this document, with all slash substituted by dots.

• sl.act.2004-02-13.2
  Sierra Leone enacted Legislation. Act number 2 of 2004.
  
  

The domain-less URI of the work as specified in this document, with all slash substituted by dots.

• sl.act.2004-02-13.2.en@2004-07-21
  Sierra Leone enacted Legislation. Act number 2 of 2004.  English version, as amended on July 2004
  
  

The domain-less URI of the work as specified in this document, with all slash substituted by dots.

• sl.act.2004-02-13.2.en@2004-07-21.schedule01
  Attachment “schedule01” of Sierra Leone enacted Legislation. Act number 2 of 2004.  English version, as amended on July 2004
  
  

The domain-less URI of the work as specified in this document, with all slash substituted by dots.

• sl.act.2004-02-13.2.en@2004-07-21.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
  
  

T.B.D.

TLC Item

T.B.D.