OASIS LegalDocumentML (LegalDocML) TC

"Parochial" as in narrow...but unduly local might also fit...knucklehead is a US epithet referring to someone who does something foolish...

Perhaps a Google hangout or Skype or other phone conference might be helpful on this subject, compared to this email thread. Again, I liked Monica showing one example of an instantiation of something into AKN. However, it would be helpful to me and perhaps other to see the California and/or other jurisdiction have each possible document mapped to AKN types. Fabio has a good written explanation, but to go one step forward with the AKN example would help me. This points out the problems of semantics overtaking the object naming which could allow representations in element and attribute to be more difficult than needed, perhaps. Daniel On 2/11/2013 9:10 AM, Aisenberg, Michael A. wrote: "Parochial" as in narrow...but unduly local might also fit...knucklehead is a US epithet referring to someone who does something foolish...
Original Message------ From: McGibbney, Lewis John To: Mr Michael Aisenberg To: 'fabio@cs.unibo.it' To: 'legaldocml@lists.oasis-open.org' Subject: RE: [legaldocml] Acts and bills Sent: Feb 11, 2013 03:53 Hi Michael, You find the conversation parochial because it refers in some sense to a church parish or because it is narrow in its scope and views? I assume it has to be one of the two. I am not quite getting you here! What are knuckleheads? In line with this thread, I am not familiar with the terminology. Lewis ________________________________________ From: legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] On Behalf Of Aisenberg, Michael A. [maisenberg@mitre.org] Sent: 11 February 2013 03:03 To: 'fabio@cs.unibo.it'; 'legaldocml@lists.oasis-open.org' Subject: Re: [legaldocml] Acts and bills I find this discussion frighteningly parochial. Fear of deferring to the U.S. Federal construct, which has been settled since the first edition of Jefferson's Manual, seems to be creating an unnecessary tempest. The distinction is entirely procedural and depends on the instrument's posture in the process. The term "bill" has since the Second Session of the First U.S. Congress referred to any writing seeking to become an element of the U.S. Statutory system ("Public "Laws") properly introduced into one of the two houses of Congress. In its introduced form, it may (and now commonly does) adopt the style and caption of the form it will have if passed--that is, it refers to itself as an "Act"...BUT IT IS NOT an "ACT" until passed by both houses (at which point it is No Longer a "bill") and sent to the President for his signature, at which point, the Act will become Michael Aisenberg. Sent from handheld. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

  Here is House Resolution 5 from this year's session in California: http://leginfo.ca.gov/pub/13- 14/bill/asm/ab_0001-0050/hr_5_ bill_20130204_amended_asm_v98. pdf     It simply commemorates the 100th anniversary of Rosa Parks' birth. It is obvious that it proposes no law. Nonetheless, it is an official document of the California Assembly. It was adopted on February 4th. It is not now a Statute and will not be entered into the Statutes of 2013. It is merely a statement honoring a great American.   Here is Senate Concurrent Resolution 1 from this year's session in California:   http://leginfo.ca.gov/pub/13- 14/bill/sen/sb_0001-0050/scr_ 1_bill_20121206_chaptered.pdf   It simply re-designates Diane Boyer-Vine as Leg. Counsel for this session. Again, it is proposing no law. It passed and was entered into the "Resolution Chapters" for this session. It does this by virtue of being a Concurrent Resolution which was passed by both houses.   Here is Assembly Constitutional Amendment 1 from this year's session in California:   http://leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/aca_1_bill_20121203_introduced.pdf   It proposes an amendment to the people of California to amend the constitution relating to the powers of the Legislature. It clearly limits how the Legislature may make law and specify how agencies that have delegated law making powers answer back to the legislature. If it is adopted, it will be chaptered as a "Resolution Chapter" rather than in the regular statutes of 2013.   In the jurisdictions I have worked thus far:   1. A Resolution is a formal written motion taken up by a legislature 2. A Non-Binding Resolution expresses an opinion of the legislature or takes up some other matter not related to creating law. It will not become law if adopted. It does not become an act and is not referred to as a statute.  Sometimes a Non-Binding Resolution is simply called a Resolution. 3. A "binding" resolution is known as a Bill (In the US House, a Joint Resolution is also a "binding" form of a resolution in most cases) A Bill proposes law and will become law if adopted. 4. Another type of motion is an Amendment. Its purpose is to amend a Bill or Resolution currently being considered. 5. A Constitutional Amendment is not an Amendment in the same sense. It is instead a Resolution and results in a proposition to the people that must be passed in order to enter into law. At the US Federal level, it is a Joint Resolution that requires ratification of the states in order to become law. In some respects, a Constitutional Amendment straddles the line between a bill and a resolution and falls one way or the other depending on the jurisdiction. 6. A Bill that is adopted becomes an Act when it is promulgated (I think). It is also referred to as a Statute. 7. A Non-Positive Law Title of the US Code is not enacted, was never a Bill, and thus is not, in itself, Law. It is not an Act.   In Akoma Ntoso, there exists tags for motions that are Bills and Amendments and for Bills that have gone on to become Acts. Unless I am very much mistaken, there exists no tags for Resolutions (#2 above) other than Bills or non-authoritative representations of the law (#7 above). Arguing that the terms "bill" and "act" are simply metonymies for broad concepts of document asks that the established meanings, sometimes defined in stone in the Constitutions, be relaxed. This seems unlikely to be acceptable in many situations.   Let me give a counter-example to make my point. Imagine the argument were not about the word act but was instead about the word statute. That word could just as easily have been selected as the term for the general concept of a law. Go back and look at ACR 1 above. It's clearly granting powers using a clearly defined meaning for the word statute just as it is clearly using the word bill. it is not for us to tamper with those meanings. It has been my experience that being sensitive to the established meaning of these words and concepts is a requirement.   It is important that the models we adopt be sufficiently accurate and comprehensive to correctly portray how a legislature views their legislation. In my job, I perform a document analysis. I echo back what the drafters at the legislature teach me as a taxonomy which is then mapped into a schema. If that schema does not fit or it appears I am force fitting terms to tags in ways that are tortured and require suspending disbelief to accept, then my credibility and the credibility of the technologies I suggest is put on the line.   -Grant     On Mon, Feb 11, 2013 at 6:35 AM, Daniel Bennett < daniel@citizencontact.com > wrote: Perhaps a Google hangout or Skype or other phone conference might be helpful on this subject, compared to this email thread. Again, I liked Monica showing one example of an instantiation of something into AKN. However, it would be helpful to me and perhaps other to see the California and/or other jurisdiction have each possible document mapped to AKN types. Fabio has a good written explanation, but to go one step forward with the AKN example would help me. This points out the problems of semantics overtaking the object naming which could allow representations in element and attribute to be more difficult than needed, perhaps. Daniel On 2/11/2013 9:10 AM, Aisenberg, Michael A. wrote: "Parochial" as in narrow...but unduly local might also fit...knucklehead is a US epithet referring to someone who does something foolish...
Original Message------ From: McGibbney, Lewis John To: Mr Michael Aisenberg To: ' fabio@cs.unibo.it ' To: ' legaldocml@lists.oasis-open. org ' Subject: RE: [legaldocml] Acts and bills Sent: Feb 11, 2013 03:53 Hi Michael, You find the conversation parochial because it refers in some sense to a church parish or because it is narrow in its scope and views? I assume it has to be one of the two. I am not quite getting you here! What are knuckleheads? In line with this thread, I am not familiar with the terminology. Lewis ______________________________ __________ From: legaldocml@lists.oasis-open. org [ legaldocml@lists.oasis-open. org ] On Behalf Of Aisenberg, Michael A. [ maisenberg@mitre.org ] Sent: 11 February 2013 03:03 To: ' fabio@cs.unibo.it '; ' legaldocml@lists.oasis-open. org ' Subject: Re: [legaldocml] Acts and bills I find this discussion frighteningly parochial. Fear of deferring to the U.S. Federal construct, which has been settled since the first edition of Jefferson's Manual, seems to be creating an unnecessary tempest. The distinction is entirely procedural and depends on the instrument's posture in the process.  The term "bill" has since the Second Session of the First U.S. Congress referred to any writing seeking to become an element of the U.S. Statutory system ("Public "Laws") properly introduced into one of the two houses of Congress.  In its introduced form, it may (and now commonly does) adopt the style and caption of the form it will have if passed--that is, it refers to itself as an "Act"...BUT IT IS NOT an "ACT" until passed by both houses (at which point it is No Longer a "bill")  and sent to the President for his signature, at which point, the Act will become Michael Aisenberg. Sent from handheld. ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php -- ____________________________________________________________________ Grant Vergottini Xcential Group, LLC. email: grant.vergottini@xcential.com phone: 858.361.6738

Dear Grant, Ok, I fear that writing essays rather than messages is just too much for anyone to bear. So here is my actual proposal, short and to the point: 1) Shall we be content with the addition of a new document type, meant to represent documents that have an official status, are officially approved and/or endorsed by an authority, but have NO normative content? 2) Is ONE new document type enough, or do we need to distinguish drafts being discussed within the assembly from final things formally approved and published by the official body? 3) Would the content model be as ample as possible, namely OpenStructure, or do you foresee and restriction in the allowed elements? 4) Would the name "resolution" fit for this new document type? Veronique, would it fit your needs? I fear that, since California uses the term "resolution" for non-normative content, while the European Parliament has normative content in, we should not use this name. If so, can someone propose an alternative? 5) Do we need to add a name attribute to bill and act, where one can specify the actual name of the draft/approved legislative document, such as statute or executive order etc.? 6) Can we keep the name attribute as optional, so that plain old bills and acts can still be called bill and act without further specification unless so desired? Thanks Fabio Il giorno 12/feb/2013, alle ore 00.26, Grant Vergottini ha scritto: > > Here is House Resolution 5 from this year's session in California: > http://leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/hr_5_bill_20130204_amended_asm_v98.pdf > > It simply commemorates the 100th anniversary of Rosa Parks' birth. It is obvious that it proposes no law. Nonetheless, it is an official document of the California Assembly. It was adopted on February 4th. It is not now a Statute and will not be entered into the Statutes of 2013. It is merely a statement honoring a great American. > > Here is Senate Concurrent Resolution 1 from this year's session in California: > > http://leginfo.ca.gov/pub/13-14/bill/sen/sb_0001-0050/scr_1_bill_20121206_chaptered.pdf > > It simply re-designates Diane Boyer-Vine as Leg. Counsel for this session. Again, it is proposing no law. It passed and was entered into the "Resolution Chapters" for this session. It does this by virtue of being a Concurrent Resolution which was passed by both houses. > > Here is Assembly Constitutional Amendment 1 from this year's session in California: > > http://leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/aca_1_bill_20121203_introduced.pdf > > It proposes an amendment to the people of California to amend the constitution relating to the powers of the Legislature. It clearly limits how the Legislature may make law and specify how agencies that have delegated law making powers answer back to the legislature. If it is adopted, it will be chaptered as a "Resolution Chapter" rather than in the regular statutes of 2013. > > In the jurisdictions I have worked thus far: > > 1. A Resolution is a formal written motion taken up by a legislature > 2. A Non-Binding Resolution expresses an opinion of the legislature or takes up some other matter not related to creating law. It will not become law if adopted. It does not become an act and is not referred to as a statute. Sometimes a Non-Binding Resolution is simply called a Resolution. > 3. A "binding" resolution is known as a Bill (In the US House, a Joint Resolution is also a "binding" form of a resolution in most cases) A Bill proposes law and will become law if adopted. > 4. Another type of motion is an Amendment. Its purpose is to amend a Bill or Resolution currently being considered. > 5. A Constitutional Amendment is not an Amendment in the same sense. It is instead a Resolution and results in a proposition to the people that must be passed in order to enter into law. At the US Federal level, it is a Joint Resolution that requires ratification of the states in order to become law. In some respects, a Constitutional Amendment straddles the line between a bill and a resolution and falls one way or the other depending on the jurisdiction. > 6. A Bill that is adopted becomes an Act when it is promulgated (I think). It is also referred to as a Statute. > 7. A Non-Positive Law Title of the US Code is not enacted, was never a Bill, and thus is not, in itself, Law. It is not an Act. > > In Akoma Ntoso, there exists tags for motions that are Bills and Amendments and for Bills that have gone on to become Acts. Unless I am very much mistaken, there exists no tags for Resolutions (#2 above) other than Bills or non-authoritative representations of the law (#7 above). Arguing that the terms "bill" and "act" are simply metonymies for broad concepts of document asks that the established meanings, sometimes defined in stone in the Constitutions, be relaxed. This seems unlikely to be acceptable in many situations. > > Let me give a counter-example to make my point. Imagine the argument were not about the word act but was instead about the word statute. That word could just as easily have been selected as the term for the general concept of a law. Go back and look at ACR 1 above. It's clearly granting powers using a clearly defined meaning for the word statute just as it is clearly using the word bill. it is not for us to tamper with those meanings. It has been my experience that being sensitive to the established meaning of these words and concepts is a requirement. > > It is important that the models we adopt be sufficiently accurate and comprehensive to correctly portray how a legislature views their legislation. In my job, I perform a document analysis. I echo back what the drafters at the legislature teach me as a taxonomy which is then mapped into a schema. If that schema does not fit or it appears I am force fitting terms to tags in ways that are tortured and require suspending disbelief to accept, then my credibility and the credibility of the technologies I suggest is put on the line. > > -Grant > > > > > On Mon, Feb 11, 2013 at 6:35 AM, Daniel Bennett <daniel@citizencontact.com> wrote: > Perhaps a Google hangout or Skype or other phone conference might be helpful on this subject, compared to this email thread. Again, I liked Monica showing one example of an instantiation of something into AKN. However, it would be helpful to me and perhaps other to see the California and/or other jurisdiction have each possible document mapped to AKN types. Fabio has a good written explanation, but to go one step forward with the AKN example would help me. > > This points out the problems of semantics overtaking the object naming which could allow representations in element and attribute to be more difficult than needed, perhaps. > Daniel > > > > On 2/11/2013 9:10 AM, Aisenberg, Michael A. wrote: > "Parochial" as in narrow...but unduly local might also fit...knucklehead is a US epithet referring to someone who does something foolish... >
Original Message------ > From: McGibbney, Lewis John > To: Mr Michael Aisenberg > To: 'fabio@cs.unibo.it' > To: 'legaldocml@lists.oasis-open.org' > Subject: RE: [legaldocml] Acts and bills > Sent: Feb 11, 2013 03:53 > > Hi Michael, > You find the conversation parochial because it refers in some sense to a church parish or because it is narrow in its scope and views? I assume it has to be one of the two. > I am not quite getting you here! > What are knuckleheads? In line with this thread, I am not familiar with the terminology. > Lewis > > ________________________________________ > From: legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] On Behalf Of Aisenberg, Michael A. [maisenberg@mitre.org] > Sent: 11 February 2013 03:03 > To: 'fabio@cs.unibo.it'; 'legaldocml@lists.oasis-open.org' > Subject: Re: [legaldocml] Acts and bills > > I find this discussion frighteningly parochial. > Fear of deferring to the U.S. Federal construct, which has been settled since the first edition of Jefferson's Manual, seems to be creating an unnecessary tempest. > The distinction is entirely procedural and depends on the instrument's posture in the process. The term "bill" has since the Second Session of the First U.S. Congress referred to any writing seeking to become an element of the U.S. Statutory system ("Public "Laws") properly introduced into one of the two houses of Congress. In its introduced form, it may (and now commonly does) adopt the style and caption of the form it will have if passed--that is, it refers to itself as an "Act"...BUT IT IS NOT an "ACT" until passed by both houses (at which point it is No Longer a "bill") and sent to the President for his signature, at which point, the Act will become > Michael Aisenberg. Sent from handheld. > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > -- > ____________________________________________________________________ > Grant Vergottini > Xcential Group, LLC. > email: grant.vergottini@xcential.com > phone: 858.361.6738 -- 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/

Dear Fabio, If it is really needed, we can add new document types for document containing non normative content, but then, I think we need to have a clear "universal" definition of what is a normative content and what is not a normative content and on which base the selection of the correct category is done in AkomaNtoso.  (I suppose that an attribute on the bill/act element with the value like "normative" / "nonNormative" is not enough ;-) ).  For example, is the rules of procedure of an institution normative or not ? If we do so, I think that we need two new document types, one for "draft/motion/proposal/..." and one for the document that is officially approved by an official body.  In the context of the Parliament, all these document have a structure like a bill or an act : preamble, body, annexes, but not so strict as legislation.  Sometimes, they have annexes that are bill (for exemple : Motion for a European resolution with recommendations to the Commission on setting up a legislation on a specific subject) "Resolution" is a specific type. Other are "decision" or "recommendation".  So I prefer to have a more general name.  But currently, I have no concret idea for the names. I think that an additional attribute could be interesting to store the type of official document as it is named in the country.  I don't know if the 'name' attribute is the good one or if an attribute like 'type' is better.    Kind regards   Véronique Parisse ________________________________________ De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de Fabio Vitali [fabio@cs.unibo.it] Date d'envoi : mardi 12 février 2013 10:05 À : Grant Vergottini Cc: legaldocml@lists.oasis-open.org Objet : Re: [legaldocml] Acts and bills Dear Grant, Ok, I fear that writing essays rather than messages is just too much for anyone to bear. So here is my actual proposal, short and to the point: 1) Shall we be content with the addition of a new document type, meant to represent documents that have an official status, are officially approved and/or endorsed by an authority, but have NO normative content? 2) Is ONE new document type enough, or do we need to distinguish drafts being discussed within the assembly from final things formally approved and published by the official body? 3) Would the content model be as ample as possible, namely OpenStructure, or do you foresee and restriction in the allowed elements? 4) Would the name "resolution" fit for this new document type? Veronique, would it fit your needs? I fear that, since California uses the term "resolution" for non-normative content, while the European Parliament has normative content in, we should not use this name. If so, can someone propose an alternative? 5) Do we need to add a name attribute to bill and act, where one can specify the actual name of the draft/approved legislative document, such as statute or executive order etc.? 6) Can we keep the name attribute as optional, so that plain old bills and acts can still be called bill and act without further specification unless so desired? Thanks Fabio Il giorno 12/feb/2013, alle ore 00.26, Grant Vergottini ha scritto: > > Here is House Resolution 5 from this year's session in California: > http://leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/hr_5_bill_20130204_amended_asm_v98.pdf > > It simply commemorates the 100th anniversary of Rosa Parks' birth. It is obvious that it proposes no law. Nonetheless, it is an official document of the California Assembly. It was adopted on February 4th. It is not now a Statute and will not be entered into the Statutes of 2013. It is merely a statement honoring a great American. > > Here is Senate Concurrent Resolution 1 from this year's session in California: > > http://leginfo.ca.gov/pub/13-14/bill/sen/sb_0001-0050/scr_1_bill_20121206_chaptered.pdf > > It simply re-designates Diane Boyer-Vine as Leg. Counsel for this session. Again, it is proposing no law. It passed and was entered into the "Resolution Chapters" for this session. It does this by virtue of being a Concurrent Resolution which was passed by both houses. > > Here is Assembly Constitutional Amendment 1 from this year's session in California: > > http://leginfo.ca.gov/pub/13-14/bill/asm/ab_0001-0050/aca_1_bill_20121203_introduced.pdf > > It proposes an amendment to the people of California to amend the constitution relating to the powers of the Legislature. It clearly limits how the Legislature may make law and specify how agencies that have delegated law making powers answer back to the legislature. If it is adopted, it will be chaptered as a "Resolution Chapter" rather than in the regular statutes of 2013. > > In the jurisdictions I have worked thus far: > > 1. A Resolution is a formal written motion taken up by a legislature > 2. A Non-Binding Resolution expresses an opinion of the legislature or takes up some other matter not related to creating law. It will not become law if adopted. It does not become an act and is not referred to as a statute.  Sometimes a Non-Binding Resolution is simply called a Resolution. > 3. A "binding" resolution is known as a Bill (In the US House, a Joint Resolution is also a "binding" form of a resolution in most cases) A Bill proposes law and will become law if adopted. > 4. Another type of motion is an Amendment. Its purpose is to amend a Bill or Resolution currently being considered. > 5. A Constitutional Amendment is not an Amendment in the same sense. It is instead a Resolution and results in a proposition to the people that must be passed in order to enter into law. At the US Federal level, it is a Joint Resolution that requires ratification of the states in order to become law. In some respects, a Constitutional Amendment straddles the line between a bill and a resolution and falls one way or the other depending on the jurisdiction. > 6. A Bill that is adopted becomes an Act when it is promulgated (I think). It is also referred to as a Statute. > 7. A Non-Positive Law Title of the US Code is not enacted, was never a Bill, and thus is not, in itself, Law. It is not an Act. > > In Akoma Ntoso, there exists tags for motions that are Bills and Amendments and for Bills that have gone on to become Acts. Unless I am very much mistaken, there exists no tags for Resolutions (#2 above) other than Bills or non-authoritative representations of the law (#7 above). Arguing that the terms "bill" and "act" are simply metonymies for broad concepts of document asks that the established meanings, sometimes defined in stone in the Constitutions, be relaxed. This seems unlikely to be acceptable in many situations. > > Let me give a counter-example to make my point. Imagine the argument were not about the word act but was instead about the word statute. That word could just as easily have been selected as the term for the general concept of a law. Go back and look at ACR 1 above. It's clearly granting powers using a clearly defined meaning for the word statute just as it is clearly using the word bill. it is not for us to tamper with those meanings. It has been my experience that being sensitive to the established meaning of these words and concepts is a requirement. > > It is important that the models we adopt be sufficiently accurate and comprehensive to correctly portray how a legislature views their legislation. In my job, I perform a document analysis. I echo back what the drafters at the legislature teach me as a taxonomy which is then mapped into a schema. If that schema does not fit or it appears I am force fitting terms to tags in ways that are tortured and require suspending disbelief to accept, then my credibility and the credibility of the technologies I suggest is put on the line. > > -Grant > > > > > On Mon, Feb 11, 2013 at 6:35 AM, Daniel Bennett <daniel@citizencontact.com> wrote: > Perhaps a Google hangout or Skype or other phone conference might be helpful on this subject, compared to this email thread. Again, I liked Monica showing one example of an instantiation of something into AKN. However, it would be helpful to me and perhaps other to see the California and/or other jurisdiction have each possible document mapped to AKN types. Fabio has a good written explanation, but to go one step forward with the AKN example would help me. > > This points out the problems of semantics overtaking the object naming which could allow representations in element and attribute to be more difficult than needed, perhaps. > Daniel > > > > On 2/11/2013 9:10 AM, Aisenberg, Michael A. wrote: > "Parochial" as in narrow...but unduly local might also fit...knucklehead is a US epithet referring to someone who does something foolish... >
Original Message------ > From: McGibbney, Lewis John > To: Mr Michael Aisenberg > To: 'fabio@cs.unibo.it' > To: 'legaldocml@lists.oasis-open.org' > Subject: RE: [legaldocml] Acts and bills > Sent: Feb 11, 2013 03:53 > > Hi Michael, > You find the conversation parochial because it refers in some sense to a church parish or because it is narrow in its scope and views? I assume it has to be one of the two. > I am not quite getting you here! > What are knuckleheads? In line with this thread, I am not familiar with the terminology. > Lewis > > ________________________________________ > From: legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] On Behalf Of Aisenberg, Michael A. [maisenberg@mitre.org] > Sent: 11 February 2013 03:03 > To: 'fabio@cs.unibo.it'; 'legaldocml@lists.oasis-open.org' > Subject: Re: [legaldocml] Acts and bills > > I find this discussion frighteningly parochial. > Fear of deferring to the U.S. Federal construct, which has been settled since the first edition of Jefferson's Manual, seems to be creating an unnecessary tempest. > The distinction is entirely procedural and depends on the instrument's posture in the process.  The term "bill" has since the Second Session of the First U.S. Congress referred to any writing seeking to become an element of the U.S. Statutory system ("Public "Laws") properly introduced into one of the two houses of Congress.  In its introduced form, it may (and now commonly does) adopt the style and caption of the form it will have if passed--that is, it refers to itself as an "Act"...BUT IT IS NOT an "ACT" until passed by both houses (at which point it is No Longer a "bill")  and sent to the President for his signature, at which point, the Act will become > Michael Aisenberg. Sent from handheld. > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > -- > ____________________________________________________________________ > Grant Vergottini > Xcential Group, LLC. > email: grant.vergottini@xcential.com > phone: 858.361.6738 -- 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/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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. -- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Thomas R. Bruce @trbruce Director, Legal Information Institute Cornell Law School http://www.law.cornell.edu/ @liicornell +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

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

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

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

On 2/12/13 8:17 AM, monica.palmirani wrote: 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? Does the subtype value take the local name?  Or is it a controlled vocabulary of abstract subtypes?  The problem that I think we have is that people will want to see the name they actually use for the thing somewhere.  So, if they decide for some misbegotten reason to call this particular type of document a binky , would it be <FRBRsubtype value= binky legalStatus= #non-normative > That is, of course, assuming that a binky is non-normative :).   And speaking of norms, there are an awful lot of folks on this TC that we haven't heard from yet, many of whom I know have a lot of experience with fieldwork and adoption processes.  Anyone?  (I'm lookin' at *you*, Laurel Shifrin :) ) t. -- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Thomas R. Bruce Director, Legal Information Institute Cornell Law School http://www.law.cornell.edu twitter: @trbruce +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Hi all, just for making my proposal clearer and not create more confusion: <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> <bill name= statement >--> name contains a controlled vocabulary value useful for interoperability purposes <FRBRsubtype value= resolution legalStatus= #non-normative >--> value contains a local name I am sure that some refinements are necessary on FRBR side, if you like this model but I am confident Fabio can do it. Yours, Monica Il 12/02/2013 17:03, Thomas R. Bruce ha scritto: On 2/12/13 8:17 AM, monica.palmirani wrote: 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? Does the subtype value take the local name?  Or is it a controlled vocabulary of abstract subtypes?  The problem that I think we have is that people will want to see the name they actually use for the thing somewhere.  So, if they decide for some misbegotten reason to call this particular type of document a binky , would it be <FRBRsubtype value= binky legalStatus= #non-normative > That is, of course, assuming that a binky is non-normative :).   And speaking of norms, there are an awful lot of folks on this TC that we haven't heard from yet, many of whom I know have a lot of experience with fieldwork and adoption processes.  Anyone?  (I'm lookin' at *you*, Laurel Shifrin :) ) t. -- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Thomas R. Bruce Director, Legal Information Institute Cornell Law School http://www.law.cornell.edu twitter: @trbruce +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ -- =================================== 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 ====================================

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

So you agree with me that draft is not a good term in substitution of bill ;-) By the way: what do you think about the following proposal? do you like it the term statement for representing resolution ? do you like the attribute legalStatus? <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> cheers, mp Il 12/02/2013 18:50, Grant Vergottini ha scritto: 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 -- =================================== 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 ====================================