[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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]