Re: [legaldocml] RE : [legaldocml] Acts and bills

Monica, All,

Re: Draft Bills as used in the UK.

For what it is worth, the concept of a draft bill is quite common. In California (and elsewhere from what I have seen), all bills and resolutions start out life as a "draft". That is the proper term that describes them until they become bills or resolutions upon introduction. They flip from drafts to bills or resolutions just as bills will flip to be statutes when later chaptered and promulgated. Drafts are produced by the attorneys in the Office of the Legislative Counsel and have a "requestor" which may not be a legislator. Often the requestor represents a government agency as in the UK. In some cases the draft might be "shopped" around to find a sponsoring legislator to introduce it in one of the houses. The "author" is a legislator and is the document's sponsor. The author is not the "drafter" and may not be the "requestor". Many more drafts exist than ever go on to become actual resolutions and bills. California does not publish drafts - they are protected by client attorney privilege between the OLC and the requestor.

Drafts are drafted as bills and resolutions because that is the form they take the first time they will be formally published. This decision would likely differ if they were to be released prior to introduction, as appears to be the case recently in the UK -- And no, I am not begging for another tag ;-)

Another point worth noting. Drafts are amended informally. Bills and Resolutions take an Amending Motion (an AKN amendment) to change. Statutes (including codes) take an Amending Bill to change. The terminology I am using is partly from Hong Kong as their concepts are the same as California, but they're more specific in their naming. Their name for a Statute is an Ordinance however - as they're a city state.

-Grant

On Tue, Feb 12, 2013 at 5:17 AM, monica.palmirani <monica.palmirani@unibo.it> wrote:

Dear all,
first of all thanks for this brainstorming.

Following some suggestions and hints I would like to provide a very practical and concrete proposal for managing the good issues arisen by Grant.

First of all the term "resolution" is it not a good term because we have other important institutions that use the SAME term in a very different way:
UN resolution http://www.un.org/ga/search/view_doc.asp?symbol= A/RES/66/279; administrative resolution;
European Council resolution;
EU parliament resolution http://www.europarl.europa.eu/sides/getDoc.do?type=TA&language=EN&reference=P7-TA-2012-386.
I think it is important to find a solution where everybody could be comfortable.
"Statement" is a good alternative to "resolution".

Second I would like to split the problems. From my point of view there are three parameters involved in the discussion:

•    Normative/non-normative legal document (e.g. resolution could be non-normative)
•    Official/non-official legal document (e.g. non-positive title of the code is non-official)
•    Draft/Approved (e.g. bill in UK is a draft bill presented officially to the Parliament following a specific protocol - by the way draft-bill is a particular type of document in UK - see http://www.parliament.uk/about/how/laws/draft/).

These three parameters are more or less what Grant need to distinguish. We have at the end these types to manage:
- draft, resolution, non-normative, official
- draft, resolution, normative, official
- approved, resolution, non-normative, official
- approved, resolution, normative, official
- code non-normative unofficial
- code normative official
- amendment, non-normative, official
- etc.

These parameters are mostly metadata and some of them need interpretation.
The duplication of doc type it is a design chose quite in contrast with the Akoma Ntoso pattern oriented principle.

See my proposal below:

Case 1: draft resolution non-normative official
<bill name="statement">
<FRBRWork>
                    <FRBRthis value="/us/bill/resolution/2008-12-19/23/main"/>
                    <FRBRuri value="/us/bill/resolution/2008-12-19/23/main"/>
                    <FRBRdate date="2008-12-19" name="Generation"/>
                    <FRBRauthor href="" as="#author"/>
                    <FRBRsubtype value="resolution" legalStatus="#non-normative">
                    <FRBRcountry value="us"/>
                    <FRBRnumber value="23"/>
</FRBRWork>

Case 2: - code non-normative unofficial

<documentCollection name="code">
<FRBRWork>
                    <FRBRthis value="/us/bill/resolution/2008-12-19/23/main"/>
                    <FRBRuri value="/us/bill/resolution/2008-12-19/23/main"/>
                    <FRBRdate date="2008-12-19" name="Generation"/>
                    <FRBRauthor href="" as="#editor"/>
                    <FRBRsubtype value="resolution" legalStatus="#non-normative">
                    <FRBRcountry value="us"/>
                    <FRBRnumber value="23"/>
</FRBRWork>

In brief:

add name with a list of abstract values: code, statement

use <FRBRsubtype value="resolution" legalStatus="#non-normative">

add new attribute legalStatus

bill means draft and act means approved

<FRBRauthor href="" as="#editor"/> gives the authoritativeness of the document and how is the "father".

What do you think about this?

Yours,
Monica

Il 12/02/2013 13:42, Thomas R. Bruce ha scritto:

Folks:

Regrettably, I will not be able to attend tomorrow's meeting because of some urgent family business. I did want to weigh in again on this question of nomenclature. I agree with Fabio that it is important for us to come to agreement and move on so as not to imperil the process of adoption where it is already underway. Unfortunately, though, we face a situation where the target audience for new adoptions is much more diverse in its use of nomenclature than we anticipated, and no less insistent on its importance than the creators of the original standard. I agree with Grant that, if we want adoption, we must defer to local usages. The first piece of advice I ever got on doing client presentations was, "Don't present with made-up data, and never show a client field names they won't recognize".   It still holds. There is, in the United States, a popular diet called the "South Beach Diet" (don't know if it's made it abroad yet).   Its creators say that it isn't a very good diet, scientifically, except in one respect: it is the only diet that people will actually follow. That, it seems to me, is our situation.

I do think we could settle the matter by proliferating attributes/properties a little. I would suggest the use of two attributes, abstract-type and localname, to resolve the difference. So, perhaps instead of documentType, just <document abstract_type="(set of abstract types)" localname="eg. non-binding resolution">. I do think there needs to be some expansion of the set of abstract types. Alternatively, one might just add an additional "localname" attribute to the documentType element.

Fabio will not find this a useful remark, but I think that part of what we're seeing here is a problem with the general idea of having specific element names designed to meet an original set of needs that has vastly expanded with more widespread adoption across multiple jurisdictions. Just as with the naming of hierarchical levels, I continue to prefer a more flexible approach that uses a generic element name such as "document" or "level" and supplements/specifies more narrowly with attributes such as "n" (for level number) and "localname" for whatever the legislature/body in question calls the thing when they're all at home around the dinner table.   I find this to be a much cleaner and more flexible approach than proliferating element names. I expect that won't be a popular view, especially this late in the game, but we do have a problem with name recognition by adopters and it will continue to grow with the scope of adoption.

All the best,
Tb.

-- =================================== 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 ====================================

--
____________________________________________________________________
Grant Vergottini
Xcential Group, LLC.
email: grant.vergottini@xcential.com
phone: 858.361.6738

legaldocml message