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: Rif: Re: [legaldocml] RE : [legaldocml] Acts and bills

Dear all,
just to quickly inform you that we plan to publish every "law proposal" as an akoma ntoso "bill" type of document, independently from the proposer type.
We plan to publish these documents by the end of this month on the Italian Senate website, so to allow You all to check our work and propose suggestions/improvements.

As for the "act" akoma ntoso type of document, we think this is appropriate for >published< laws, i.e. law proposals approved by the Parliament, promulgated by the President of the Republic, and finally published in the Official Gazette.

Best regards,
Carlo Marchetti

Carlo Marchetti, PhD
Head of Information Systems Development Office
Senato della Repubblica Italiana
tel. 0667064581
fax. 0667063495
email: carlo.marchetti@senato.it

Da:        monica.palmirani <monica.palmirani@unibo.it>
Per:        <legaldocml@lists.oasis-open.org>
Data:        12/02/2013 14.17
Oggetto:        Re: [legaldocml] RE : [legaldocml] Acts and bills
Inviato da:        <legaldocml@lists.oasis-open.org>

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

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">
                   <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"/>

Case 2: - code non-normative unofficial

<documentCollection name="code">
                   <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"/>

In brief:
What do you think about this?


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


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,

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

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