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

[monica.palmirani <monica.palmirani@unibo.it>]

sorry some typos the second example:
Case 2: - code non-normative unofficial

<documentCollection name="code">
<FRBRWork>
                    <FRBRthis value="/us/code/2008-12-19/34/main"/>
                    <FRBRuri value="/us/code/2008-12-19/34/main"/>
                    <FRBRdate date="2008-12-19" name="Generation"/>
                    <FRBRauthor href="" as="#editor"/>
                    <FRBRsubtype value="code" legalStatus="#non-normative">
                    <FRBRcountry value="us"/>
                    <FRBRnumber value="34"/>
</FRBRWork>
Il 12/02/2013 14:17, monica.palmirani ha scritto:

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

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