Re: [legaldocml] FRBR and legislation

[Fabio Vitali <fabio@CS.UniBO.IT>]

Dear Tom, 

>> I fear you have a dreamy and unjustified admiration for the legislative process in Europe. At least in Italy, this is just as messy and chaotic as you describe yours. We have Frankenbills (I love the term, and will use it as often as I can), we have reconciliation of separate bills, we have multi-topical bills, we have simultaneous versions of the same document. We have found a way to use/coerce/rape FRBR to deal with these situations.
> This gets to the heart of my ultimate concern.  Why go to the trouble of coercion?  What does a legislative document standard gain from the incorporation of FRBR concepts?  I've never really grasped how it helps us in any practical way.  It gives librarians,  who are in love with it, something they can relate to. But I am not sure how it increases the power, expressiveness, or usability of a standard.
> 
> Although as usual I have to confess to some confusion of my own.  I'm working on a project that mostly involves modeling legislative document metadata.  That's  intextricably linked to XML encoding standards, because the most practical source of the metadata will no doubt be extraction from XML, so that one would want the XML documents to contain whatever values are needed, marked up in a useful way.  But RDF gives us a way to much more expressively talk about legislative documents and their various relationships to one another (versioning or otherwise), in ways that could (for example) be tied to legislative events and so on.  On that view, FRBR relationships are a kind of selection or mapping of a more extensive collection of document relationships that are much more closely conceptually and practically related to legislation (in other words, we do the coercion by mapping or querying).   Anyway, trying to keep my head in both worlds is difficult, and it makes it if anything more confusing to think about what we gain by talking about FRBR when we're down on the bare metal of the legislation itself.
> 
> This is not me being snarky; it's me asking an honest question: What does FRBR get us?

I will first start with the weakest argument I have in my panoply, argumentum ad auctoritatem. Not only Akoma Ntoso, NormeInRete, CEN Metalex, Lex Brazil, and URN:Lex explicitly use FRBR, but also ELI (http://legalinformatics.files.wordpress.com/2012/03/st17554-en11.pdf ), although never mentioning FRBR, distinguish between Work-level, Expression-level and Manifestation-level URIs, and even the UK in legislation.gov.uk distinguishes between identifier URIs, document URIs and representation URIs (http://www.legislation.gov.uk/developer/uris ), which are a rather transparent renaming of Work-level, Expression-level and Manifestation-level URIs respectively. But of course recurring to authorities (especially since I have been involved or personally know the people involved in about half of them) will hardly make me gain points. 

The second argument is stronger, as it is functional: I here list a series of four required functions that any conceptual model for legislative documents should provide, and show that FRBR does, in fact, provide them. 

The first requirement is of course that we need permanent URIs for legal documents. This by the way means that references in legal texts should NEVER point to physical files in a specific repository under a specific filename. Distinguishing between an abstract idea of the destination document and its concrete representation as a computer file allows us to accommodate technological evolutions to our systems, tools and files without a corresponding complete redesign of our referencing mechanisms. Also, as soon as you separate physical addresses of files (URLs) from conceptual addresses of documents (permanent URIs) you find you need a resolution engine that converts the permanent URI of the document you are requesting into the ephemeral URL of the physical file that today is the best match to the document you are requesting. Such resolvers are NECESSARY immediately. 

The second requirement is the management with equivalent ease of both dynamic and static references. Some legal documents make references that are static, i.e. refer to only and only one version of the legal document referenced: for instance, amendments and modification acts affect only a very specific version of the bill or act, and similarly an argument in a judgment is usually based on a specific version of an act, which could subsequently change without affecting the correctness of the judgment itself. Other documents make dynamic references, which means that the specific version they refer to may depend on the time of the request or the context in which the request was made: for instance, a reference to legislations needs to bring you to the current version of the act, or, more often, to the version of the act that was in force at the time of the legal fact that you need to evaluate. One may decide that we are talking about two different XML elements (e.g., <dynamicRef href="..."> and <staticRef href="...">). My opinion, on the other hand, is that we are talking about two different types of references, that need to be expressed with different URIs, not different XML elements. So we need to distinguish between references to a specific version of the document and references to ALL/ANY existing version of the document, among which we will choose case by case the specific version that is relevant to our needs. 

The third requirement is that we are able to express correctly different nuances about authorship of a document. For instance it is the case in Italy (and I believe in many other countries, including the US) that the official promulgation of an act meant to amend and extend a code is often NOT accompanied by the resulting new version of the code itself, but that the actual codification is left as an exercise to the reader. This means that the actual new versions of the codes are created editorially, possibly by a public office or by private publishers. In these cases, who are we to assume as the "author of the text"? The "legislator" is the author of the code, but it is not the author of the specific codification resulting from the application of a new act, as such codification is not authoritative, so it must be someone/something else, i.e, the office or the private publisher in charge of this operation. Who is then the author of the markup of the XML document? It should be yet someone else, because the legislator does not promulgate XML markup, and most probably the legal experts of the private publisher know very little of legislative markup. So we need a third character, the author of the markup, for that responsibility. So we have at least three different "authors" for the same document. We need a way to express that. 

The fourth requirement is that navigation between legal documents can be established within a specific context, so that I do not have to specify it after every navigation step. Suppose for instance that I choose to read the German version of an European act as it was in force on May 17th, 2011 (because the legal fact I am examining happened on that date), and that I particularly appreciate the Akoma Ntoso version of it even though the system could provide me with PDF versions as well. Then every time I click on a reference to another piece of legislation, I would appreciate to be sent to the German version that was in force on May 17, 2011 in Akoma Ntoso, rather than being sent to some default version (e.g., current version in English, ask if PDF or XML) and require me to disentangle myself from the intricate sets of options you offer. This means that there must be a way for me to provide a rich set of requirements directly in the request for a document, rather than making a generic request and have the system provide a question/answer session to determine, time and again, which specific version to provide me with. 

So my point is that FRBR does satisfy all of these requirements, by providing a reasonable conceptualization of the different ideas of documents that we routinely used interchangeably, creating confusion and misunderstandings. We have abstract documents, called Works, with their own URIs. We have specific versions/variants for each Work, called Expressions, with their own URIs. We have specific representations of each Expression in computer format, called Manifestations, with their own URIs. We finally have physical files, that contain a byte-by-byte identical copy of some Manifestation, called Item, with their own URLs. Resolution is the process of identifying the best Item-level URLs that matches the Work-, Expression- or Manifestation-level URI you requested. It works. 

As a side note, I really do not understand why using FRBR or not should be relevant to the technique you are using and the use of RDF. In fact, FaBiO (don't ask!),  http://purl.org/spar/fabio/ , is an OWL 2 ontology providing support for RDF assertions describing bibliographic facts using FRBR terms and concepts. FRBR is very much expressible in RDF terms and it is by no mean in contrast with Semantic Web technologies. 

I hope this clarifies a bit things. 

Ciao

Fabio  

--

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/