AKOMA NTOSO 1.0 Schema

Release 09 December 2009
Technical Supervision: Fabio Vitali - University of Bologna
Legal Domain Supervision: Monica Palmirani - University of Bologna

This document introduces and explains the schema for AKOMA NTOSO 1.0, an XML-based document format for legislative documents in African countries. More details about the background and rationale of this project and of the design methodology can be found in the AKOMA NTOSO web site, www.akomantoso.org.

In this document we provide technical details and assumptions about the AKOMA NTOSO 1.0 document structure and elements, as well as some hints for document markup using this schema. The final document describes two different but connected families of schema. The first is the AKOMA NTOSO general schema, a vocabulary and a minimal set of constraints that all AKOMA NTOSO documents must comply to. A set of stricter schemas, the AKOMA NTOSO custom schemas, provide more constraints over the same vocabulary of elements to enforce the rules of specific document types in specific African countries. It is a requirement of AKOMA NTOSO that all documents satisfying one of the custom schemas also satisfy the general schema. 

In this release only the general schema is described in full. Thus, except when explicitly mentioned, all rules are expected to refer to the general schema (and thus to all AKOMA NTOSO documents). 

Patterns are the abstraction and distillation of past experiences in designing and resolving design problems. They are general and widely applicable guidelines for approaching and justifying design issues that often occur in XML-based projects.

In AKOMA NTOSO patterns are used to create categories of content models (and thus correspond to only those content models that have been found to be actually useful) and more generally in schema design (and thus correspond to guidelines on how to make the schema more modular, flexible and understandable by users). Both approaches are well known and well established in the literature, although by different experts in different ways. 

4.2 Patterns in schema design

Design patterns are distillation of common wisdom in organizing the parts and the constraints of a schema. Some of them are listed in http://www.xmlpatterns.com/. Whenever there has been a design choice to be made that was not immediately obvious and naturally acceptable, a relevant pattern has been sought and properly used. In fact, http://www.xmlpatterns.com/ also contain immediately obvious and naturally acceptable pattern that have been used in AKOMA NTOSO, but only the not-so-obvious and not-so-natural ones have been explicitly mentioned and referred to. You can find the relevant mentions in comments within the schema itself, and in the documentation. 

The meta section contains all the meta-information that needs or can be added to the actual content of the document. As a rule, all editorial content (i.e. content added by the editorial process out of drafting rooms) need to be placed in the meta section, except for markup and note references. Vice versa, all actual content of the document need to have a place outside of the meta section and within the appropriate content sections.

Elements within the <meta> section are divided in several subsections, such as <identification> (to provide for names and identifiers to clearly specify and identify the various aspects of the document as characterized by the FRBR model), <publication> (details about the publication of the paper-based document), <lifecycle> (information about the events the document has undergone) or <references> (a list of entities, individuals, concepts and other documents this document is related to for any reason, such as the topics the document is about, the people mentioned, or the documents it amends or it is amended by). An additional section, <proprietary>, allows additional metadata elements to be added by local implementations without the need for all other implementations to know about them and know how to react to them.

AKOMA NTOSO 1.0 include a sophisticated mechanism to keep track of the life cycle and evolution of a legal document. This is particularly useful for acts that are amended and modified in time, while maintaining their fundamental nature.

The management of evolution of a document makes two important assumptions:

• Amendments and events in the life cycle of a document (including original approval, final repeal and any other event affecting its presence in the law system or its content) happen in precise moments in time that can be determined objectively (albeit possibly with difficulty) and attributed a specific date.

• Amendments and events in the life cycle are due to the enactment of a specific, individual document that can be objectively traced back and identified with an URI. If two different documents affect the same act on the same date, then these must be counted as two different and separate events on the amended act.

Handling events in AKOMA NTOSO centers around the <lifecycle> element in the meta section. This contains two containers, <events> and <references>, used to list the dates of all the events affecting a document, and the references to the URIs of all the documents generating these events. Each reference is provided with a required identifier, which is used by the event list to specify which document is responsible for which events. These elements must appear in all documents that have undergone two or more events (e.g., all acts except the ones that still have no amendments). 

