AKOMA NTOSO in detailAKOMA NTOSO defines a set of recommendations and guidelines for e-services in a world-wide context. This framework is an essential prerequisite for interlinking and web-enabling Parliaments and Courts. It addresses information content and recommends technical policies and specifications for connecting information systems across countries.This initiative enables open access to information by focussing on both “semantic” and “technical” interoperability at the document level. * Semantic interoperability is concerned with ensuring that the precise meaning of exchanged information is understandable by any person or application receiving the data. The majority of AKOMA NTOSO's efforts are dedicated to this area. * Technical interoperability is aimed at ensuring that all AKOMA NTOSO-related applications, systems and interfaces are based on a shared core of technologies, languages and technical assumptions easing data interchange, data access and reuse of acquired competencies and tools. AKOMA NTOSO ensures technical interoperability by enforcing the use of open standards and open document formats, all of whom are based on the XML (eXtensible Markup Language) language, whose specifications are a world-wide standard and for which numerous tools and applications have been developed and are widely available. By adopting AKOMA NTOSO specifications, parliamentary and court system designers can ensure interoperability between systems while at the same time enjoy the flexibility to select different hardware, and systems and application software to implement solutions.Akoma NtosoAN_ca0f28c8-5502-11e1-bc05-f8717a64ea2aAkoma Ntoso (“linked hearts” in Akan language of West Africa) defines a set of simple, technology-neutral electronic representations of parliamentary, legislative and judiciary documents for e-services in a Pan-African context and provides an enabling framework for the effective exchange of "machine readable" parliamentary, legislative and judiciary documents such as legislation, debate record, minutes, judgements, etc. Providing access to primary legal materials, parliamentary works and judiciaries documents is not just a matter of giving physical or on-line access to them. "Open access" requires the information to be described and classified in a uniform and organized way so that content is structured into meaningful elements that can be read and understood by software applications, so that the content is made "machine readable" and more sophisticated applications than on-screen display are made possible. The opportunity to make visible the structures and semantic components of parliamentary, legislative and judiciary documents to software applications means to be able to use the huge capacity of ICTs to manipulate documents not as just plain undifferentiated text but in their structure and semantic components so that high value information services can be developed to assist institutions and citizens to better play their respective roles.AfricaParliamentsCountry Parliaments and Courts should use the guidance provided to supplement their national e-Government Interoperability Frameworks with a world-wide dimension and thus enable world-wide interoperability of Parliaments. AKOMA NTOSO is meant to supplement, rather than replace, national interoperability guidelines that may exist in loco by adding to them a world-wide dimension.CourtsUsersAKOMA NTOSO aims at providing support for a large number of tasks and users spread throughout time, space and competencies. The types of potential users that might end up using or benefiting from AKOMA NTOSO can be grouped in the following categories:AuthorsThe “author” -- The “author” can be a member of a Parliament, a Judge, a legal practitioner or a clerk/personal assistant of them. He/she is currently drafting a new piece of legislation, due to be discussed which maybe, approved in a future session of the Parliament, or preparing a judgement. “The author” might not be aware of the existence of AKOMA NTOSO, XML, or any such technicality. He/she might, or might not, be aware of the existence of guidelines in the formal drafting of law and judgements. Yet he/she does not know what XML is, and does not care. But he/she wants be able retrieve bills, acts, judgements, etc. effectively, and to be able to access explicit references to other laws made in them, etc. The ”author” also wants to be able to access “point-in-time” consolidations of laws that provide a version of the original act updated to a specific point in time through the application of all the subsequent amendments , and wants easy and effective tools to find and retrieve bills, acts, judgements, etc. to carry out his/her duties more effectively.DraftersThe “drafter” -- The “drafter” is a member of the office supporting the process of drafting of legal documents, be it of legislation, parliamentary proceedings or judgements. During the work-flow phase, the “drafter” receives all proposed text modifications to a document being drafted abd generates any of a number of documents used by the “authors” (e.g., members of the Parliaments, judges, etc.), such as summaries, synaptic views of amendments, etc.. When the proposed document is finally approved, he/she creates the final version of it, either directly in an XML editor using the AKOMA NTOSO format or in a word processing application creating a file that is then translated into AKOMA NTOSO XML by some downstream process phase. The “drafter” is a domain expert in a specific matter, e.g legislation, judgements, etc. , and has some, even minor, computing experience, but he/she is definitely no computer programmer or scientist. He/she is aware of AKOMA NTOSO and knows about its structural and semantic requirements but he/she may know very little about XML and he/she will never be exposed or required to know anything about XML. Yet he/she is usually required to be very knowledgeable about the structures, semantics and explicit and implicit information the the document he/she is drafting carries.ToolmakersThe “toolmaker” -- The “toolmaker” is a computer scientist working for a computing firm who has a contract for creating AKOMA NTOSO software for a specific Parliament or Court. The “toolmaker” may need to create a specialized editing tool by customizing a well-known Word Processor (such as OpenOffice.org or MS Office) or a conversion tools that creates valid AKOMA NTOSO documents recognizing formatting characteristics of the input texts, or any possibly as yet unforeseeable tool doing advanced processes on AKOMA NTOSO documents. He/she is given the goal of making the tools usable by the “drafter” and his/her colleagues, and at the same time make it generate documents that are compatible with AKOMA NTOSO rules. Differently from the “drafter”, the “toolmaker” has full access to the AKOMA NTOSO documentation, and can talk to his users to understand together what each part of AKOMA NTOSO really is relevant to their task and how to proceed.CitizensThe “citizen” -- The “citizen” of a country where the AKOMA NTOSO system is being used, he/she might be a lawyer, a public employee, an business person or just any ordinary citizen needing fast and easy access to laws legislation or judgements for his/her own purposes. His/her main objective is searching for laws and judgements either through an explicit reference (e.g. “section 36(2)(c)(ii) of Act 2-1999”) or via a search interface (either textual or exploiting vocabularies and ontologies specified through the AKOMA NTOSO metadata). The “citizen” doesn’t know what AKOMA NTOSO is meant to deliver, that the project is meant to provide the text of legal documents through some kind of esoteric machinery behind the scenes, he/she does not know what XML is, and does not care. He/she wants his/her web browser to display the text of the acts, proceedings and judgments he/she searched, and wants all explicit references to other documents to be hypertext links that can be navigated with ease and immediacy, and wants a reasonable interface that lets him/her read the text on the screen and, when necessary, print it on paper.Future ToolmakersThe “future toolmaker” -- The “future toolmaker” is 10 years old now. He/she is playing with his school friends and does not know anything about AKOMA NTOSO and does not care. Yet. He/she is in this list because in fifteen years, when he/she’ll be 25, he/she will be a professional computer programmer and will have to create new tools for AKOMA NTOSO. The key difference between the “toolmaker” and the “future toolmaker” is that the “future toolmaker” may not have access to the complete documentation of the AKOMA NTOSO project, because things may have been changed globally or locally with little or no formal records, and people responsible for these changes may have moved, retired or forgotten about the changes altogether. He/she may only have sparse documentation of the actual features of the system. Furthermore, he/she will have to deal with a fairly stratified situation where the basic ideas (on which today's “toolmaker” has worked) have evolved, modified, expanded and changed emphasis. Furthermore, more often than not these changes have happened slowly and without documentation. The only sure thing that the “future toolmaker” has to work on is more than 15 years of legislation available in XML format, whose documentation is introductory for certain, but far from complete and sufficient. Fortunately the early AKOMA NTOSO decisions have been to have the XML format be as self-explanatory as possible, so that he/she can, in principle, deduce all undocumented facts about AKOMA NTOSO by simply examining a few relevant XML instances of the legislation and discovering there how it should work. In a sense, the “future toolmaker” is more a key user for our system than the “toolmaker”, and the possibility for the “future toolmaker” to deduce fundamental properties of AKOMA NTOSO from the visual examination of XML documents will make us sure of long-term existence and usefulness of the AKOMA NTOSO system itself.Akoma Ntoso fulfils the citizens' right to access parliamentary and judiciary proceedings and legislation by providing "open access" and advanced functionalities like "point-in-time" legislation through standardised representations of data and metadata in the parliamentary and judiciary domain and mechanism for citation and cross referencing of legal documents to also improve data exchange and document life cycle automation._ca0f2ca6-5502-11e1-bc05-f8717a64ea2aTo develop a number of connected standards and languages and guidelines for parliamentary, legislative and judiciary documents_ca0f2e2c-5502-11e1-bc05-f8717a64ea2aOpen Access"meaning" and "structure" of every element in a parliamentary, legislative or judiciary document will be available to software applications.InteroperabilityAlthough each Parliament and court system has its unique characteristics, all parliamentary democracies have a number of characteristics in common: Actors, Structures, Procedures, Acts and Information Processes are in many ways comparable. AKOMA NTOSO defines common building blocks for these concepts in a single model that can be applied to all (or, at least, most) parliamentary, legislative and judiciary documents.SimplicitySimple data model -- identify a number of basic, fundamental classes of structures. The AKOMA NTOSO document model is designed, first and foremost, to be actually used. As a consequence, a high premium has been placed on simplicity throughout its design. Data models created to handle complex document types (such as legislation or sentences) need to deal with two apparently opposed requirements: on the one hand, they need to be sufficiently sophisticated to handle all possible semantic and structural occurrences and situations that may occur in the actual documents. On the other, they need to be speedily understood and used by the people who would need to apply these models. These opposed requirements can be jointly satisfied not by simplifying the vocabularies of available structures and elements, which would reduce the available descriptive sophistication of the language, but rather by simplifying the structure variability and types (in XML parlance, the content models), thereby reducing the learning time and the software complexity without compromising a full and detailed descriptive power of the language. The idea therefore is to identify a number of basic, fundamental classes of structures (containers, hierarchies, blocks, etc.) that can be immediately understood and used appropriately, regardless of their actual names.UsageThe AKOMA NTOSO document model is designed, first and foremost, to be actually usedEvolutionAbility to evolve -- built to stand evolutions and changes over time. A critical attribute of a successful XML model is its ability to evolve over time. This “evolvability” has been a key concern in the creation of the AKOMA NTOSO model. Thus, although the language is built to stand evolutions and changes over time, the language can be customized at will for local needs and purposes , and still be made compatible with the overall AKOMA NTOSO infrastructure and the general language. Furthermore, the language is built to stand evolutions and changes even regarding the number of actual functionalities provided: features such as the number and type of metadata values, or the automatic generation of amended text, or the activation of special analysis tools on the text may require the language to evolve in time. In these cases, it can be guaranteed that existing documents already marked up according to initial versions of AKOMA NTOSO will be either immediately compatible with the new schemas, or easily convertible to it via a single XSLT stylesheet to be provided.CorrectnessCorrectness assurance -- verifying the correctness of an XML document against specific schema.Verification“Validation” is the word used in XML parliance to refer to the act of checking the correctness of an XML document according to some pre-defined structural rules expressed in the formal definition of the language as expressed in one or more DTDs and XML Schemas. The validation step verifies whether the XML document contains, in number and position, all the expected elements of the type this document is an instance of. The AKOMA NTOSO XML language is formally defined using an XML Schema, and the corresponding validation schemaAKOMA NTOSO imposes a number of constraints and restrictions on the final form of the XML document, requiring for instance a specific order in the containment of parts or that any part is preceded by a heading, etc. The problem with being very restrictive in the constraints specified in the validation schema is that, documents may be drafted (e.g. approved by a Parliament) that do not conform to these rules: many countries have guidelines for the correct drafting of legislation or judgements, but have no prescriptive value: they are just what they are called, guidelines, that can be ignored and customized at will by a higher authority such as a Parliament or Court. This fact has a very important effect on the generation of electronic versions of such documents: everything that gets approved by Parliaments or written by Courts has to be accepted by the system, and everything that has already been approved even more so. Therefore, failing XML validation (i.e., violating one or more of the constraints and restrictions expressed in the schemas) cannot have the effect of rejecting documents, but, at most, of pointing out issues and differences from the guidelines that the authority itself, if it wants and has time to spend on this, can consider for editing and modifications. If we consider the validation schema a contract on the form a document has to assume, then this contract clearly binds only the author of the XML markup, leaving the author of the textual content (i.e., the legislator or the judge) absolutely free to organise the text as he/she chooses. Thus compliance to rules such as “A numerical identifier will always be associated to each substructure of the act” or “The enactment date will be specified” can be safely required, as they only bind the XML markup of the document, while structural rules (such as “Every subpart will have a heading”, or “A section will contain paragraphs which contain clauses”) can only be suggested, and not imposed, as they would interfere with the authority and independence of the legislator, which in the case of Parliaments is most often total and not constrainable by the mundane requirement of adherence to an abstract document structure. The goals of forcing authors of XML markup to fully describe all the parts of the document, and of leaving the legislator with the maximum freedom in writing, may seem incompatible and hard-to-reach, but they can be and are reached within the AKOMA NTOSO framework. AKOMA NTOSO clearly separates data and metadata, thereby clearly distinguishing the contribution of the legislator (data) and the contribution of the author of the XML markup (metadata); AKOMA NTOSO provides a richly evocative vocabulary of structures and elements, so that the markup author can correctly and precisely describe what is actually contained in the documents. AKOMA NTOSO imposes little or no constraints on data, letting the legislator write and organize the text matter as wished, but imposes a number of constraints on the metadata, forcing the markup author to provide all bits of information that are necessary to manage and organize the document. Yet it might be appropriate for the tool to guide through the drafting guidelines enacted in each country, and help in following them as precisely as possible. One way out, as adopted by AKOMA NTOSO, is to provide a number of concentrical schemas, the outer of which, called the General Schema, is fully descriptive, not binding the legislator but only the author of the markup, allowing him to describe as precisely as possible the actual structure of the document as approved and emanated by the Parliament. Within the rules dictated by the General Schema one can add as many custom schemas that can be made more prescriptive, and can be used to check whether the document actually conforms to the existing legal drafting guidelines in each individual country. Successful validation of documents is required against the general schema, since these errors would signal incorrect markup (which is not acceptable in AKOMA NTOSO), while the detailed schema can be used, at the discretion of the Parliament itself, to automatically check conformance of the proposed bill against the drafting guidelines, and thus warn the legislator to modify it accordingly in case conformance is sought. Both descriptive and prescriptive schemas, of course, are closely related: they both use the same vocabularies, and have the same set of basic, fundamental rules. They then differ in the number of additional rules and constraints they impose. All rules enforced in the general schema also exist in all custom schemas, so that all documents that are valid according to each of the custom schemas are also valid according the general schema. Furthermore, this double layer of schemas also allows interoperability of documents coming from different countries. In fact the descriptive general schema can accept all AKOMA NTOSO documents from any interested country, and can be used as the baseline for accessing and displaying documents regardless of their provenance. On the other hand each prescriptive detailed schema is created to deal with the specific guidelines of each individual country, helping towards the more precise legal drafting process and the correct preservation of cultural peculiarities of each individual country. The fundamental commonality of these schemas provides therefore full description of individual and country-specific document types without renouncing to interoperability and document interchange.Document FormatDefine a common document format_ca0f2f94-5502-11e1-bc05-f8717a64ea2a1Parliaments and Courts function through the medium of documents. Debate in Parliamentary chambers and courts proceedings are recorded as documents. Legislation is passed through the voting process via a combination of documents, the proposed legislation itself, proposed amendments, committee working papers and so on. Given that most of the processes are document-centric, the key enabler of streamlined Information Technology in Parliaments and Courts is the use of open document formats for the principal types of documents. Such open document formats will allow easy exchange and aggregation of information – in addition to reducing the time required to make the information accessible via different electronic publishing media. The Information Technology industry has coalesced around a standard technology for Open Document Formats known as XML (eXtensible Markup Language). AKOMA NTOSO makes use of XML industry standard XML (eXtensible Markup Language) to define the structure and syntax of its open document standards. It includes a set of XML-based parliamentary, legislative and judiciary Open Document Formats to cover: * Parliamentary Debates * Committee briefs * Journals * Primary Legislation - covering the life-cycle of a piece of legislation * Judgements * Others to be addedParliamentary Debates_ca0f3156-5502-11e1-bc05-f8717a64ea2a1.1Committee Briefs_ca0f3336-5502-11e1-bc05-f8717a64ea2a1.2Journals_ca0f3584-5502-11e1-bc05-f8717a64ea2a1.3Primary Legislation_ca0f3764-5502-11e1-bc05-f8717a64ea2a1.4covering the life-cycle of a piece of legislationJudgements_ca0f394e-5502-11e1-bc05-f8717a64ea2a1.5Others_ca0f3b38-5502-11e1-bc05-f8717a64ea2a1.6Others to be addedInterchange ModelDefine a common model for document interchange_ca0f3d2c-5502-11e1-bc05-f8717a64ea2a2Regardless of the processes that generate and use parliamentary, legislative and judiciary documents, regardless of the cultural and historical factors that give shape and substance to these documents, and regardless of the human languages in which these documents are written, there are undeniable similarities that are shared by documents of the same type, of different types, for different purposes, of different countries. One of the main objectives of AKOMA NTOSO is to be able to capture and describe these similarities so as to unify and streamline, wherever possible and as far as possible, the formats and software tools related to parliamentary, legislative and judiciary documentation, and describe processes in a similar way. This lends itself to reducing the need for local investments in tools and systems, to helping open access, and to enhancing cooperation and integration of governmental bodies both within the individual countries and between them. AKOMA NTOSO defines a model for open access focused on the following issues: *Generation of Documents * Presentation of Documents * Accessibility of Documents * Description of Documents. At the same time, the AKOMA NTOSO model considers the differences that exist in individual document types, that are derived from using different human languages, and that are implicit in the legislative culture of each country. Therefore the common open access model is designed to be flexible, to support exceptions, and to allow extensions far enough to provide support for all individual characteristics that can be found in a complete document set covering different cultures and countries.Generation of DocumentsIt should be possible to use the same tools for creating the documents, regardless of their type, country, language, and generation process._ca0f3f2a-5502-11e1-bc05-f8717a64ea2a2.1Presentation of DocumentsIt should be possible to use the same tools to show on screen and print on paper all documents, regardless of their type, country, language and generation process._ca0f4326-5502-11e1-bc05-f8717a64ea2a2.2Accessibility of DocumentsIt should be possible to reference and access documents across types, languages, countries, etc., converting the network of explicit references among texts into a web of hypertext links that allow the reader to navigate easily and immediately across them._ca0f4588-5502-11e1-bc05-f8717a64ea2a2.3Description of DocumentsIt should be possible to describe all documents, regardless of their types, languages, countries, etc., so as to make it possible to create repositories, search engines, analysis tools, comparison tools, etc._ca0f47a4-5502-11e1-bc05-f8717a64ea2a2.4Data SchemaDefine a common African parliamentary, legislative and judiciary DATA schema_ca0f49ca-5502-11e1-bc05-f8717a64ea2a3ParliamentsCourtsParliaments and Courts work with a number of distinct types of documents such as legislation, debate records, parliamentary questions, judiciary proceedings, judgements etc. AKOMA NTOSO explicitly supports each major type of document with specific provisions for individual characteristics. The definition takes the form of human and machine-readable document models, according to the specification tools made available by XML schema, the specification language used by XML. All document types share the same basic structures, provide support for metadata, addressing and references, differentiate common structure and may accommodate national peculiarities. All documents can be produced by the same set of tools (although specialized tools may provide more detailed and specific help in specific situations), need the same tools to be displayed or printed (although specialized tools can provide more sophisticated and individual presentations), can reference each other in an unambiguous and machine-processable way, and can be described by a common set of metadata that helps in indexing, analysing and storing all documents._ca0f4bf0-5502-11e1-bc05-f8717a64ea2aMetadata Schema and OntologyDefine a common African parliamentary, legislative and judiciary METADATA schema and ontology_ca0f4e2a-5502-11e1-bc05-f8717a64ea2a4African ParliamentsAfrican LegislaturesAfrican CourtsMetadata are structured information about a resource. Metadata record information about a document that is not actually part of its content, but is necessary to examine in order to deal with the document itself (for instance, information about its publication, lifecycle, etc.). Metadata also enable a document to be found by indicating what the document is about and how it can be accessed. Furthermore, metadata facilitates the discovery and use of online resources by providing information that aids and increases the ease with which information can be located by search engines that index metadata. Metadata values are labelled and collected according to a common ontology, i.e. an organized description of the metadata categories that describe the resources. A shared ontology is fundamental to provide a way for managing, organizing and comparing metadata. The parliamentary, legislative and judiciary ontology is concerned particularly with records management and document management, and covers the core set of data elements needed for the effective management and retrieval of official parliamentary, legislative and judiciary information. The aim of the parliamentary, legislative and judiciary ontology is to provide a universal schema for all the information about a document that is available to its owner, does not belong to the document itself, and might be needed for management or searching. The AKOMA NTOSO ontology provides direct translation of some of its values into the corresponding properties of the Dublin Core metadata schema (an international standard for the description of electronic documents available online), and uses values and terms drawn from the legal thesauri to improve searchability by legal professionals. Nonetheless, AKOMA NTOSO, the ontology is designed to be extensible so that Parliaments and Courts with different, or more specific, metadata needs may add extra elements and qualifiers to meet their own requirements._ca0f5078-5502-11e1-bc05-f8717a64ea2aCitation and ReferencingDefine a common schema for citation and cross referencing_ca0f52e4-5502-11e1-bc05-f8717a64ea2a5MECHANISM for citation and cross referencing of documents -- Define a mechanism MECHANISM for citation and cross referencing of data between documents: The AKOMA NTOSO Naming Convention and the corresponding AKOMA NTOSO reference mechanism are intended to enable a persistent, location-independent, mechanism for resource identification and active referencing. The adoption of a scheme based on the Naming Convention allows the full automation of access to documents in a fully distributed hypertext. The naming convention can cater for: * the direct access to the document being referred to, regardless of type, jurisdiction, country, or emanating body. * the specification of the existence, at a certain time, of more than one copy of the same document being referred to; * the possibility that references to resources not yet published on the web are present. Official documents, bills, laws, acts and judgements contain numerous references to other official documents, judgements, bills, laws and acts. The whole parliamentary, legislative and judiciary corpus of documents can be seen as a network, in which each document is a node linking, and linked by, several other nodes through natural language expressions. The adoption of a common naming convention and a reference mechanism to connect a distributed document corpus, like the one embodied by the Parliaments and Courts, will greatly enhance the accessibility and richness of cross references. It will enable comprehensive cross referencing and hyper-linking, so vital to any parliamentary, legislative and judiciary corpus, from: * debate record into legislation * section of legislation to section of legislation in the same act * section of legislation to section of legislation in another act of the same Parliament or of an institution like the Pan African Parliament or European Parliament; * from judgements to other judgements and acts._ca0f5550-5502-11e1-bc05-f8717a64ea2aTools[Provide] a brief list of the foreseeable tools and the main categories._ca0f57c6-5502-11e1-bc05-f8717a64ea2a6Editor, converter, name resolver, post-editing tools. Just as many are the users (some of whom are not even aware of the fact they are using or relying on AKOMA NTOSO-compatible systems), many also are the tools that need to be created around the AKOMA NTOSO document model. Some of them are basic tools that are necessary for the AKOMA NTOSO system to work at all. Others are additional applications that are to be used once for a sufficiently large document base has been generated using the AKOMA NTOSO language. Although this is not the place to provide a full list of the foreseeable tools, a brief list of the main categories may help in explaining the breadth and variety of the AKOMA NTOSO project, and the number of issues that need to be considered in the development of the data format. It is also to be remembered that AKOMA NTOSO is fundamentally an open standard for data formats: tools can be produced by any individual and organization, and those proposed within the AKOMA NTOSO project are only to be considered as proposals and baseline tools: as long as a new tool conforms to the requirements of the Akoma Ntoso data formats, it is to be considered as good as the AKOMA NTOSO tools for all purposes.Editors_ca0f5a64-5502-11e1-bc05-f8717a64ea2a6.1The editor -- The editor is one of the two fundamental tools for the generation of XML versions of legislation or judgement, etc. Although drafting can be done without a specialized editor in most real life scenarios, there will be situations in which using a specific editor is appropriate and possibly even necessary. The editor is used in three different scenarios: 1. as an application for the direct insertion of both text and markup, starting off an empty document: although this is the easiest case to understand, itis probably the rarest concrete scenario of use, as the drafting offices will most usually work off existing documents in some other format. 2. as an application to manually mark-up a document whose textual content was provided in a different format. Depending on the sophistication of the conversion engine, this scenario will most probably blend naturally with the following one, with automatic tools suggesting markup that is then verified and approved by the human user. The editor basically provides functionalities to edit and add any kind of AKOMA NTOSO-conformant markup, and is able to check the validity of any intermediate result. 3. as an interface to activate, control and verify the automatic conversion obtained by the tool described in the next section. Through the editor the user can verify the correctness of the conversion, and change and add whatever markup or content the conversion engine has forgot or misidentified using the standard editing interface.Converters_ca0f5d66-5502-11e1-bc05-f8717a64ea2a6.2The converter -- The converter is, with the editor, the most fundamental tool for the AKOMA NTOSO system. The need for a converter is based on the assumption that in many cases the drafting process is already in place with a number of generic and specialized tools, and the offices and the drafter may start conformance by adopting a tool for the final task of generating the XML version of the document, and not replace their existing workflow with new tools and new tasks. Such final tool is the converter. The converter has the double purpose of 1. converting into AKOMA NTOSO XML documents the files that the “drafter” is producing traditionally, and, 2. converting into AKOMA NTOSO files the legacy documents, such as the existing acts and judgements that form the current situation of each country, and whose conversion into XML is needed for any hypertext web of references to work at all. Since legacy documents are, by definition, in any old format, and since it makes no sense to type them in XML using an XML editor, the task of conversion happens through a semi-automatic operation using the converter. The conversion is based on the idea of semi-automatic operation, i.e., it i based on an automatic process that determines as correctly as possible the actual structures, and a subsequent manual process that confirm (or, if there is an error, modifies) the inferences made by the automatic process. In fact, this application is often meant to be one of the modules of the editor, and uses the editor itself for corrections to the automatic inferences of the converter. Of course, the amount of human editing is inversely proportional to the regularity of the documents and the sophistication of the converter, so that large quantities of regular documents can usually be processed automatically with little or no manual intervention. The converter works by examining the typographical and textual regularities of the document, and by inferring from them a structural or semantic role for each text fragment. When no deducible structural or semantic role can be inferred automatically, the presentational characteristics will be recorded instead and if the human user will be asked to provide the structural or semantic role that the tool failed to identify. Experiences with European laws show that the basic structure of the bill (sections, subsections, clauses, preambles, conclusions, attachments, etc.) can be inferred automatically with great precision and few errors. The most important semantic elements, references and dates, can also be deduced automatically with great precision as long as the human-readable text used for them uses one of a limited number of acceptable forms. More complex structural elements (explicit modifications, specialized terms, people, etc.) might be difficult to catch in a fully automatic way, but this is not impossible.Traditionally Produced DocumentsConvert into AKOMA NTOSO XML documents the files that the “drafter” is producing traditionally._ca0f6018-5502-11e1-bc05-f8717a64ea2a6.2.1Legacy DocumentsConvert into AKOMA NTOSO files the legacy documents._ca0f6310-5502-11e1-bc05-f8717a64ea2a6.2.2Name ResolversSpecify an architecture-independent network address for all relevant structures of the AKOMA NTOSO standard._ca0f65ea-5502-11e1-bc05-f8717a64ea2a6.3The AKOMA NTOSO Naming Convention is a standard mechanism for creating identifiers of documents that can be used for accessing content and metadata regardless of storage options and architecture. AKOMA NTOSO documents are stored on networked computers and are accessible by specifying their network addresses. Yet these addresses are extremely dependent on the specificities of the architecture that were adopted by the custodian of those documents, and are dependent on the technologies and tools that are in vogue or appropriate for the economic and technical context of the custodians. It is extremely inappropriate, therefore, that any content or structure that is planned to last for more than a short period of time is named according to the physical address of the document in the form that is currently used to access it. For this reason, the AKOMA NTOSO Naming Convention specifies an architecture-independent network address (using a permanent family of Web-derived URI addresses) for all relevant structures of the AKOMA NTOSO standard, which on the other hand is not meant to be used directly for accessing these structures. A name resolver is a software tool that can, given an architecture-independent URI, identify the resource being sought and provide the current architecture-dependent address that needs to be used at any given time in order to perform the actual access. Name resolvers are either indirect, in that they return the client application the current address of the requested document, and leave the client application the task of re-requesting the document at the correct address or direct, in that they immediately return the requested document by generating the actual physical address and requesting the document as a proxy for the initial client application.Post-Editing Tools_ca0f68d8-5502-11e1-bc05-f8717a64ea2a6.4The post-editing tools are a number of validation, enrichment, and storage tools that are used after the “legal drafter” has finished his/her editing job. All these tools require no user-interface to speak of, are managed either automatically or by the system administrator of the storage centre for all AKOMA NTOSO documents. These tools include at least (but the list might be longer and more sophisticated):Content and Structure ValidatorA content and structure validator that checks the correctness of the document instance with regard to the AKOMA NTOSO schema document, and to any additional rules that were added locally._ca0f6be4-5502-11e1-bc05-f8717a64ea2a6.4.1Reference ValidatorA reference validator that checks whether all references contained in the document already belong to the document collection and are correctly referenced._ca0f6ef0-5502-11e1-bc05-f8717a64ea2a6.4.2Metadata ValidatorA metadata validator that checks whether the metadata stored with the document are correct and complete._ca0f7210-5502-11e1-bc05-f8717a64ea2a6.4.3Document Management SystemA sophisticated and complex document management system, with search engines, hypertext functionalities, XSLT support and versioning facilities._ca0f753a-5502-11e1-bc05-f8717a64ea2a6.4.4XSLT StylesheetsAn XSLT stylesheet (or a series thereof) to create visualizations of individual documents for a number of browsers and applications that will increase and get more sophisticated in time._ca0f7864-5502-11e1-bc05-f8717a64ea2a6.4.52012-02-11http://www.akomantoso.org/akoma-ntoso-in-detail/referencemanual-all-pagesOwenAmburOwen.Ambur@verizon.net