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