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
- From: carlo.marchetti@senato.it
- To: legaldocml@lists.oasis-open.org
- Date: Tue, 12 Feb 2013 15:58:58 +0100
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 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
====================================
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]