Hi all,
To prepare the next TC meeting, here are a few thoughts on Grant's comparison:
- FRBR WORK:
- ELI and USLM both have an open hierarchy, whereas AKN has a fixed hierarchy.
- Is it better to force a syntax or to leave it open? Both approaches have pros and cons.
- Date: USLM and AKN both use the format YYYY-MM-DD (or only YYYY), whereas ELI uses /YYYY/MM/DD.
- ELI's format seems more powerful as it could potentially allow to retrieve all documents of a specific month using: /eli/{jurisdiction}/year/month
- FRBR _expression_:
- Language:
- USLM does not have any provisions for language, but it seems obvious that the language is needed.
- Both AKN and ELI uses a three-letter code according to ISO 639-3
- Point-in-time Date and version : USLM use @{version|YYYY-MM-DD}, AKN uses /@{version|YYYY-MM-DD}, ELI uses /YYYYMMDD/version
- ELI's format seems more powerful as both Point-in-time Date and Version can be present
- Both AKN and USLM introduce the '@' character whereas ELI use '/' as the only delimiter.
I find it simpler to have just 1 delimiter, especially as it is not common to find the '@' character in URLs, but again both approaches have pros and cons
- Portions: same remark about the '~' character as above
- FRBR MANIFESTATION:
- ELI does handle manifestation level.
Existing examples :
http://www.legifrance.gouv.fr/eli/loi/2011/12/29/ETSX1119227L/jo/texte/fr/pdf
http://www.legifrance.gouv.fr/eli/loi/2011/12/29/ETSX1119227L/jo/texte/fr/rtf
http://www.legifrance.gouv.fr/eli/loi/2011/12/29/ETSX1119227L/jo/texte (no format means /html)
Best regards,
Daniel Lupescu
SEDONA
10 Place de la Madeleine 75008 Paris
Tel: 01 83 64 51 61
dlupescu@sedona.fr
From: "Grant Vergottini" <grant.vergottini@xcential.com>
To: legalcitem-technical@lists.oasis-open.org, "Fabio Vitali" <fabio@cs.unibo.it>
Sent: Mercredi 7 Janvier 2015 20:44:39
Subject: [legalcitem-technical] 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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php