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: RE:[legaldocml] Defining the work


Dear all,

For the first point


At first solution, my personal view is also to use the <documentCollection> to represent the volume.
So, each act is a work, but the entire volume is also a work.

The only point is how to represent the eventual structure of the volume ?

for example :

Subject 1 : blablabla
  • act 1
  • act 2
subject 2 : truc
subject 2.1 : tototo
  • act3
  • act 4
  • act 5
  • ...
With the current schema, the only way to represent it is to have a component for each item of the structure, containing an interstitial. (as a component can have an heading but must have also one and only one document I think)


For the second point

Fabio writes :
It is now a well-established opinion that bills and acts are separate works, and not expressions of the same work. This means that each act coming out of an omnibus bill is its own work, that has no FRBR connection with the bill it came out of. Non FRBR-relations between works, such as the ones between bills and acts, should be placed in the <references> section of the metadata, but no standard or recommended way has been suggested yet.

I would use a TLCReference element with a refersTo attribute to some TLCConcept such as "enactmentOf" (in acts, to refer to their bill) or "enactedAs" (in bills, to refer to their acts), or some such name.

For me also, "bill" and "act" are separate works. There are also different type of akomantoso documents.  They don't have the same "history" (passiveModification of a bill will never be a passiveModification of the corresponding act)


For the relation between the two, don't you think it is important to standardize the link type ?

suggestion :
put it in the <analysis> part of the metadata :
In <passiveModifications>, there is a <legalSystemMod>.
We can use the type "ratification" or add a new standard type like "enactment" ; "href" of source is the reference to the bill.

What do you think ?

Kind regards

Véronique


Véronique Parisse
AUBAY Luxembourg
Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251
www.aubay.com

________________________________________
De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de Fabio Vitali [fvitali@gmail.com]
Envoyé : mercredi 10 décembre 2014 11:20
À : Grant Vergottini
Cc : legaldocml@lists.oasis-open.org
Objet : Re: [legaldocml] Defining the work

Dear Grant,

my own view on this:


On 10/dic/2014, at 08:29, Grant Vergottini <grant.vergottini@xcential.com> wrote:

> Dear all,
>
> Two basic questions:
>
> 1) How should volumes which assemble many different independent works
> into a conceptual whole be modeled with respect to FRBR? I have many
> examples of this:
>
> a. The non-positive titles of the U.S. Code are not a single
> enactment (unlike the positive law titles which are). Rather they're
> an assemblage of acts, grouped by subject. Unfortunately, it's a bit
> worse than that simplistic definition -- for the LRC sometimes choose
> to dismember an enactment and reconstitute it within the non-positive
> title in some other way. Also, its quite possible that a whole act
> could be assigned to a note within a section of another note, although
> it's never legally a part of that section.
> b. The groupings of many acts into conceptual volumes, usually
> arranged by chapter. Examples include the Laws of Hong Kong -- each
> ordinance is a chapter, the Statutes for each year in California --
> each statute is a chapter, the Public laws of the U.S -- each statute
> is a chapter.
>
> In all these cases, the individual acts are the works rather than the
> volume they're assigned to. This differs from the case where the
> entire volume is the work -- examples being the positive law titles of
> the U.S. Code or the individual Codes (29 in total) of California. In
> these cases, its the larger volume that was enacted.
>

Akoma Ntoso has a class of document types called documentCollection, composed of <officialGazette>, <amendmentList> and the generic <documentCollection>. These are meant for works that are collections of documents that have their own independent existence as works themselves. This is exactly the case you mention, I believe.

How to use them: they use a collectionStructure with the usual parts, <meta>, <coverpage>, <preamble>, etc, and then a <collectionBody>, which is a list of <component> elements, each of which of docComponentType type, which is made of an optional series of heading elements (such as num, heading, etc., plus either a documentType (e.g., an individual work) or an <interstitial> element (documents or fragments that have no legislative or legal role, e.g. an errata corrige, statements, advertisement, etc.) or a <toc>. Of course you can replace the documentType with a <documentRef> and physically place the document outside of the collection.


> 2) How should omnibus bills be modeled with respect to FRBR? An
> omnibus bill is found in many jurisdiction -- although disallowed in
> many U.S. states. An omnibus bill may breaks into multiple independent
> acts rather than a single act upon enactment. So there isn't a
> one-for-one mapping between the bill and a resulting act. Also, at
> least at the U.S. federal level, how an omnibus bill is structured can
> be quite arbitrary. The component parts may be found within the main
> body or in annexes -- anything is permissible.

It is now a well-established opinion that bills and acts are separate works, and not expressions of the same work. This means that each act coming out of an omnibus bill is its own work, that has no FRBR connection with the bill it came out of. Non FRBR-relations between works, such as the ones between bills and acts, should be placed in the <references> section of the metadata, but no standard or recommended way has been suggested yet.

I would use a TLCReference element with a refersTo attribute to some TLCConcept such as "enactmentOf" (in acts, to refer to their bill) or "enactedAs" (in bills, to refer to their acts), or some such name.

Ciao

Fabio

--

> -- Grant
> ____________________________________________________________________
> Grant Vergottini
> Xcential Group, LLC.
> email: grant.vergottini@xcential.com
> phone: 858.361.6738
>
> ---------------------------------------------------------------------
> 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
>



--

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/






--

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





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