[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.
Hi Fabio,
That sounds sensible to me. We already use ISO 3166 in the UK to describe the various UK jurisdiction variations (not currently very visible on the website but coming soon) having looked at various different schemes concluded that this was the most complete and useable. I agree we need a way to specify anything that isn't covered.
Regards,
Catherine
Catherine Tabone
Data Manager
Legislation Services
The National Archives, Kew, Richmond, Surrey TW9 4DU
+44 (0)20 8876 3444 ext. 2233
catherine.tabone@nationalarchives.gsi.gov.uk
www.legislation.gov.uk | www.nationalarchives.gov.uk
-----Original Message-----
From: legalcitem-technical@lists.oasis-open.org [mailto:legalcitem-technical@lists.oasis-open.org] On Behalf Of Fabio Vitali
Sent: 26 May 2015 10:34
To: Frank Bennett
Cc: monica.palmirani; legalcitem-technical@lists.oasis-open.org
Subject: Re: [legalcitem-technical] Comparison of ELI, Akoma Ntoso (AKN), and LLL (USLM) referencing schemes.
Dear all,
a summary on what I understood of the discussion.
Country and jurisdiction are a topic. Naively, I thought of jurisdictions as sub-country geographical or administrative entities, but Frank correctly pointed out that this is not the whole story.
So this is what I currently think:
1) the correct way to refer to a jurisdiction is through a hierarchy of parts. No-one will want to find out directly about the municipality of Budrio (a small town, 5000 persons, near Bologna), so we must specify the full hierarchy of parts to identify it, say:
country: Italy, region: Emilia-Romagna, municipality: Budrio.
2) At the top of the hierarchy we have a Top Level Jurisdiction (TLJ), which for practical purpose shall be defined as a "country (with exceptions)".
3) we are not in the business of deciding which jurisdictions are countries and which aren't, and what are its sub-jurisdiction and how are they called. We MUST delegate this to an external authority.
4) The best candidate that I know for an authority on TLJ is ISO 3166. This provides criteria for the specification of countries and their codes. ISO 3166 Maintenance Agency was constituted in the seventies and has given out codes for all countries that existed in and since 1974. Codes are not reused, so countries that dismembered after 1974 still have their own codes (which is useful in our case). ISO 3166 gives out also codes for first level sub-jurisdictions in many cases (e.g., individual US states) but does not go further than this. Many international organizations (including UN) have their own codes.
5) This approach provides a good solution in many cases, but there are a few that remain uncovered:
5-a) unlisted sub-jurisdictions of existing jurisdictions (e.g.: Budrio). Proposal: full name.
5-b) unrecognized countries (including ministates such as Liberland)
5-c) disputed lands
5-e) Unlisted international entities
5-f) historical jurisdictions (e.g., in Kenya some legislation refers to East African British Colonies, a jurisdiction covering current Kenya, Tanzania and Uganda and that stopped existing before 1974. Or, more simply, roman law).
5-g) International treaties (about which I strongly object to list explicitly all signing countries).
Let me know what you think.
Ciao
Fabio
--
On 25/mag/2015, at 23:23, Frank Bennett <biercenator@gmail.com> wrote:
> 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/059600421
>>>>>> 4/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}]@[{ve
>>>>>>> rsionOrPointInTime}]][~{portionId}][/{source][.{format}]
>>>>>>> uslm:
>>>>>>>
>>>>>>> /uslm/{jurisdiction}/{docSet...}/{docName}[{level...}][@{version
>>>>>>> OrPointInTime}][~{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}][/{na
>>>>>>> turalIdentifier}]
>>>>>>> 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_workgrou
>>>>>>> ps.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
>> ====================================
>>
>
>
> ---------------------------------------------------------------------
> 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 The sage and the fool
Dept. of Informatics go to their graves
Univ. of Bologna ITALY alike in this respect:
phone: +39 051 2094872 both believe the sage to be a fool.
e-mail: fabio@cs.unibo.it Where, then, may wisdom be found?
http://vitali.web.cs.unibo.it/ Qi, "Neither Yes nor No", The codeless code
---------------------------------------------------------------------
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
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.
------------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]