[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml] On ids for structures in multipleVersions documents
Dear Grant, Monica, > The confusion over the evolvingId or temporalId has left me wondering whether a single Id attribute would not be better as a GUIDy thing without any hint of the number I had this very discussion less than 12 months ago with technical people from the European Commission (not the Parliament, the Commission). It seems as if there is something in the brain of computer scientists that make them believe that the only job of an id is to be unique within the document, and for this reason it can be any absurd string of characters as long as it isn't repeated anywhere else. Of course, for computer scientists, unique ids are stable across versions, so it is safe to assert that whatever was identified by some id in the initial version will be identified by the same id in all subsequent versions. Next thing it happens is that you talk to legal experts and tell them: "so there is the id for, say, section 9, let's say the value of the id is actually 'xy45a3', and you place it after the "#" character of the URI and voilà you have your link". And they will ask you: "Ok, this is cool, but now how do I know the id of the next section, that is to say, section 10?" And you will say: "You can't know it beforehand: you have to look it up in the source and check whatever absurd string of character has been chosen for section 10." and they will stare blankly at you as if this was the pun of a joke that they did not get, and ask simply, in a very low voice: "Why?" And not only legal experts: archivists have the same point of view, and librarians, and publishers, and medical students, etc. They all understand that the id, to be useful, has to be meaningful in some other manner than simply being unique: it has to carry within itself at least SOME information about the thing it identifies. For them, this is not subject to argumentation: it is an evident truth that is pointless to discuss, like the sun is not green, Justin Bieber is not male, Ferraris are red and Brazilian soccer teams do not play the chain ( http://en.wikipedia.org/wiki/Catenaccio ). On this very topic, I would like to point you again to section 7.4 of the Release Notes, and in particular to the list starting with "Our solution must maintain some fundamental principles: ", and in particular with item 8, "Meaningfulness: the id of a part must, as much as possible, express basic facts about its nature, position, or relation to superior and/or neighboring elements that are meaningful to the local tradition.". This is a fact so ingrained in the mind of jurists that sometimes they consider all too natural to go to the exact opposite... For instance, I had exactly the opposite discussion with Monica not later than last week, again about ids in bills. She was asserting that since renumbering in bills is a frequent operation, and in enacted laws it is rather rare, it makes sense to allow two different policies for ids, whereby in acts you maintain the same id across versions, and use evolving ids for the id the structure would have now, while in bills you do exactly the opposite, and update the ids to whatever is the structure number after the renumbering, and use evolvingIds to record the original id. This would violate basically every item of the above mentioned list, plus item 0 that we never cared to express, namely "Homogeneity: there must be ONE solution and it needs to be applied in the same way to all document types and parts". So let me come back to the discussion, again as expressed in section 7.4: there are two opposite needs for identification, one that needs to be persistent, so as to allow easy tracking of the same entities across versions, and another that needs to be meaningful, so as to be able to associate easily the id to its entity and the entity to its id, without the need of global lookups within the document. These opposite needs completely overlaps when no renumbering happens, and dramatically contrast every time a renumbering happens. The solution adopted so far has been to have two separate sets of identifiers, one of which is persistent and the other is meaningful. Which of them is called id and which is called something else is irrelevant, but it seems to me that any solution that sets either persistency or meaningfulness as the only relevant requirement throwing away the other is inherently wrong, and any solution that requires different approaches for different types of documents is even worse. So the way I see it is that both you and Monica hate evolvingId with the purest of your heart, but from completely different points of view, and that the usefulness of evolvingId can only be denied by denying the very need of a compromise between persistency and meaningfulness, which you both do but from opposite positions. I hope I was convincing... Ciao Fabio -- Il giorno 25/lug/2013, alle ore 08:09, Grant Vergottini <grant.vergottini@xcential.com> ha scritto: > Hi Fabio, > > I finally got some quality time to sit down and look over this. I understand the two approaches - and depending on the scope of the change, one is better than the other as you note. > > I do worry that the Id management is going to be very difficult in an application. This whole issue has come up for me in the past week on work we're doing for the US House. It seems to me that maintaining the original section number in the Id across time will only lead to confusion in the minds of the developers that will work with the data. I've tried to explain the notion of the evolvingId vs. the id on several occasions now only to get confusion back. Another approach I have tried is to describe the Id as time independent Id and the evolvingId as a time dependent Id - actually calling it a temporalId instead and explaining it as an Id that only can exist at a point-in-time - as it's dependent on a specific state. That approach has been better understood, but in the end is controversial too. > > The confusion over the evolvingId or temporalId has left me wondering if it makes sense to have it at all, and whether a single Id attribute would not be better as a GUIDy thing without any hint of the number. This is similar to how the US House already assigns identifiers and how Hong Kong appears to assign identifiers. Actually, if I'm seeing it right, the existing Hong Kong system assigned two concatenated GUIDs to create the Id. The first half stays the same across all versions while the second half gets reassigned a GUID value from version to version. The end result is the same - a long jumble of alphanumeric characters. > > What purpose does the evolvingId attribute serve? Why is it necessary? I know I've been one who has elevated the role of the evolvingId attribute, but I'm wondering if there perhaps isn't a better way to sidestep the confusion that results when an id attribute tries to have a meaningful value based on something that varies with time - like the "num". > > -Grant > > > On Tue, Jul 23, 2013 at 12:52 PM, Fabio Vitali <fabio@cs.unibo.it> wrote: > Ciao. > > I had a remaining task I promised last week to Grant, i.e. to provide my own point of view on how to solve the riddle of managing multiple coexisting versions of the same structure (say, section 9 of a bill) in a multi-versioning document (i.e., a document that maintains data about multiple subsequent versions and can be used to display the content of any of them). > > Let's make a simple example. Here you have section 9 of a bill as presented on January 1st, 2013. Each month (to simplify) it gets renumbered, first to 7 and next to 13 and finally again to 9, but the content never changes. The version of January 1st is a originalVersion, all the subsequent ones are multipleVersions. > > FIRST VERSION > ------------- > > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="originalVersion" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval refersTo="#firstVersion" start="#e1" /> > </temporalGroup> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > ... > <section id="sec9"> > <num>Section 9</num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > Pretty simple so far. On February 1st, a new version of the document gets approved, where section 9 is now section 7 and nothing else. The manifestation of the new expression becomes multipleVersions, we now have three temporalInfo elements (what has remained without changes, what has been deleted in version 2 and what has been inserted in version 2). > > As for the body, we have two choices. The first one is to mark simply and exactly the text fragments that have changed. Therefore there is still only ONE section element, and id and evolving ids are used as needed and we have two spans in the CONTENT of the num element associated to one or the other of the temporalInfo elements, as follows: > > SECOND VERSION, APPROACH ONE > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > </temporalGroup> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > <section id="sec9" evolvingId="sec7"> > <num>Section > <span id="sp1" period="ti2">9</span> > <span id="sp2" period="ti3">7</span> > </num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > The second approach is to duplicate the section element, and to maintain identity as follows: the currently existing section with the new content maintains the id, plus the evolving id, while the old section, maintaining the old content, has some appropriate identifier and no evolvingId (because it does not exist now and therefore needs no evolvingId). Furthermore, we add a renumberingInfo element to keep track of the changes (when only dealing with two versions, this element does not provide any additional information than evolving ids, but is will change from the second renumbering. > > SECOND VERSION, APPROACH TWO > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > </temporalGroup> > <renumberingInfo id="rI1" originalId="#sec9" evolvedId="sec7" start="#e2"/> > </temporalData> > <references source="#fv">... </references> > </meta> > <body> > <section id="sec9-1" period="#ti2"> > <num>Section 9</num> > <heading id="sec9-1-h">Some heading</heading> > <content id="sec9-1-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9" evolvingId="sec7" period="#ti3"> > <num>Section 7</num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > Ok so far? The choice between approach one and approach two is left to the marker, and in my mind it clearly depends on how much of section 9 has been changed besides the simple number. If much has changed, then approach two is better, if only the number has changed, then approach one is better. > > ----- > > On March 1st, the section gets renumbered again, this time to 13. Now we know the drill and the two approaches still work. Please note that in the two approaches the section meta is identical, while the body is different. > > THIRD VERSION, APPROACH ONE > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > <eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > <timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" /> > <timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" /> > </temporalGroup> > <renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/> > <renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3"/> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > <section id="sec9" evolvingId="sec7"> > <num>Section > <span id="sp1" period="ti2">9</span> > <span id="sp2" period="ti4">7</span> > <span id="sp3" period="ti5">13</span> > </num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > THIRD VERSION, APPROACH TWO > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > <eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > <timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" /> > <timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" /> > </temporalGroup> > <renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/> > <renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3"/> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > <section id="sec9-1" period="#ti2"> > <num>Section 9</num> > <heading id="sec9-1-h">Some heading</heading> > <content id="sec9-1-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9-2" period="#ti4"> > <num>Section 7</num> > <heading id="sec9-2-h">Some heading</heading> > <content id="sec9-2-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9" evolvingId="sec13" period="#ti5"> > <num>Section 13</num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > Finally, on April 1st, we renumber the section back to section 9, but we want to maintain the twists that the section has gone through in the past. > > FOURTH VERSION, APPROACH ONE > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > <eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" /> > <eventRef id="e4" date="2013-04-01" source="#pr3" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > <timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" /> > <timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" /> > <timeInterval id="ti6" refersTo="#repealedinVersion4" start="#e3" end="#e4" /> > <timeInterval id="ti7" refersTo="#addedinVersion4" start="#e4" /> > </temporalGroup> > <renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/> > <renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3" end="#e4"/> > <renumberingInfo id="ri3" originalId="#sec9" evolvedId="sec9" start="#e4"/> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > <section id="sec9" evolvingId="sec7"> > <num>Section > <span id="sp1" period="ti2">9</span> > <span id="sp2" period="ti4">7</span> > <span id="sp3" period="ti6">13</span> > <span id="sp4" period="ti7">9</span> > </num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > FOURTH VERSION, APPROACH TWO > ---------------------------- > <akomaNtoso xmlns="http://docs.oasis-open.org/legaldocml/ns/akn/3.0/CSD05";> > <bill contains="multipleVersions" name="bill"> > <meta> > <identification source="#fv"> ... </identification> > <lifecycle source="#fv"> > <eventRef id="e1" date="2013-01-01" source="#ro1" type="generation" /> > <eventRef id="e2" date="2013-02-01" source="#pr1" type="amendment" /> > <eventRef id="e3" date="2013-03-01" source="#pr2" type="amendment" /> > <eventRef id="e4" date="2013-04-01" source="#pr3" type="amendment" /> > </lifecycle> > <temporalData source="#fv"> > <temporalGroup id="tg1"> > <timeInterval id="ti1" refersTo="#originalVersion" start="#e1" /> > <timeInterval id="ti2" refersTo="#repealedinVersion2" start="#e1" end="#e2" /> > <timeInterval id="ti3" refersTo="#addedinVersion2" start="#e2" /> > <timeInterval id="ti4" refersTo="#repealedinVersion3" start="#e2" end="#e3" /> > <timeInterval id="ti5" refersTo="#addedinVersion3" start="#e3" /> > <timeInterval id="ti6" refersTo="#repealedinVersion4" start="#e3" end="#e4" /> > <timeInterval id="ti7" refersTo="#addedinVersion4" start="#e4" /> > </temporalGroup> > <renumberingInfo id="ri1" originalId="#sec9" evolvedId="sec7" start="#e2" end="#e3"/> > <renumberingInfo id="ri2" originalId="#sec9" evolvedId="sec13" start="#e3" end="#e4"/> > <renumberingInfo id="ri3" originalId="#sec9" evolvedId="sec9" start="#e4"/> > </temporalData> > <references source="#fv"> ... </references> > </meta> > <body> > <section id="sec9-1" period="#ti2"> > <num>Section 9</num> > <heading id="sec9-1-h">Some heading</heading> > <content id="sec9-1-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9-2" period="#ti4"> > <num>Section 7</num> > <heading id="sec9-2-h">Some heading</heading> > <content id="sec9-2-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9-3" period="#ti6"> > <num>Section 13</num> > <heading id="sec9-3-h">Some heading</heading> > <content id="sec9-3-cnt"> > <p>Some content</p> > </content> > </section> > <section id="sec9" evolvingId="sec9" period="#ti7"> > <num>Section 9</num> > <heading id="sec9-h">Some heading</heading> > <content id="sec9-cnt"> > <p>Some content</p> > </content> > </section> > </body> > </bill> > </akomaNtoso> > > That is all. I hope I did not make errors in the markup. I also hope I was clear and exhaustive. I surely was exhausting, but alas, what could I do? > > Ciao > > Fabio > > -- > > 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 > > > > > > -- > ____________________________________________________________________ > 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]