OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legaldocml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [URI - naming convention]

Dear all,

about the URI naming convention of the legal resources, we would be
happy if you can send to the LegalDocML TC a brief document where you
present your naming convention for legal resources (if any) in order to
capture new requirements or simply to stress the Akoma Ntoso model.

We know the following naming conventions for legal resources:
- Metalex/CEN
- URN:Lex naming convention for legal resources in Europe
- ECLI naming convention for accessing to the Case-Law,

- Cornell University LII

It would be useful to understand the naming convention used by
LexisNexis, by the California State and also to the EU Parliament, but
also from the other TC members (Parliaments).

Many thanks in advance.

Monica and Fabio

Il 03/07/2012 15:39, Fabio Vitali ha scritto:
Dear all,

On 28/giu/2012, at 19.41, Flavio Zeni wrote:

Fabio and Roger,

              I think the concern of Roger is not on the how the URI is structured but on how can somebody make use of it.

More specifically, let's say that somebody come across an Akoma Ntoso document, since there is no base URL or reference to a resolver ... how can this somebody have any hope to find the "source" ?

But may be this was not the "concern" of Roger ... in that case ... ops, sorry :-) tried my best ...:-)
I will try to provide an answer to the doubts expressed by Roger and Flavio.

First of al, let me point out the obvious fact that an Akoma Ntoso document is an XML document, and as such is not immediately accessible through a browser. The most obvious use of an XML document is through one or more tools that provide context-dependent functional steps, for instance for rendering and semantics. For instance, the most obvious way to display an XML document is via an XSLT stylesheet that is often not specified in the document itself, but provided by the context.

More generally we have the XML document, which is and should be context-independent (i.e., it should NOT contain information about the specific architecture and tools that are needed to make use of them, lest we restrict ourselves to these specific architecture and tools and limit the useful lifespan of the document), AND we also have many specific tools, such as document servers, URI resolvers, XSLT stylesheets, etc., that provide the specific context for a successful and interesting use of this document. THESE TOOLS are the ones that need to take care of handling the context-specific tasks for the use of the document, whose details may change over time because of advancements in the technology.

<recap of URI theory, skip it if you are bored>
In the terminology introduced by RFC 3986, "URI Generic Syntax",http://tools.ietf.org/html/rfc3986, an Akoma Ntoso URI is an "absolute path relative URI" (section 4.2). Given the similarity of this term with absolute URI (section 4.3), which is a completely different thing, it was decided long ago to keep the "absolute URI" as in 4.3, and rephrase "absolute path relative URI" as a "global URI"

Let me give you a few examples:
1)http://www.site.com/path1/path2/path3#fragment   is an http-based absolute URI
2) urn:lex:part1:part2:part3:fragment              is a urn-based absolute URI
3) /path1/path2/path3#fragment                     is (in RFC 3986) an absolute path relative URI reference, or (in AN) a global URI
4) path2/path3#fragment                            is (in RFC 3986) a relative path relative URI reference, or (in AN) a relative URI
5) #fragment                                       is (in RFC 3986) a same-document URI reference, or (in AN) a local URI

Of these types of addresses, the http-based absolute URI is the only that is (potentially) usable by the browser to access the document, a process called dereferencing. All other addresses require an intermediate step, called resolution, meant to generate the corresponding http-based absolute URI from the given address. The resolution process is basically identical in all cases. yet, please note that even http-based absolute URIs may require a resolution process, e.g., whenever they do not specify the physical address of the requested resource, as in our case, because legal references are usually to abstract (Work-level or Expression-level) conceptualizations of a document, and almost never to (Item-level) physical files.

But regardless of whether they represent the physical address of the resource or the address of the engine that provides the resolution, http-based absolute URIs DO CONTAIN parts that provide information about architecture and/or tools needed to resolve them, and as such provide a strong constraint to the generality and useful lifespan of the address. On the other hand, ALL the other URI do not contain architecture-dependent information, and can survive arbitrarily radical modification in the tools provided to access them. This is, in my point of view, absolutely good.

I would be strongly against using http-based absolute URIs for Akoma Ntoso, as this would imply providing a specific resolution engine and blessing for all time as the only one allowed to provide an interpretation of the actual meaning of the URI. This is not the right way to provide long-lasting, multi-national solutions to these problems. For different reasons, I would be strongly against using urn-based absolute URIs, as we would gain nothing in terms of flexibility and generality, and would loose much in terms of usability and compatibility of the addresses. I believe that the only reasonable choice is to go with global URIs, that have the same characteristics as http-based absolute URIs except the address of the resolution engine, that needs to be provided from the context of use.

As Roger mentioned during the call, this leaves an open issue as to where to place the missing context-dependent bits, e.g., the domain name of the resolution engine, since they are necessary to make the system work, yet are impermanent and may change over time and jurisdictions and even personal tastes. The answer, as I tried to explain, has to be found in the context of use: this is never empty. Even in situations where we have no document server, where the XML document has been transmitted as an attachment via mail, or found in a  USB thumbdrive, the context-dependent set of tools is never empty: at the very least there must be an XSLT stylesheet to convert AKoma Ntoso into aX(HTML). This is where the domain name of the resolution engine, as well as any additional information regarding the context of use of the document, need to reside. Putting this kind of information in the document is wrong and temporally restricting.

Putting ONE additional line in the XSLT stylesheet, as follows:

<xsl:template match="akomaNtoso">
       <base href="http://www.resolution.com/";  />

is more than adequate for the task and does NOT pollute the XML file with context-dependent information.

I hope this satisfies you all.






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"


Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
Palazzo Dal Monte Gaudenzi - Via Galliera, 3
Tel +39 051 277217
Fax +39 051 260782

5 per mille all'Università di Bologna - C.F.: 80007010376

Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell’ente.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]