[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalcitem-technical] Comparison of ELI, Akoma Ntoso (AKN), and LLL (USLM) referencing schemes.
On Tue, May 26, 2015 at 1:45 AM, monica.palmirani
<monica.palmirani@unibo.it> wrote:
> Hi Frank,
> about the jurisdiction(s) it is better for me to have both elements:
> - country
> - jurisdiction(s)
>
> Example: UK
> Jurisdictions: England+Wales
> http://www.legislation.gov.uk/ukpga/2015/23/introduction?view=extent
Separating the two exposes a general schema to political controversy
over what constitutes a country:
United Nations
Republic of Abkhazia
London Court of International Arbitration
World Trade Organization
World Bank Group / ICSID
Council of Europe
FB
>
> Yours,
> mp
>
> Il 25/05/2015 14:50, Frank Bennett ha scritto:
>>
>> I have added a couple of comments below, on the recording of
>> jurisdictions and authorities in feature-sets.
>>
>> Frank
>>
>> On Mon, May 25, 2015 at 3:53 PM, monica.palmirani
>> <monica.palmirani@unibo.it> wrote:
>>>
>>> Dear all,
>>>
>>> my few comments below.
>>>
>>> Yours,
>>> Monica
>>>
>>>
>>> Il 24/05/2015 22:26, Fabio Vitali ha scritto:
>>>>
>>>> Dear all,
>>>>
>>>> If there is no other contribution, I'll try to give a summary of what
>>>> this
>>>> discussion has unearthed:
>>>>
>>>> 1) parsability of the reference is an issue. Rather, it's THE issue.
>>>>
>>>> CT says:
>>>>>
>>>>> It proved impossible to find a standard approach as values essential to
>>>>> one country were completely irrelevant to another.
>>>>
>>>> I fear that if this is the case, we will have to go through the same
>>>> path
>>>> that ELI did and see if we find ourselves in the same situation. We
>>>> shall
>>>> need to examine references that cannot be accommodated in a unique
>>>> schema,
>>>> and try to understand why and if there is a way out.
>>>>
>>>> As a matter of principle, let me remind that the purpose of this
>>>> exercise
>>>> is NOT to find the best URI scheme, but to find the best features of
>>>> each
>>>> and combine them together to generate (from scratch, if needed) a schema
>>>> that is better than all the existing ones.
>>>>
>>>> GCV says;
>>>>>
>>>>> The benefit of an open syntax is that any unforeseen use case can be
>>>>> handled
>>>>
>>>> I believe that there is gray area between the rigid "Only the things we
>>>> now know about shall be needed for the identification" and the open "We
>>>> will
>>>> never know every use case so let's not stipulate anything in the ones we
>>>> know". In particular, I believe we could and should stipulate rules for
>>>> the
>>>> features we already know about (e.g., country, language, dates, etc.)
>>>> and
>>>> leave room for the ones that may have differences in individual
>>>> countries.
>>>>
>>>> CT says:
>>>>>
>>>>> Although ELI is flexible the expectation is that each official
>>>>> legislation publisher decides on the fixed variation they will use and
>>>>> then
>>>>> lodges their URI scheme in the ELI register
>>>>
>>>> I believe we have wider use cases: in particular, I do not want to
>>>> restrict ourselves only to national legislation, for obvious reasons,
>>>> nor
>>>> only to official, authoritative resolvers managed by state-managed
>>>> publishers. The issue of providing resolution is political and
>>>> technical,
>>>> while the issue of providing names is cultural and structural, and is
>>>> the
>>>> business we are in: resolvers and documents may come from anywhere with
>>>> any
>>>> type of authoritativeness.
>>>> CT says:
>>>>>
>>>>> Most countries already have a website and are not in a position to be
>>>>> able to create a new one from scratch. In order for them to implement
>>>>> ELI it
>>>>> needed to be flexible enough to fit in with existing architecture will
>>>>> minimum alteration.
>>>>
>>>> I see that this is an issue. But since we are considering to go through
>>>> a
>>>> resolver, we do not have the requirement to modify the physical URL of
>>>> documents, but just the mechanisms through which the mapping between
>>>> abstract URIs and concrete URLs is organized. Any kind of legacy naming
>>>> convention lies at the end of this process, and should not be able to
>>>> impact
>>>> on it.
>>>>
>>>> CT says:
>>>>>
>>>>> If ELI has been implemented it's the http ELI identifier that returns
>>>>> the
>>>>> document on the national legislation website so there's no need for
>>>>> parsing
>>>>> for any additional resolution.
>>>>
>>>> So ELI is actually a suggestion for physical naming of files so that it
>>>> does not require resolution. I think that we CAN find a residual
>>>> justification for this: e.g., if all countries implemented ELI for their
>>>> physical naming schemes, then resolution from LegalCitem references to
>>>> ELI
>>>> names would be very easy.
>>>>
>>>> CT says:
>>>>>
>>>>> ELI was designed as a common official URI scheme it didn't really
>>>>> consider citations or links for use on other legal websites.
>>>>
>>>> Good to know. On the other hand, we here deal with references, so this
>>>> is
>>>> an issue we must consider. For instance, view date is not an issue in
>>>> identifiers, but it is a BIG issue in references. I can provide details
>>>> on
>>>> this.
>>>>
>>>> CT says:
>>>>>
>>>>> However, saying that I do think that parseability would be useful. I
>>>>> wonder if it would be possible to allow greater flexibility than a
>>>>> universally fixed scheme by allowing some custom values and some kind
>>>>> of
>>>>> embedded statement or declaration about what's being used?
>>>>
>>>> Yes, I think we should strive for that. Only, what you call custom
>>>> values
>>>> I prefer to call optional features. Would that work for you?
>>>>
>>>> 2) Features
>>>> It may be my impression, but when we'll examine the output of the
>>>> various
>>>> subgroups we will have to strive hard to identify info sufficiently
>>>> organized into structured data that we will be able to place them as
>>>> features in our schema.
>>>>
>>>> So we should start looking into the "minimum required set of features
>>>> that
>>>> will be obviously needed".
>>>>
>>>> A brief list off the top of my mind:
>>>> 1) country
>>>> 2) language
>>>> 3) document type
>>>> 4) creation date (for the subtle interpretations of what "creation"
>>>> actually means, let's consider a separate discussion thread)
>>>> 5) secondary dates (e.g. version date, view date, etc.)
>>>>
>>> MP: for the WORK level we need also:
>>> - jurisdiction is another important information different from the
>>> "country"
>>> information (e.g., UK case or judgments);
>>
>> I would favor replacing country with jurisdiction entirely, and
>> casting this feature as a path, with national jurisdictions rooted on
>> the country. The sub-elements of non-nations (e.g. international
>> bodies, or virtual jurisdictions representing mere categories, such as
>> ad hoc arbitration panels) can be expressed in the same fashion. That
>> is what urn:lex proposes (at section 2.4 of draft 09), and (in terms
>> of structure, at least) it seems a good approach.
>>
>>> - authority (e.g. Uruguay needs to add "chamber" and "senate" for
>>> distinguish the same document in two different WORKs);
>>
>> For what it's worth, I would favor using a path-like identifier
>> to specify issuing bodies with rule-making authority as well, with
>> committees and the like set as a separate feature.
>>
>>> - number (e.g., Argentina uses only the unique number of bill for all the
>>> legislative process without date because the number is enough to
>>> unequivocally identify the document).
>>>
>>> I totally agree that about "creation" date definition we need a separate
>>> thread.
>>>
>>> For now let me say that the "creation date" in legal domain could be:
>>> "the date when a document assumes legal meaning in a given workflow step
>>> according to a specific legal system regulation and following the rules
>>> of
>>> procedure defined by the authority emitting the document".
>>>
>>> This means for instance, but not limited:
>>> - the date of promulgation of the president for the acts in a Republic
>>> for
>>> of government
>>> - the date of assent of the Queen for the acts where we have the
>>> - the date of admission of a draft-proposal-bill as a BILL in the
>>> parliament
>>> process
>>> - the date of emanation of a judgment
>>> - the date of publication of the order of a day
>>> - the date of creation of a generic document.
>>>
>>>> CT says:
>>>>>
>>>>> If you want to create a URI for this item of legislation as it stood at
>>>>> a
>>>>> particular point in time, e.g. "decree of 1st May 2015" as it stood on
>>>>> 2015-05-20, you end up with two date values in your URI the different
>>>>> date
>>>>> formats are signifying this difference.
>>>>
>>>>
>>>> Changing the syntax to distinguish between types of dates is a working
>>>> approach. I don't like it, but I can see it working. Nonetheless, if we
>>>> find
>>>> a better approach, I would prefer it.. For instance, Akoma Ntoso uses
>>>> the
>>>> positional difference and special separators to obtain the same result.
>>>>
>>>> GCV says:
>>>>>
>>>>> I see {year} all the the time. For example
>>>>> /{jurisdicion}/{year}/{sessionNum}/... I believe that notion of {year}
>>>>> is in
>>>>> keeping with ELI's notion of separating year, month, and day. I don't
>>>>> have a
>>>>> use case that extends beyond {year} in a legislative context.
>>>>
>>>>
>>>> In a parsable syntax, we would KNOW that a date is a date, and would be
>>>> able to correctly identify 2015 as a year-only date, 2015-05 as a
>>>> month+year
>>>> date, and 2015-05-24 as a full date. There are THREE cases, not two
>>>> thousands. Can we expect the software to handle three types of date
>>>> specifications?
>>>>
>>>> So if I see something like /{jurisdiction}/2015/{sessionNum}/ I can
>>>> understand that 2015 is a date, while if I see something like
>>>> /{jurisdicion}/2015-05-24/123/ I can understand that 2015-05-24 is a
>>>> full
>>>> date. It CAN be done.
>>>>
>>>>> Perhaps there are two notions of time that we must separate. The first
>>>>> is
>>>>> a construct that is purely for organizing information in some logical
>>>>> structure. The second is its use in defining a point-in-time context.
>>>>> The
>>>>> structure {year}[/{month}[/{day}]] is useful when organizing
>>>>> information --
>>>>> not so much for establishing the temporal context.
>>>>
>>>> I don't see what 2015/04 can give you that 2015-05 can't, and see
>>>> plenty
>>>> of troubles that 2015/05 would bring (again, because of parsability) and
>>>> 2015-05 would avoid.
>>>>
>>>> GCV says:
>>>>>
>>>>> Yeah, yeah, yeah. I think I live in that state too! ;-)
>>>>
>>>> Ok, thanks. :-) So we agree that national language is a requirement even
>>>> in situations where there is only ONE official language?
>>>>
>>>> Let me confess that I sometimes fear that English-speaking countries
>>>> tend
>>>> to consider other languages, and countries with more than one language,
>>>> as
>>>> nuisances that would be better off by renouncing to their language and
>>>> just
>>>> adopt English.
>>>>
>>>> GCV says:
>>>>
>>>>> I brought this up as I have seen use cases, with bills, in which there
>>>>> are multiple versions within a single day. These are corrections that
>>>>> are
>>>>> published after the initial version was published with an error. The
>>>>> corrected reprint gets a new version.
>>>>
>>>> Ok. This is a thing in which Akoma Ntoso comes short. We SHALL need to
>>>> have both the date AND the version identifier in expressions. Good to
>>>> know.
>>>>
>>>> Ciao
>>>>
>>>> Fabio
>>>>
>>>> --
>>>>
>>>>
>>>> On 20/mag/2015, at 13:17, "Tabone, Catherine"
>>>> <Catherine.Tabone@nationalarchives.gsi.gov.uk> wrote:
>>>>
>>>>> Hi everyone,
>>>>> A few additional comments from me, marked CT:
>>>>> Regards,
>>>>>
>>>>> Catherine
>>>>> From: legalcitem-technical@lists.oasis-open.org
>>>>> [mailto:legalcitem-technical@lists.oasis-open.org] On Behalf Of Grant
>>>>> Vergottini
>>>>> Sent: 18 May 2015 20:13
>>>>> To: Fabio Vitali
>>>>> Cc: Daniel LUPESCU; legalcitem-technical@lists.oasis-open.org
>>>>> Subject: Re: [legalcitem-technical] Comparison of ELI, Akoma Ntoso
>>>>> (AKN),
>>>>> and LLL (USLM) referencing schemes.
>>>>> My thoughts below at GCV:
>>>>> 2015-05-18 9:45 GMT-07:00 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.
>>>>> GCV: I agree that a parseable structured syntax is better than the
>>>>> open
>>>>> one of ELI. The benefit of an open syntax is that any unforeseen use
>>>>> case
>>>>> can be handled - the downside is how you choose to handle it is
>>>>> unspecified.
>>>>> I'm guessing that the team behind ELI basically agreed to disagree on a
>>>>> format and the result was a minimum of structure -- which also came
>>>>> with a
>>>>> minimum of usefulness.
>>>>>
>>>>>
>>>>> CT: Personally I see pros and cons for each approach. A fixed pattern
>>>>> is
>>>>> easier to understand and parse without too much work as the pattern is
>>>>> always the same. The problem is that there will inevitably be
>>>>> legislation
>>>>> that doesn't fit into the syntax pattern which means it either won't be
>>>>> implemented at all or it will be implemented in a non-standard way
>>>>> which
>>>>> undermines the parsability. The more flexible structure is easier to
>>>>> bend to
>>>>> fit all the weird and wonderful examples of necessary legislation
>>>>> citation.
>>>>> It's disadvantage is that is harder to reuse.
>>>>>
>>>>> Additionally couple of things to put the ELI approach into context:
>>>>>
>>>>> The features that uniquely identify an item of legislation are very
>>>>> different in different EU countries, e.g. some use a legislation type,
>>>>> year
>>>>> and series number, some use a signature or enactment date and
>>>>> legislation
>>>>> type, some use type, series number and parliamentary session, others
>>>>> switch
>>>>> schemes at some historical point. It proved impossible to find a
>>>>> standard
>>>>> approach as values essential to one country were completely irrelevant
>>>>> to
>>>>> another. ELI is designed not as an abstract identifier but to be the
>>>>> URI
>>>>> used to access the legislation item on an official publisher's website
>>>>> for
>>>>> each EU country. Most countries already have a website and are not in a
>>>>> position to be able to create a new one from scratch. In order for them
>>>>> to
>>>>> implement ELI it needed to be flexible enough to fit in with existing
>>>>> architecture will minimum alteration.
>>>>>
>>>>> Although ELI is flexible the expectation is that each official
>>>>> legislation publisher decides on the fixed variation they will use and
>>>>> then
>>>>> lodges their URI scheme in the ELI register (countries are still in the
>>>>> process of implementation and the ELI register website is still being
>>>>> set-up
>>>>> so unfortunately there's nothing to look at yet). This means that if
>>>>> you
>>>>> wanted to parse ELI URIs you could do this but you would need to deal
>>>>> with
>>>>> the URI scheme for each country separately. This appears as more work
>>>>> but I
>>>>> wonder if it's actually equivalent to what you need to do to get an AKN
>>>>> resolver to work? You do the work at a different point but essentially
>>>>> you
>>>>> are still trying to get the reference to resolve to the actual web
>>>>> page.
>>>>>
>>>>>
>>>>>> - 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.
>>>>> GCV: Bothers me too.
>>>>> CT: The reason for the different date formats is to allow for the
>>>>> fact
>>>>> that some countries may need two dates in the URI. In a significant
>>>>> number
>>>>> of European countries (although not the UK) the identifier for
>>>>> legislation
>>>>> is the signature date, i.e. it is the "decree of 1st May 2015" there is
>>>>> no
>>>>> series number. If you want to create a URI for this item of legislation
>>>>> as
>>>>> it stood at a particular point in time, e.g. "decree of 1st May 2015"
>>>>> as it
>>>>> stood on 2015-05-20, you end up with two date values in your URI the
>>>>> different date formats are signifying this difference. It's also to
>>>>> accommodate people who want to use the URI as a hackable search string
>>>>> e.g.
>>>>> decree/2015/05/01 is the specific document, decree/2015/05 is all the
>>>>> documents in May, decree/2015 all documents in 2015.
>>>>>
>>>>>
>>>>> 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?
>>>>> GCV: I see {year} all the the time. For example
>>>>> /{jurisdicion}/{year}/{sessionNum}/... I believe that notion of {year}
>>>>> is in
>>>>> keeping with ELI's notion of separating year, month, and day. I don't
>>>>> have a
>>>>> use case that extends beyond {year} in a legislative context.
>>>>> GCV: Perhaps there are two notions of time that we must separate.
>>>>> The
>>>>> first is a construct that is purely for organizing information in some
>>>>> logical structure. The second is its use in defining a point-in-time
>>>>> context. The structure {year}[/{month}[/{day}]] is useful when
>>>>> organizing
>>>>> information -- not so much for establishing the temporal context.
>>>>>
>>>>>> - 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.
>>>>> GCV: Yeah, yeah, yeah. I think I live in that state too! ;-)
>>>>>
>>>>>> - 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.
>>>>> GCV: I brought this up as I have seen use cases, with bills, in
>>>>> which
>>>>> there are multiple versions within a single day. These are corrections
>>>>> that
>>>>> are published after the initial version was published with an error.
>>>>> The
>>>>> corrected reprint gets a new version.
>>>>>
>>>>>> - 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.
>>>>>
>>>>> GCV: I agree that having different limiters is better. Otherwise, you
>>>>> have a set of delimited values and it's difficult, without applying
>>>>> some
>>>>> other probably unreliable heuristic, to know what is what.
>>>>>
>>>>>> - 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
>>>>>
>>>>> GCV: I vote yes too.
>>>>> 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?
>>>>> GCV: I think that parseability is something that ELI sacrificed in
>>>>> order to come to some agreement, with a substantial loss of usefulness.
>>>>> I
>>>>> believe that one of our core goals should be to establish a scheme that
>>>>> allows for unambiguous parsing of key information, while still allowing
>>>>> for
>>>>> the widest range of possible use cases. Deciding what is the key
>>>>> information
>>>>> should be part of our focus.
>>>>> CT: I think there is a significant difference in context here. There
>>>>> was no requirement to parse ELI URIs. If ELI has been implemented it's
>>>>> the
>>>>> http ELI identifier that returns the document on the national
>>>>> legislation
>>>>> website so there's no need for parsing for any additional resolution.
>>>>> ELI
>>>>> was designed as a common official URI scheme it didn't really consider
>>>>> citations or links for use on other legal websites. However, saying
>>>>> that I
>>>>> do think that parseability would be useful. I wonder if it would be
>>>>> possible
>>>>> to allow greater flexibility than a universally fixed scheme by
>>>>> allowing
>>>>> some custom values and some kind of embedded statement or declaration
>>>>> about
>>>>> what's being used?
>>>>>
>>>>> 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/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ____________________________________________________________________
>>>>> Grant Vergottini
>>>>> CEO & Founder, Xcential
>>>>> email: grant.vergottini@xcential.com
>>>>> phone: 858.361.6738
>>>>>
>>>>> This email was scanned by the Government Secure Intranet anti-virus
>>>>> service supplied by Vodafone in partnership with Symantec. (CCTM
>>>>> Certificate
>>>>> Number 2009/09/0052.) In case of problems, please call your
>>>>> organisations IT
>>>>> Helpdesk.
>>>>> Communications via the GSi may be automatically logged, monitored
>>>>> and/or
>>>>> recorded for legal purposes.
>>>>>
>>>>>
>>>>> Please don't print this e-mail unless you really need to.
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------------------------
>>>>>
>>>>> National Archives Disclaimer
>>>>> This email and any files transmitted with it are intended solely for
>>>>> the use of the
>>>>> individual(s) to whom they are addressed. If you are not the intended
>>>>> recipient and
>>>>> have received this email in error, please notify the sender and delete
>>>>> the email.
>>>>> Opinions, conclusions and other information in this message and
>>>>> attachments that do
>>>>> not relate to the official business of The National Archives are
>>>>> neither
>>>>> given nor
>>>>> endorsed by it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>> .
>>>>
>>>
>>> --
>>> ===================================
>>> Associate professor of Legal Informatics
>>> School of Law
>>> Alma Mater Studiorum Università di Bologna
>>> C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/
>>> Palazzo Dal Monte Gaudenzi - Via Galliera, 3
>>> I - 40121 BOLOGNA (ITALY)
>>> Tel +39 051 277217
>>> Fax +39 051 260782
>>> E-mail monica.palmirani@unibo.it
>>> ====================================
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>> .
>>
>
>
> --
> ===================================
> Associate professor of Legal Informatics
> School of Law
> Alma Mater Studiorum Università di Bologna
> C.I.R.S.F.I.D. http://www.cirsfid.unibo.it/
> Palazzo Dal Monte Gaudenzi - Via Galliera, 3
> I - 40121 BOLOGNA (ITALY)
> Tel +39 051 277217
> Fax +39 051 260782
> E-mail monica.palmirani@unibo.it
> ====================================
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]