[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.
Looks good to me too. This is pretty much how the (more ad hoc) data
source for IDs used in the Juris-M reference manager (formerly
"Multilingual Zotero") is done:
Data: http://fbennett.github.io/legal-resource-registry/
Tools: https://juris-m.github.io/downloads/
In the data source, China and Vietnam are worth a look - they both set
romanized IDs from a non-English script. (There is a small possibility
of data loss in the conversion at present - the script does not
account for conflicting romanizations at the same nesting level.)
FB
On Wed, May 27, 2015 at 4:45 AM, Tabone, Catherine
<Catherine.Tabone@nationalarchives.gsi.gov.uk> wrote:
> Hi all,
>
> Considering the issue of parseability I wonder if we can find an approach that allows for parseability and clarity but is also flexible enough to allow for variations, i.e. combining the best of all worlds?
>
> This is only an off the top of my head suggestion so may not be desirable/useable at all but we might be able to achieve this with something like a list of enumerated features with definitions e.g. 1 = country 2 = language 3 = document type 4 = ... etc. the list can be added to and there could be a facility for custom values as well. We accept the fact that not all values are relevant or known for each citation and allow any combination in an identifier something along the lines of 1-UK/2-EN/3-Act/.....etc. so that each feature is clearly identifiable regardless of whether all are present or even the order used (you could potentially map this to other identifier schemes e.g. identifier with values 2, 5, 7, 3, 9 in that order is equivalent to an AKN identifier, a combination of values 1, 2, 3, 7, 9 in any order is equivalent to ELI etc.).
>
> Regards,
>
> Catherine
>
> -----Original Message-----
> From: Fabio Vitali [mailto:fvitali@gmail.com]
> Sent: 24 May 2015 21:27
> To: Tabone, Catherine
> Cc: Daniel LUPESCU; legalcitem-technical@lists.oasis-open.org; Grant Vergottini
> Subject: Re: [legalcitem-technical] Comparison of ELI, Akoma Ntoso (AKN), and LLL (USLM) referencing schemes.
>
> 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.)
>
> 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/tex
>> > te (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/re9
>> 1.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}][/{da
>> > y}][/{type}][/{naturalIdentifier}][/{level...}][/{pointInTime}][/{vers
>> > ion}][/{lang}]
>> > akn:
>> > /akn/{jurisdiction}/{docType}/{docNum}[/{docDate}][[{lang}]@[{versio
>> > nOrPointInTime}]][~{portionId}][/{source][.{format}]
>> > uslm:
>> > /uslm/{jurisdiction}/{docSet...}/{docName}[{level...}][@{versionOrPo
>> > intInTime}][~{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}][/{natura
>> > lIdentifier}]
>> > 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.p
>> > hp
>> >
>> >
>> >
>>
>>
>>
>> --
>>
>> 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.
>>
>>
>> ----------------------------------------------------------------------
>> --------------
>>
>>
>>
>>
>
> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]