Documents in AKOMA NTOSO are organized in three main categories, as specified in the contain attribute of the document type element:

• originalVersion: this value reflects the fact that the content on the document is exactly the content that has been formally and explicitly approved by the relevant authority, with no amendments applied.

• singleVersion: this value reflects the fact that the content of the document is an editorially modified version of the original document, according to one or more subsequent amendment documents. These amendment documents and the enactment dates of the amendments must be all mentioned in the <lifecycle> element. Individual additions and deletions are not marked in the content. 

• multipleVersions: this value reflects the fact that the content of the document is the juxtaposition of fragments belonging to two or more different versions of the same document, each fragment marked as belonging to one or many of these versions. Thus in a multipleVersions act there could be two or more copies of section 2, each associated to the date it started enactment and ended enactment.

The <lifecycle> element is a required element for all singleVersion and multipleVersion documents, and must be complete up to the enactment date of the latest document referenced in the <lifecycle> element (i.e., there can potentially exist subsequent amendments not included, but all amendments preceding the document’s date must be correctly listed and referenced, even if they play no part in the displayed content). originalVersion documents need not have the <lifecycle> element, but surely can have it if the editors decide so. 

In case a multipleVersions document is being generated, each element and text fragment may be associated with an enactment specification through the means of the five attributes: start, end (for validity), startEfficacy, endEfficacy (for efficacy) and status. Each fragment (a whole element if appropriate, otherwise a newly inserted <span> or <inline> element for text fragments for which no exact containing element exists) must use these attribute to specify its nature. 

The start and end attributes (and similarly the startEfficacy and endEfficacy attributes) contain a reference to the ID of the event that has marked the beginning or the end of the enactment (or of the efficacy) of the fragment. A start attribute with no end attribute marks a fragment that has appeared in an amendment and still exists in the latest recorded version of the document. An end attribute with no start attribute mark a fragment that was part of the original document but has been repealed before or at the latest recorded version of the document. The status attribute records the type of amendment of the fragment. The value “omissis” can only be used by non-authoritative publications that need to display only part of the whole document: when status=”omissis”, the structure must be complete as if all contents was present, but unrequired parts of the actual content can be removed. Similarly, the value “editorial” can be used to add fragments of text of editorial nature (i.e., that are generated by editors rather than authors). Examples include annotations and translated sentences. For instance:

<p xml:lang=”afr” id=”blk123”>Partye wat deel wil vorm van die proses van regering, is vol verligting. ``Sien,'' sˆ die Nuwe NP, ``die ANC is nie magshonger nie!'' Ryke ironie, komende van waar die Nuwe NP sit. <span xml:lang=”eng” status=”editorial”>(Translation of Afrikaans paragraph follows.)</span></p>

<p xml:lang=”eng” status=”editorial” refersTo=”blk123”>[Parties who want to form part of government are quite relieved. ``You see'', says the New NP, ``the ANC is not power-hungry!'' Such irony, if one considers where the New NP is sitting.]</p>

Documents make references to external entities that need to be identified with clarity and no ambiguity. The current release of Akoma Ntoso includes a section where references to external concepts, people and places are specified. These include references to other Akoma Ntoso documents, to other  non-Akoma Ntoso documents that are accessible through the net, or to individual instances of classes specified in a local ontology.

7.1 The structure of references

All references to external concepts share the same structure, in that they are empty elements in the references section provided with exactly four attributes:

• href: the URI describing the entity being referred to. This can be a whole document (for instance, the act containing amendments to the current document), or a fragment of a document (for instance, the identifier of the unique record identifying precisely the person being referred to in the document).

• id: this is the string that identifies within the document the entity being described. All internal references will thus use this id. For instance, every event in the document lifecycle has a source attribute containing a reference to the id of the document affecting or being affected by the document. 

