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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalcitem message

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


Subject: RE: [legalcitem] Prolegomena to the constitution of subcommittees [UNCLASSIFIED]


Hi Fabio,

First allow me to introduce myself. I'm a member of the ELI task force but in my day job I work for the UK National Archives as part of the team responsible for the http://www.legislation.gov.uk  website. So as well as representing ELI I can also, as necessary, speak on behalf of http://www.legislation.gov.uk  URIs/versioning and the UK Crown Legislation Mark-up Language (CLML), which also provides a mechanism for marking-up citations (both mentioned in relation to the extended charter). 

I support the proposed suggestions on subcommittees and I agree that it would be good to extract any useful concepts from existing standards already available rather than reinventing the wheel. I wonder if it would also be valuable to consider not just what standards are already out there but which are in use and why - is it a matter of convention or are there features that make some more readily useable?

Additionally, I'd just like to clarify John Dann's comments regarding ELI. I agree that the FRBR model is a valuable conceptual model, indeed the URI structure of  http://www.legislation.gov.uk is based on it. ELI is also intending to be an implementation of the FRBR model it's not suggesting an improvement. I don't want to dive into too much detail but the issue is that for official legislation publishers there is particular significance to distinguishing between consolidated and non-consolidated expressions. In view of this ELI has tried to provide explicit labels for these. The labels appear slightly contradictory to the usual FRBR terminology but the concepts are entirely consistent.

Kind regards,


Catherine Tabone

Data Manager
Legislation Services
The National Archives, Kew, Richmond, Surrey TW9 4DU

+44 (0)20 8392 5330 ext. 2233
catherine.tabone@nationalarchives.gsi.gov.uk
www.legislation.gov.uk | www.nationalarchives.gov.uk




-----Original Message-----
From: legalcitem@lists.oasis-open.org [mailto:legalcitem@lists.oasis-open.org] On Behalf Of Fabio Vitali
Sent: 20 February 2014 16:45
To: John Dann
Cc: legalcitem@lists.oasis-open.org
Subject: Re: [legalcitem] Prolegomena to the constitution of subcommittees

Dear John, 

>> Personal proposal for the definition of a few relevant terms to this TC:
>> * citation: an explicit, human-readable mention of a legal text as found in another text, providing sufficient detail for an averagely competent person to identify with precision the relevant text. 
>> * reference: a machine-readable representation of a citation, containing at least the same quantity of information (but possibly more) as the plain text citation for the purpose of identifying the relevant text.
>> * identifier: a string univocally associated to a document that identifies it. Using an identifier in a reference is a simple way to make it work, but it is not the only way: there will be references that do not contain an identifier, and require more work to find the relevant text.
>>  
>  
> Having an explicit human readable and machine readable does not mean that they have to be fare different from each other. It is important to have a machine readable which looks as close as possible to the human readable one. A unique identifier which should be used should be recognizable, readable and understandable by both humans and computers at the same time.
>  
> Meaning that somebody who knows how to cite a legal citation in a country, will almost be able to construct the "URI" which would lead you to the machine readable citation.

Completely agree. But I fear that technical constraints will make us inevitably compromise on this. Namely if, as I hope, we end up with choosing URIs, then the syntax of URIs will inevitably separate machine readable references from textual citations, maybe just a little bit, but we need to be ready for this. 

>>  Next are some standard Web terms that are relevant for this TC, I believe:
>> * A locator is an identifier of a physical resource (e.g., a file on a hard disk somewhere on the net) that is actionable (that is, it can be immediately used for dereferencing). 
>> * Resolution: the act of determining a usable, active locator of a physical resource given a reference to a document of which said physical resource is a reasonable representation.
>> * Dereferencing: the act of delivering a copy of a physical resource given its locator.
>>  
>  
> The ELI FBER model could give some ideas - abstract resource - legal resource - interpretation - format . You will notice that we have 4th layer has been added, the "abstract resource" being a new introduction, in comparison to the FBER model - work - expression -manifestation. On of the main aims of the "abstract resource" was to "link" with consolidated acts or even with other documents of other sources.
>  
> Simple example attached of the future Luxemburgish ontology.

I appreciate this effort, but I also have some doubts. 

