[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comparison of ELI, Akoma Ntoso (AKN), and LLL (USLM) referencing schemes.
Hi all, Below is my comparison of the three URL based referencing schemes. They are truly very similar. I took a stab at the ELI scheme despite not having too much familiarity with it. Please correct as necessary. Comparison of ELI, AKN, and LLL (USLM) legislative referencing schemes ====================================================================== ------------------------------------------------------------------------------- BASIC SYNTAX eli: /eli[/{jurisdiction}][/{agent}][/{subAgent}][/{year}][/{month}][/{day}][/{type}][/{naturalIdentifier}][/{level…}][/{pointInTime}][/{version}][/{lang}] akn: /akn/{jurisdiction}/{docType}/{docNum}[/{docDate}][[{lang}]@[{versionOrPointInTime}]][~{portionId}][/{source][.{format}] uslm: /uslm/{jurisdiction}/{docSet...}/{docName}[{level...}][@{versionOrPointInTime}][~{portionId}][.{format}] Where: parenthesis denote variable fields square brackets denote optional parts an ellipsis at the end of text in parenthesis denotes 1 or more occurrences Comments: All elements in ELI are optional as is their order. ------------------------------------------------------------------------------- STARTING MATTER eli: /eli/{jurisdiction} akn: /akn/{jurisdiction} uslm: /uslm/{jurisdiction} All three schemes essentially take the same approach for the initial part of the URL, differing only in the scheme name. ------------------------------------------------------------------------------- FRBR ORGANIZATION For the sake of organizational discussion, and taking the lead from Akoma Ntoso, the basic syntax after the starting matter is being divided into four parts, borrowing the FRBR concepts of WORK, EXPRESSION, and MANIFESTATION. While not a perfect match, all three schemes are being coerced to follow this model as follows eli: Work: [/{agent}][/{subAgent}][/{year}][/{month}][/{day}][/{type}][/{naturalIdentifier}] Expression: [/{level...}][/{pointInTime}][/{version}][/{lang}] Manifestation: akn: Work: /{docType}/{docNum}[/{docDate}] Expression: [[{lang}]@[{versionOrPointInTime}]][~{portionId}] Manifestation: [/{publisher][.{format}] uslm: Work: /{docSet...}/{docName} Expression: [{level...}][@{versionOrPointInTime}][~{portionId}] Manifestation: [.{format}][?source={publisher}] Comments: Does ELI handle the manifestation level? The {level...} and the {portionId} specification (discussed below) are considered as part of the expression as the are time variant. ------------------------------------------------------------------------------- THE WORK eli: [/{agent}][/{subAgent}][/{year}][/{month}][/{day}][/{type}][/{naturalIdentifier}] akn: /{docType}/{docNum}[/{docDate}] uslm: /{docSet...}/{docName} Path to document: All three schemes can be seen to be defining a part to a document resource. ELI defines seven named parameters which can be used, presumably in any hierarchy. Akoma Ntoso defines a fixed hierarchy based on document type, number, and date. USLM defines an open hierarchy. Document Name: ELI describes a natural identifier as the name of the document. Akoma Ntoso partitions out the document name, number, and date. USLM defines a docName that is apparently analogous to ELI's natural identifier. ------------------------------------------------------------------------------- THE EXPRESSION eli: [/{level...}][/{pointInTime}][/{version}][/{lang}] akn: [[{lang}]@[{versionOrPointInTime}]][~{portionId}] uslm: [{level...}][@{versionOrPointInTime}][~{portionId}] Language: ELI permits a hierarchical level corresponding to the language. Akoma Ntoso encodes the lang to precede the '@' character. USLM does not have any provisions for language - English is the sole language for US legislation. Point-in-time Date: ELI permits a hierarchical level corresponding to the point-in-time date. Akoma Ntoso encodes the point-in-time date to follow the '@' character. USLM encodes the point-in-time date to follow the '@' character. Note: There is a subtle difference between Akoma Ntoso and USLM when there is no language specification. Akoma Ntoso would express a simple URI as {work}/@{point-in-time} while USLM would express the same as {work}@{point-in-time}. Note the missing '/' in the USLM notation. This is because USLM does not have any provision for the {lang} prior to the '@' character -- or in any other place, for that matter.. Version: ELI permits a version number as a hierarchical level. Akoma Ntoso permits a version number in place of a version date following an '@'. (Fabio???) USLM permits a version number in place of a version date following an '@'. Portions: ELI permits a document portion to be expressed as levels within the natural hierarchy of the reference. Akoma Ntoso permits a portion to be specified in the form of an identifier query following a tilde '~'. In Akoma Ntoso, identifiers (specifically the @wId and @eId attributes) are expressed as after pseudo-hierarchy following a strictly defined nomenclature. Double underscores '__' denote the hierarchical levels. Level prefixes are prescribed. USLM takes a similar approach to ELI, permitting a document portion to be expressed as levels within the natural hierarchy of the reference. This is because different implementation of the US Code partition the US Code into individual documents differently. The value of the USLM level hierarchy corresponds exactly to the value of the @identifier attribute within the XML -- similar in nature to how the Akoma Ntoso ~portionId corresponds to the @eId. Prescribed level prefixes are used for "big" levels (section and above) and omitted for "small" levels (below the section). USLM also supports the ~{portionId} method, but USLM @id values are expressed as GUIDs rather than as meaningful identifiers. Due to the unreadability of USLM @id's and instability maintaining @id values, this method in USLM is only for short-term usages and should never be persisted. Ranges: USLM has provisions for ranges within the level hierarchy expressed to reference a portion of a document. The basic nomenclature is a series of three periods "...". This is used between two numbers at a level. For instance sec1...5 is the range of sections between and including sections 1 and 5. If the terminating number is omitted, that signifies an open end and corresponds to "et seq." in a citation. Complex non-contiguous ranges are expressed as a sequence of references. There is no provision for a sequence which starts at one level and ends at a different level -- this is proving problematic. Disambiguation: USLM has provisions for disambiguating duplicate numbers. It is quite common, and unfortunate, that provisions are often misnumbered and duplicate numbering accidentally occurs. For instance, it is possible that two unrelated section 1234 come into existence and are simultaneously both effective law. In citations, this is handled through "qualifying" or "disambiguating" language such as "as added by..." or "as amended by...". USLM allows this reference to the originating or amending provision to be encoded to follow the level in the hierarchy containing the ambiguity within square brackets. For instance: /uslm/us/usc/t100/div4/chap5[/uslm/us/usc/pl/2014/200/sec3]/art1 indicates that there are duplicate chapter 5s and that the one created or modified by /uslm/us/usc/pl/2014/200/sec3 is the one being referred to. ------------------------------------------------------------------------------- THE MANIFESTATION eli: ??? akn: [/{publisher][.{format}] uslm: [.{format}][?source={publisher}] ELI does not appear to deal with the manifestation level. ??? Akoma Ntoso allows the publisher and the file format to be specified. The file format is always at the end of the reference and appears as a normal file extension -- permitting 3 or 4 characters USLM allows the file format to be specified. Similar to Akoma Ntoso, the file format is always at the end of the reference and appears as a normal file extension. USLM has no provisions to specify the data source or publisher within the USLM schema. Instead the &source query parameter has been used to provide that function. -- Grant ____________________________________________________________________ Grant Vergottini Xcential Group, LLC. email: grant.vergottini@xcential.com phone: 858.361.6738
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]