• showAs: this is the string that can and must be used in displaying information about this entity. For instance, this attribute contains the name of the speaker as it must be displayed.

• shortForm: this optional attribute contains a secondary form of the display information of the entity. For instance, in some reports it is necessary to provide the full name of a person at the first utterance, and only the name in any further utterance from the same person.

7.2 Referring to precise concepts in the document

AKOMA NTOSO provides a series of mechanisms for referring to precise concepts in the documents being marked up. Regardless of whether the textual content of the document is sufficiently explicit and unambiguous, the marker of the document may and should provide additional disambiguating information about individual pieces of fragment denoting precise concepts through the aid of the appropriate attributes.

This disambiguation happens systematically as a two-step process: first of all, a mention to the ontological concept is added to the references section and provided with an id, and then one or more attributes in the document elements are used to refer to it.

For instance, every individual in a debate is associated via the id to an element TLCPerson in the references section: the by attribute of the speech element indicates the speaker (this must be a TLCperson), the as attribute specifies the role of the speaker (which must ne a, if any (and it must be a TLCrole) and the to attribute indicates the addressee (this can either be a person or a role).

The following are the attributes used for this purpose:

• refersTo: points to any instance of a Top Level Class of the ontology. It is used to notify the reader in a generic way to what specific concept is the element referring to.
• href: contains the URI of a instance of an FRBR document class or of a web page. Furthermore, it signals the application that the reference must be considered navigable, i.e., activatable by the user (e.g. via a link).
• upTo: for range references (e.g., rref and rmod) this specifies the URI of the last, or highest, element of the range being referred to.
• by: points to a person, i.e., an instance of the class TLCPerson in the references section, relative to the person by which the content has been provided.
• as: points to a role, i.e., an instance of the class TLCRole in the references, relative to the role held by the person when uttering the content.
• to: points either to a role, a person or an organization, relative to the kind of addressee of the content being provided.

Thus, any fragment in the text content of the document referring to Events, Concepts, or other instances of the Top Level Classes need to use the refersTo attribute to point to the id of the corresponding element in the references section.

A few elements can be considered of some use:

• The element entity provides a standard mechanism to refer to mentions of instances of Top Level Classes in the content of the document. Any instance of any class can be referred to via an instance element.
• ref, mref, and rref provide a mechanism to refer to other documents in the Akoma Ntoso domain. These elements may use the refersTo attribute, but will most frequently directly use the href attribute to specify a navigable reference to the document they refer to. The element ref specifies a single reference, the element mref a group of references (a list of individual ref elements must be placed inside the mref element, one for each reference) and the rref element specifies a range of references delimited by the href and upTo attributes.
• mod, mmod and rmod provide a mechanism to specify modifications to other documents. The mod element contains at least one ref element identifying the destination of the modification, and may contain as many quotedStructure and quotedText elements as needed providing the textual modification (if any) in terms of either whole structures or individual words. The element mod specifies a single modification, the element mmod a group of modifications (a list of individual mod elements must be placed inside the mmod element, one for each modification) and the rmod element specifies a range of modifications delimited by the href and upTo attributes.
• The a element provides a mechanism to refer to web pages, e.g., the official home page of an organization. It should never be used for references to AKOMA NTOSO documents (that are only referred to via *ref elements).

The following inline elements may appear to be references, but are rather definitions:

• date:  specifies that the content of the element is a date. Through the date attribute it is possible to provide the unambiguous form of the date in XSD 1.0 syntax (yyyy-mm-dd).
• docDate, docType, docNumber, docProponent, docPurpose: specify that the content of the element provide information about a date, a type, a number, a proponent and a purpose of the document, respectively. The attribute refersTo may point to appropriate instances of the Top Level Classes accordingly. Attributes refersTo are required if there are more than ONE such element per type (e.g., a document may have TWO different docNumber or docDate elements, but they must be disambiguated via refersTo elements pointing to different instances of the TLCConcept class).
• judge, party, lawyer specify the judge, party and lawyer associated to a judgement. These elements need to be used when the document introduces these individuals or organizations in a formal way. Any further reference to them should be done via the entity element. 

The AKOMA NTOSO standard defines a number of referenceable concepts that are used in many situations in the lifecycle of legal documents. The purpose of this section is to provide a standard referencing mechanism to these concepts through the use of URIs associated to classes and instances of an ad hoc ontology. The referencing mechanism discussed in this document is meant to be generic and evolving with the evolution of the underlying ontology.

The most important concepts of the Akoma Ntoso ontology are related to documents that have legal status. All discourse and all description of legal sources can be characterized as referring to one of the four levels of a document as introduced by IFLA FRBR (International Federation of Library Associations (IFLA) - Functional Requirements for Bibliographic Records (FRBR) http://www.ifla.org/VII/s13/frbr/frbr.pdf):

• WORK: the abstract concept of the legal resource (e.g., act 3 of 2005).
• EXPRESSION: any version of the WORK whose content is specified and different from others for any reason: language, versions, etc. (e.g., act 3 of 2005 as in the version following the amendments entered into force on July 3rd, 2006).
• MANIFESTATION: any electronic or physical format of the EXPRESSION: MS Word, Open Office, XML, TIFF, PDF, etc (e.g., PDF representation of act 3 of 2005 as in the version following the amendments entered into force on July 3rd, 2006).
• ITEM: the physical copy of any manifestation in the form of a file stored somewhere in some computer on the net or disconnected (e.g., the file called act32005.pdf on my computer containing a PDF representation of act 3, 2005). 

All documents at all levels can be composed of sub-elements, that when combined form the whole document. These are called components, are abstractly represent the notion that several independent subdocuments form the whole document as it appears to the reader (i.e., a main body possibly followed by a number of attachments such as schedules and tables):

• WorkComponents (e.g., main, schedule, table, etc) - the WorkComponents are abstract entities that can be referenced to refer to different ExpressionComponents in time.
  
• ExpressionComponent (e.g., main, schedule, table, etc.) - the ExpressionComponents represent the visible division of the document as generated by the content author (Parliament, etc.)
• ManifestationComponent (e.g., xml files, PDF files, TIFF images, etc.) - the ManifestationComponents represent the division of the document as generated by the manifestation author (e.g., the XML editor).
• ItemComponent - the actual files corresponding to the ManifestationComponents

Other concepts dealt by the Akoma Ntoso ontology also derive from the IFLA FRBR ontology, and include but are not limited to individuals (Person), organizations (Corporate Body), actions and occurrences (Event), locations (Place), ideas (Concept) and physical objects (Object). The full list of such concepts is provided in section 8.8.

Scope of the naming convention is to identify in a unique way all Akoma Ntoso concepts and resources on the net and in general all collections thereof. Some principles and characteristics should be respected in the naming convention:

• MEANINGFULNESS: the name is a meaningful and logical description of the resource and not of its physical path
• PERMANENCE: the name must be permanent and stable over time
• INVARIANCE: the name must derive from invariant properties of the resource so as to provide some degree of certainty in obtaining the same name for the same resource regardless of process, tool and person.

FRBR concepts are used differently when taking about documents in a variety of situations. In each cases it is important to use the URI for the correct FRBR level of document. We describe here a few particularly frequent situations:

1. Legislative references will most probably refer to WORKs: acts referring to other acts do so regardless of the actual version, and references must be to something independent of all possible expressions, e.g., to the work. 
2. The list of attachments and schedules belong to a specific EXPRESSION, so references to ExpressionComponents is specific of the expression level.
3. Yet the specific Manifestation that is the Akoma Ntoso XML format uses an XML-based syntax to refer to ExpressionComponents, and associate them to the corresponding ManifestationComponents containing the appropriate content. Therefore within XML files the URI of the ManifestationComponents must be used to refer to all components, including the main document, all attachments and all schedules.
4. Multimedia fragments within an XML manifestation (e.g., a drawing, a schema, a map, etc.) do not exist as independent ExpressionComponents, as they are only a part of some ExpressionComponent (even when they are the only part). In fact they are only ManifestationComponents, and as such are referred to in object and img elements with the appropriate ManifestationComponent URI. Even if the same multimedia content appears in different parts of the content of a Manifestation, each instance of that content must correspond to a different ManifestationComponent, and must be considered independently of the other. 
5. It is a Item-level decision, once ascertained that the content is exactly identical, to provide space-saving policies by storing only one copy of the multimedia content. This Item-level decisione has no impact on references and names, which are still individually different from each other.
6. Non-document concepts are referred to within the metadata and content of Akoma Ntoso documents. References are always performed in two steps: the first step ties the reference point in the document to an item in the Reference section using internal (and not standardized) IDs; the second step ties the item in the reference section to the actual concept through the URI of the concept as specified in this document.

Since the most important concepts in Akoma Ntoso are connected to documents, the main part of this section is devoted to detailing the URIs of document-related concepts, and in particular Works, Expressions, and Manifestations. Items are by definition outside of the scope of this standard, and are only briefly described. The final part of the section provides a URI-based naming mechanism for non-document entities (as well as for document entities when they are handled in a similar way to non-document entities).

Differences between release 9/12/2009 and 21/10/2009

This release contains just two minor bug fixes:

• The complex Type AnyOtherType (allowing elements of any namespace except Akoma Ntoso) now allows any number (including zero) of elements instead of exactly one. This affects a number of metadata elements.
• Attribute refersTo now expects an URI instead of an IDREF value. This means that references to locations inside the document (e.g., in the references section) now need to be prefixed with character “#” instead of being bare (e.g. refersTo=”foobar” needs to become refersTo=”#foobar”). This is in accordance to  a general avoidance of the IDREF introduced  on the 23/10/2006 release and for some reasons ignored for the refersTo attribute.

Differences between release 21/10/2009 and 11/5/2009

This release contains some differences to previous versions regarding mainly the handling of judgments. Most differences regard metadata to analyze judgments, and only a few of them affect the document content. 

• A new inline element, docketNumber, has been introduced to handle the specification of the docket number, case number, file number or in general any number that represents the overall procedure of which this is one document. The term docketNumber has been chosen because it is clear, unambiguous, not overly restrictive (as would have been caseNumber) and not misunderstandable for a computer-related term (as would have been fileNumber).

• Speech-related containers such as administrationOfOaths, declarationOfVote, etc. have been added to the list of containers that can be specified anywhere.

• Element lawyer has a few difference in its attributes: the attribute represents has become for, and a new attribute empoweredBy has been added for lawyers that receive the representation not directly from the client but indirectly through a delegation of power via another lawyer.

• Element opinion, wrapping the opinion of the judges in a judgment, has a new attribute type that specifies whether each individual judge consents or dissents from the judgment.

• The element workflow has been clarified. A workflow is not composed of action elements anymore, but of step elements. Each step element defines (references to instances of) a date, an actor (either a TLCPerson or a TLCOrganization), a role (a TLCRole), and an outcome (a TLCConcept).

• A new analysis container has been added for judicial analysis. The element, judicial, contains a number of judicial arguments, each of which connects a structure of the document to external sources or other structures of the document itself. The judicial element contains one result element that specifies the actual result of the judgment (one of deny, dismiss, uphold, revert, replaceOrder, remit, decide, and approve), and as many elements as needed of the judicial argument category, which are: supports,  isAnalogTo, applies, extends, restricts, derogates, contrasts, overrules, dissentsFrom, putsInQuestion, distinguishes. It should be noted that the term putsInQuestion is hardly satisfactory, and different from the proposed questions, which cannot be used in this context because  it is already used as a section of the Speech containers.

Differences between release 11/5/2009 and 16/3/2009

This release contains no difference from the previous release but a few bug fix. The main justification of this release is to introduce systematic inline documentation to all structures of the language (groups, attribute groups, simple type, complex types and elements.

Additionally, a few bug fixes have been introduced:

• The internal date of the schema has been updated to reflect correctly the revision date of the schema. In previous release, in fact, the release date within the schema had not been updated, resulting in two very different schemas asserting to have been last updated on the same date.
• Group ANotherInline has been actually added to the inlineCM group , allowing elements entity and date to be actually used in document markup.
• Complex types anyOther and anyOtherType, which were identical, have been brought together into one type, anyOtherType. All elements and attributes have been updated accordingly.
• Several reshuffles of relative position of definitions have been made. No difference in content has been performed, though.

Differences between release 16/3/2009 and 5/11/2008

This is a major release, providing a number of relevant modifications to the previous releases. Many of these modifications are NOT backward-compatible. These will be explicitly noted as such in the following.

9.1.1 Sidenotes and out of line texts

A completely new take on side notes has been undertaken in this release. Rather than being header blocks at the beginning of hierarchical structures, side notes are now full members of a new category: authorial notes. An authorial note is by definition a note (i.e., an out-of-line text fragment) that was provided by the original author of the content (i.e., by the author of the specific FRBR expression). 

Thus the element sideNote has been removed, and substituted by a new container element, outOfLine, contained in a collection element outOfLines. Each outOfLine has a type attribute assuming either of the value sideNote or publicationNote, an href attribute pointing to a structure in the document to which the out of line text should be attached to, and contains blocks such as p elements.

Thus the fragment

<akomaNtoso xmlns="http://www.akomantoso.org/1.0">
    <act>
        ...
        <body>
            <section id="sect54.a">
                <num>54A</num>
                <heading>Conduct of prosecutions.</heading>
                <clause id="sect54.a-cla1">
                    <num>(1)</num>
                    <sideNote>Cap 75.</sideNote>
                    <content>
                        <p> Blah blah</p>
                    </content>
                </clause>
            </section>
        </body>
     </act>
</akomaNtoso>

needs to become:

<akomaNtoso xmlns="http://www.akomantoso.org/1.0">
    <act>
        ...
        <body>
            <section id="sect54.a">
                <num>54A</num>
                <heading>Conduct of prosecutions.</heading>
                <clause id="sect54.a-cla1">
                    <num>(1)</num>
                    <content>
                        <p> Blah blah</p>
                    </content>
                </clause>
            </section>
        </body>
        <outOfLines>
            <outOfLine id="out01" type="sideNote" href="#sect54.a-cla1">
                <p>Cap 75.</p>
            </outOfLine>
        </outOfLines>
    </act>
</akomaNtoso>

Please note three issues:

• Reference direction is reversed than with footnotes: rather than the inline content referring to the note, it is the side note referring to the structural fragment it appears with. This allows to get rid of reference markers within the text, and makes more sense in an abstract sense.
• Only referable structures can have a side note. This means that side notes are to be considered associated to sections, clauses, etc. and not to the text they contain. If a fragment of text needs to have a side note, it must be wrapped in a referable fragment, such as a ref or a span element.
• While the previous sideNote element was a block, and thus could contain directly text, the outOfLine element is a container, and thus must contain one or more blocks that in turn contain text.

This modification is NOT backward-compatible. Elements have been removed and a whole new section created in all types of documents.

9.1.2 Content model reorganization for speeches

After being shown an Australian judgement that was really a dialogue between the judge and the lawyers, and considering that AKOMA NTOSO already has all the necessary elements to deal with dialogues, only they were not available in judgements, it was decided that all speech elements should now be available everywhere a container is available. Thus elements such as speech, question and answer are now available even in judgements.

This modification IS backward-compatible. Content models have been expanded.

9.1.3 New inline elements

A number of new inline elements have been added to this release:

• Element lawyer is used to mark the specification of a lawyer. Attribute represents can be used to refer to the party it represents and the attribute role can be added to provide more detailed information about the kind of lawyer.
• Element opinion is used to specify the opinion of the individual judge within the coram of a judgement. Use attribute refersTo to point to a TLCConcept that provides computable assessment of the type of opinion held by the judge.
• Element signature is used to specify the presence of a signature in the document. Use attribute refersTo to point to a TLCPerson that provides the identification of the person responsible of the signature.
• Element entity is used to wrap any mention to a concept that is worth being mentioned in the references section. This includes persons, organizations, roles, and places, among others. Always use attribute refersTo to point to a Top Level Class element in the references section that provides computable assessment of the concept associated to that element.
• Element date is used to wrap explicit dates in the document (that are not documentDates). Use attribute date to provide an unambiguous form of the date in XSD 1.0 syntax yyyy-mm-dd. Use attribute refersTo, if appropriate, to point to a TLCEvent that provides computable assessment of the event associated to that date. Please note that a date element was already present in the schema in the identification section of the metadata, and that it has now been renamed FRBRdate (see section 9.1.5).

This modification IS backward-compatible. Elements have been added.

9.1.4 Judgement-specific and act-specific elements reunited

Elements judgementType, judgementTitle and judgementNumber were considered overlapping and redundant with respect to documentType, documentTitle and documentNumber, and thus removed. Judgements should now use these documents. Furthermore, a new section in the Release Notes has been added providing hints at how to use these elements, section 7.2, that specifies that these elements may be present multiple times in the document, but if there are more than one per type, then the attribute refersTo must be present and point to different instances of TLCConcepts.

This modification is NOT backward-compatible. Elements have been removed.

9.1.5 Name changes in metadata elements

Elements within FRBRWork,  FRBRExpression , FRBRManifestation, and FRBRItem have now an added FRBR prefix, and thus were turned from this, uri, alias, date, and author to FRBRthis FRBRuri, FRBRalias, FRBRdate, and FRBRauthor.

A new element date was added, and its name clashed with the elements within the FRBR levels. Given the philosophy of giving short names to elements within the content, and longer names to elements within the metadata, it was decided to change the name of the FRBR elements, and of all it neighbors, by introducing the same FRBR prefix for all.

This modification is NOT backward-compatible. Element names have been changed.

9.1.6 Bug fixes

• A few elements now required presence of two main attributes: id and refersTo. These are *ref and *mod elements, plus elements party, judge and the new element lawyer. Previously both id and refersTo were optional. This modification is NOT backward-compatible. Attributes have been made required.
• Element scene was previously present as both a container and a block. This is an error, and has been fixed. Element scene is now only a container available everywhere a container can be specified. This modification is NOT backward-compatible, but minor.

9.2 Differences between release 5/11/2008 and release 3/3/2008 

This release comprises a major modification in naming of elements, introducing a systematic usage of  camel case, settling a long-standing issue about incoherence in the usage of lower and uppercase characters in element names (as well as one element group). This change is thus fixing an overall problem of coherence in element naming, rather than a concrete problem of descriptiveness or completeness of the vocabulary.

Content differences:

• The spelling “judgment” has been replaced with “judgement” in observance to the above-mentioned mail by Mariya Badeva. This relates to all elements and attributes containing the word judgement.
• All Top Level Classes have now a proposed syntax for IDs (that was up to this day only mentioned as TBD).
• Element comment has been renamed scene according to remarks about adopting a vocabulary more connected to screenplays.
• Elements ActType, ActTitle, ActNumber, ActProponent, ActDate, and ActPurpose have been renamed docType, docTitle, docNumber, docProponent, docDate, and docPurpose so as to reflect a vocabulary apt to describe more than just legislation.
• Element recordedTime has now a new attribute type to allow for the specification of recorded times for the beginning of event (startEvent) and end of events (endEvent) if necessary
• A new inline element remark has been added to specify editorial inclusions within the main text (for instance the caption of the speaker in the new page continuing from the previous one). An attribute type with an initial list of remark types (sceneDescription, phenomenon, caption, translation) is also added.

Case differences (specific to the camelCase release):

• A specific policy for case in names has been decided. It only and specifically regards structure names in the schema (these include names for attributes, elements, simple types, complex types, attribute groups and element groups) that are composed of two separate terms in plain English. The policy is as follows:

• A name that is composed of a simple term is all in lowercase (e.g., section, act, publication).

• A name that is composed of two or more full terms has the first one in lowercase, and all the others have their initial letter in uppercase (that I call camelCase, as a reduced form of CamelCase). For instance, courtType, actDate, mainContent.

• A name that is composed of an acronym plus one or more full terms has the acronym in all capital letters and the remaining terms in camelCase (i.e., the first is all lowercase and the others have the first letter in uppercase). For instance, FRBRManifestation, TLCPerson.

• The element groups, complex types and simple types EventType, VersionType, InlineCM, SpeechSection,  HierarchicalStructure, OpenStructure, DebateStructure, JudgmentStructure and DocumentTypes are now eventType, iversionType, inlineCM, speechSection, hierarchicalStructure, openStructure, debateStructure, judgementStructure (note new spelling for judgement) and documentType (note, also singular now) in camelCase.

• 17 elements have changed their case in order to adopt the camelCase approach: elements activeModifications, activeRef, akomaNtoso, attachmentOf, debateRecord, efficacyMod, forceMod, hasAttachment, mainContent, meaningMod, noteRef, passiveModifications, passiveRef, proceduralMotions, scopeMod, textualMod, and tocItem.

9.3 Differences between release 3/3/2008 and 22/10/2007 

This is a tentative release of a major evolution, with a specific improvement, namely the support for judgments. Other minor modifications have been included. Existing documents that are not judgments should be unaffected by this release.

Most of the modifications accept and organize the proposal from Monica Palmirani in a document called “Common Open Standard for Judgments”.

Modifications unrelated to the judgment we find:

• A new element for debate documents called DeclarationofVote
• A new element this is added in all FRBR levels to report the URI of the specific component where the metadata block is found
• The name for the Attachment element in the analysis element is now HasAttachment in order to avoid confusions. 

Modifications related to the judgment as specified in Palmirani’s document are:

• A new document type “judgement” is introduced, that has its own schema composed of meta, header, judgmentBody, conclusions and attachment.
• Within the section header a number of additional inline-level purpose-specific elements have been added, namely: judgmentType, judgmentTitle, judgmentNumber, courtType, neutralCitation, party, judge, and judgmentDate.
• The judgmentBody has a repeatable choice of sections named introduction, background, motivation, and decision.
• An additional metadata element, workflow, and its repeatable child action have been added.

Some modifications diverge from Palmirani’s proposal, as follows:

• No elements such as coram, judges and judgmentDates have been specified, as they are containers, disallowed in the patterned structure of inline elements. The corresponding singular elements are used directly in the flow of the text.
• The element body has been substituted with judgmentBody, as body has been used already to refer to the content of hierarchical structures such as acts and bills.
• The href attributes in part, judge and action, meant to refer to the ontological section references, have been omitted as the proper attribute refersTo now exist for all elements in the schema, and therefore no need for such attribute was needed. The as attribute, on the other hand, has been kept as proposed.

Open issues are as follows:

• We have adopted the spelling “judgment” instead of “judgement” as proposed by Palmirani, but we are worried about the last sentence in the following fragment from http://en.wikipedia.org/wiki/Judgment_%28law%29: “However, the spelling judgement (with e added) largely replaced judgment in the United Kingdom in a non-legal context […] In the context of the law and theology, however, judgment is preferred. In the U.S. judgment strongly prevails. As with many such spelling differences, both forms are equally acceptable in Canada and Australia, although judgment is more common in Canada and judgement in Australia.[1] In New Zealand the form judgment is the preferred spelling in dictionaries, newspapers and legislation, although the variant judgement can also be found in all three categories. In South Africa, judgement is the more common form."
• We are not convinced of the need for a workflow element, and would have preferred to have it harmonized and included in the lifecycle element.

9.4 Differences between release 22/10/2007 and 17/09/2007

9.16 Differences between release 15/11/2005 and release 15/09/2005