FRBR (both in its original, ER version [1] and in its newer OO version [2] is a widely successful conceptual model for complex documental situations, tools and ontologies and models abound also outside of the narrow scope of legal documents, librarians use and accept it with joy, and we in Akoma Ntoso managed to use it quite successfully for all our documental needs. 

I'll confess that abandoning it in favor of a different conceptual model, either a superset of FRBR or a completely different model, will require some serious convincing on me. 

>> Accessing a document given a reference, therefore, has two well-distinguished steps: the reference is first resolved, obtaining a locator, and this locator is subsequently dereferenced, obtaining a representation of a physical copy of the document that is actually stored and available somewhere on the web.
>>  
>> Please note that I have abstained from using web-specific acronyms such as HTTP, URI, URL, and URN, because these concepts exist independently from their web implementation, but web standards and best practices are completely consistent with the above terminology.
>>  
> The Official journals are moving away from paper versions to officially online documents, some are even moving to "Legal Open Data". Having said that,  the http URIs become more and more important because almost all the documents are available online.

I am personally ALL IN FAVOR of an http only naming schema. I believe it to be the only way forward. Alternatively, I suggest we could go on with an abstract model that can be mapped equivalently on both http URIs, URNs as well as OpenURL [3] as I suggested a few years ago in [4].

>> * there could be many different physical copies of the same "document", some authoritative (e.g. from the web site of the office emanating it), some not so much (e.g., a union, a political party, a local administration giving access to their own personal stash of documents even when they are not the official publishers of these documents), some plain, some richer in metadata (e.g., a commented version provided by private publisher).
>  
> It is important to have an < official > source- official authority -  for a legal document, which the user can trust in. This authority has, of course, also to guaranty that the provided document is authentic, has not been altered etc.

Authoritativeness of the source is a matter of the resolution engine, not of the reference itself. The reference, in itself, must not indicate an origin, and points to an abstract idea of the document that may be represented in the best way by the copy at the authoritative server. But expecting that only authoritative storage are served by the URI is a way to force non-authoritative storage to piggyback on authoritative URIs and become indistinguishable from authoritative servers. Much better, in my view, is to support both authoritative and non-authoritative manifestation URIs, and have resolvers let the users decide on the resolution policies.  

>>  * there could be many variants of the same document differentiated by content (e.g., a full copy vs. an excerpt, maybe of a very long, multi-topical text, of the bits that are relevant to the activities of an office), by language (all European legislation exists in 27 different languages, and the citation to an European act that an Austrian friend sends me as taken from the German version, when I use it I see the right place of the Italian version), by temporal validity (a reference to a 1999 act subsequently modified in 2007, 2010 and 2013, if examined in 2014 for a civil suit about events in 2011, will bring me neither to the 1999 version, nor to the 2013 version, but to the 2010 version of the act).
>>  
> What the public, lawyers etc. want is the OFFICIAL version

My experience is completely opposite. Given the choice between the official, bare copy of an act from the official server, and a heavily commented and annotated copy of the same from a private publisher, possibly consolidated to the current version, I believe most of the users will definitely go for the commented one. 

>> * there could be citations to documents that are not accessible, available or even existing yet: e.g. a citation of a court document that will be released in a separate moment from the publication of a sentence, a citation of a document for which I have no security clearance, a citation of a regulation that will be written after the enactment of the legislation it is mentioned in, a citation of an act that it is foreseen it will modify existence, validity or jurisdiction of this one.
>>  
> Can we solve all cases ?

Hopefully yes. 

>> d) contracts: the purpose of this SC is to deliver, in a multinational, multi-language and multi-jurisdictional fashion, the features that characterize citations of contracts. These features should be clearly characterized in terms of identifying vs. accessory, required vs. desired, and describing the cited document vs. describing the citation.
>>  
> Not exactly what is meant by contracts - contracts between two businesses e.g. - if yes not sure this would be the place.

Yes. I believe contracts are in scope. Both private contracts between parties, not meant for publication, as well as standardized EULAs for sw licences and the like. 

>> e) technical SC: the purpose of this SC is to deliver one or more syntactical approaches to express the features of the above-mentioned citation types, so as to provide an easily implementable navigation system using standard browsing tool, as well as to determine behavior, response types and error handling of tools connected to the use of legal references, mainly how to characterize successful and unsuccessful resolution and dereferencing of legal references. 
>>  
>  
> Concerning a b c, I am not convinced that we need 3 sub-committees for each purpose. Legal documents are still quite similar, even if they come out of courts, the parliament or governments.

I wish you were right. My impression is that we have a reasonably good grasp of legislation, but are starting just to scratch the surface with court documents. We'll see if most sc will have an easy job, then. 


> If we want this identifier to work around the world, it is very important that this identifier or system is compatible with existing technological systems. Nobody will change completely their system to implement a new standard, but they will be willing to adapt slightly or add a layer to their existing systems.
>  
> A flexible, self-documenting, consistent and unique way to reference legislation across different legal systems is a need. But the magic word is flexible, because of the so many different legal systems in the world..
>  
> A flexible identifier would be a set of building blocks where each country, region ..., courts,  parliaments etc ... can take the bricks they need to uniquely identify their documents. There is no need to have a identical identifier everywhere, which by the way would be impossible.
>  
> Everybody takes its pieces of LEGO (child memories) and will build its 
> own identifier, but on a common and big (flexible) ground

Totally agree with you on this. 

Ciao

Fabio

--
>  

[1] http://archive.ifla.org/VII/s13/frbr/frbr1.htm
[2] http://www.cidoc-crm.org/frbr_inro.html
[3] http://www.niso.org/standards/z39-88-2004
[4] http://www.lri.jur.uva.nl/~winkels/legXMLAbstract.pdf


--

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/





---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

This email was received from the INTERNET and 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 organisation's IT Helpdesk. 
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
Please don't print this e-mail unless you really need to.

-----------------------------------------------------------------------------------

 
National Archives Disclaimer
 
This email and any files transmitted with it are intended solely for the use of the 
individual(s) to whom they are addressed. If you are not the intended recipient and 
have received this email in error, please notify the sender and delete the email. 
Opinions, conclusions and other information in this message and attachments that do 
not relate to the official business of The National Archives are neither given nor 
endorsed by it.


------------------------------------------------------------------------------------


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