Re: [legalcitem-technical] Comparison of ELI, Akoma Ntoso (AKN), and LLL (USLM) referencing schemes.

[Fabio Vitali <fvitali@gmail.com>]

Dear all, 

sorry for my silence. Since some subcommittees are starting to deliver documents on which we can begin our work, it is now time to rekindle our activities and start meeting again with some regularities. 

I'll rehash Daniel's answers to Grant document, this January, for the discussion to start again. My comments are inline. Meet you then in ten days from now. 

Ciao

Fabio

--

On 19/gen/2015, at 15:07, Daniel LUPESCU <dlupescu@sedona.fr> wrote:

> 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.

What do you mean by "open hierarchy"? 

AKN has a specific order in features, so as to allow reliable parsing. So far we haven't found instances where this is a problem. 

>         - Is it better to force a syntax or to leave it open? Both approaches have pros and cons.

Ok, let's try to list pros and cons, then. 

On my part, rigorous parseable syntax is a necessary condition for true internationalization, for they would allow people who've never seen a reference from Gambia or Bolivia or Bhutan to understand at least a little what kind of document that is. I think that this is an important requirement. 

I don't have cons to list. 

>     - Date: USLM and AKN both use the format YYYY-MM-DD (or only YYYY), whereas ELI uses /YYYY/MM/DD.

As far as I can tell, ELI uses both YYYY/MM/DD and YYYYMMDD without separators. the inconsistency is somewhat bothering me, I must confess. 

As for AKN, the choice of YYYY-MM-DD comes from the date data format of XML schema [1] and relax NG [2]. 

>         - ELI's format seems more powerful as it could potentially allow to retrieve all documents of a specific month using: /eli/{jurisdiction}/year/month

use case for this?

>    
> - FRBR EXPRESSION:
>     - Language:
>         - USLM does not have any provisions for language, but it seems obvious that the language is needed.

I agree this is an issue. Not my thing, but I can foresee a future not so far where at leas some state adopt Spanish as another official language with English. 

>         - 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

Can you elaborate on this?

Furthermore, AKN also has the view date, which allows for the specification of a version date for references whose exact version date you do not know. 

/us/act/2010/124Stat119/en@2010-01-24 is a reference to the version that entered in force on 2010-01-24, while 

/us/act/2010/124Stat119/en!2015-05-18 is a reference to the version that is in force today, regardless of when it was approved.

>         - 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

The basic idea of choosing different separator is to allow parsing. By using only ONE separator, you cannot allow for optional elements and still keep automatic parseability. 

>     - Portions: same remark about the '~' character as above   

And same issue for parseability. 

> - 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)

Ok. Thanks. 

I believe there is ONE open issues that is fundamental: 

1) Is automatic parseability important? I strongly vote for yes

This gives rise to a few dependent issues: 

If parseability is NOT important, then 

2a) why is a common syntax useful? I mean, wouldn't a lookup table just suffice for our purposes?

If parseability is important, then

2b) are there other ways to parse references without enforcing a fixed order and a variety of separators?

Thanks and ciao

Fabio

[1] http://www.w3.org/TR/xmlschema-2/#date
[2] https://www.safaribooksonline.com/library/view/relax-ng/0596004214/re91.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
> 
> 
> 



--

Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
phone:  +39 051 2094872              Man got to tell himself he understand.
e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.unibo.it/