[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 all,
I am slow in writing, and this is actually the third draft of a reply, two of which went unfinished, the first one after the first message from Grant, then another after Monica's and now I hope to be able to send this after the second mail from Grant and the one from Veronique. Every time I had to scrap the text and start anew because of new arguments. I hope this time I got all the relevant ideas correctly and in time. Please inform me if I'm wrong.
I hope this discussion was at least thorough enough to convince you that the issue of ids is peskier than everyone of us thought. For instance, I thought there were two sides to it, now because of Veronique's mail I understand there are at least three. All of them, I hope we agree, are solid expressions of reasonable, well-justified and well-thought out points of view grounded on real cases that cannot be shrugged off easily. All of them, I hope we all agree, generate solutions that are good, reasonable, implementable for one's own needs, but that are intrinsically inadequate for the every other's needs, and that are incompatible with each other.
let me summarize where (my understanding tells me) we stand:
1) We all agree that id values are needed to address two separate issues, that of an identifier that is stable against modifications and that of an identifier that contains in itself information about the thing it identifies, so as to prevent lookups when a reference needs to be created.
2) We all agree that the problem arises when changes happen to the information the identifier should use, basically the structural number, so that it is fair to say that the problem arises only after an explicit renumbering.
3) We all agree that renumbering affects bills frequently, acts only rarely, and never the other document types more or less never.
Disagreements exist on basically everything else:
Monica says that for reasons mostly having to do with the need of creating external references to evolving versions of the document, she prefers the id attribute to be meaningful and evolving in time, and that another identifier needs to exist (called, for instance, permanentId) that is unchanging in time and moves with the text it refers to, and that both should be required for all document types.
Grant says that for reasons mostly having to do with organizations he's been working with that already use static ids, meaningless and unchanging, that it would be pointless to have these organizations change approach, and that he would like the id attribute to be without pre-imposed syntax and free for everyone, so that no standardization is forced even if this means that everyone is required to do a lookup to the source of the document to create a reference.
Veronique says that modifications may impact both on the number and the name of the structure, and creating meaningful ids may become overly confusing whenever a substantial change happens of the restructured fragment (e.g., the content of article #12 becomes item #7 of the second list of article #3), so that she would prefer a meaningless id even if this means that lookups are required for references.
Fabio says (and I totally agree with him) that we need ONE solution to rule all these cases, so that we do not make an exception for bills only, and that documents that do not undergo restructuring or renumbering should be basically unaffected, so that whatever decision we reach on bills requires no or minimal actions for all other document types.
First of all, let me point out that I find the argumentations from each of you clear and convincing, and that I find your solutions solid, concrete and undeniably correct. Unfortunately, I cannot help noticing a substantial incompatibility on them.
In cases like this there is little hope to find a solution that is better than those already proposed, a solution that satisfies all requirements as well as, or better than, each individual solution proposed so far, undiscovered by anyone except a superior mind that was able to oversee the whole situation and find the unexplored path through all the difficulties. In cases like these, the only hope is to find a reasonable compromise, and by compromise I mean a solution that everyone will hate with all their guts, but NOT AS MUCH AS they would hate any other solution except their own.
In this light I will bring you my compromise, which I know you will not like, indeed you will actively hate, but that I hope will be less disagreeable for you than any other solution except your own.
First of all, I am getting rid of the issue of which peculiar characteristics of the id should be associated to the simple name "id". I will call them "permanentId" and "meaningfulId" respectively, and I am open to the idea that one of them (only one, but from my point of view either one) may be eventually be renamed simply as "id" once we have reached an agreement on the rest.
Second, this is my proposal:
0) The issue for ID is identical to the issue of URIs. Whichever decision we reach for IDs shall have an impact on how we manage URIs and their resolution, because IT IS ACTUALLY THE SAME PROBLEM.
1) Both permanentId and meaningfulId are present in the syntax as attributes.
2) The syntax of both permanentId and meaningfulId is imposed by the standard, pretty much in the same way as the standard imposes the naming convention for the URIs, and for exactly the same reason. Also, I am open to the idea that a separate and future standardization group (e.g., the Open Citation TC) will eventually agree on taking charge of mandating a syntax for both external names (e.g., URIs) and internal names (e.g., ids), although I strongly hope that its output will be a smooth prosecution of the LegalDocML decisions.
3) Documents and substructures that do not undergo modifications and renumbering only need to use ONE of these attributes. This applies both to entire classes of document types that do not naturally undergo such changes (e.g., judgements, debate reports, amendments, etc.) as well as to individual documents and fragments that do belong to classes that are affected by renumberings (e.g., bills and acts), but are haven't been renumbered or restructured yet. Thus, all acts that were never renumbered, or all bills that haven't been renumbered yet, or all parts of a renumbered bill that were not affected by a renumbering, should use only ONE id attribute.
4) ONE of these attributes should be mandatory, and the other optional. Optionality in this case DOES NOT MEAN that it is a whimsical choice of the marker to use it or not, but that there is a requirement to use it WHEN AND ONLY WHEN the two identification needs arise separately (e.g., whenever a renumbering occurs and only for those parts that were actually renumbered).
5) Therefore, both attributes need to use the same syntax for their values, so that the mandatory one can act on behalf of the other in all situations when only one attribute is needed.
6) Since one of the ids (meaningfulId) makes requirements on the actual value of the id, the syntax of both ids need to follow its requirements, i.e., the ids are (or at least start as) meaningful, and then we see what happens.
7) After a renumbering or restructuring event the two ids NEED to exist both, and it is a requirement that the second id attribute appears and is maintained throughout the useful life of the document. In this case, the permanentId is fixed to whatever was the original value, while the meaningfulId changes to whatever value is meaningful for the new structure/number/position of the corresponding fragment. Any further renumbering will not affect the permanentId and will keep on changing the meaningfulId appropriately. Also, explicit and adequate log of the nature and timing of the renumbering needs to be kept in the renumberingInfo section of the metadata. I am willing and eager to add and change and modify this section of the metadata to cater to whatever need hasn't been considered yet, if any.
8) Resolution of external references to individual ids will be handled in EXACTLY THE SAME WAY AS resolution of URIs (because it is actually the same problem). This is complicated, exactly as complicated is the resolution of the URIs, because it is actually the same problem. I will give here just a brief summary of the mechanism. In order to access to structure #foobar, the resolver would need to:
1) if the fragments only contain one ID attribute each,
1-1) look for the one element whose id is "foobar"
2) if some fragments contain two ID attributes, then
2-1) if some renumberingInfo elements exist whose evolvedId is "foobar",
2-1-1) establish the ONE renumberingInfo whose "start" attribute is immediately preceding the creation date of the document containing the #foobar reference (or, if different, of the actual creation date of the #foobar reference itself),
2-1-2) look for the content element whose permanentId is equal to the "originalId" attribute of the chosen renumberingInfo.
2-2) If no evolvedId has value "foobar" then look for the element whose only id is "foobar" (because the element was not renumbered).
And voilà, it works!
Finally, a few objections to your arguments:
Veronique:
No, I do not think outdated meaningful ids would be confusing, because it would be extremely clear when they are active (i.e., meaningful) and when they are not. In particular, in my proposal, whenever there is only ONE id attribute, then the meaning is not outdated. Whenever there are two ID attributes, then the value of the permanentID is NOT meaningful, it is a opaque string of characters that just coincidentally happen to resemble the meaningfulId of the original version of the fragment, but you can safely ignore its value. Also, there would be a clearly marked meaningfulId just next to it.
Grant:
No, we should not leave to the individual administration the task of establishing the values of the id attributes. This would defeat the overall purpose of homogenization and interoperability of references of Akoma Ntoso, and would force creators of references to lookup each and every id of referenced fragments, not only for renumbered parts, but for EVERY reference between documents, including acts. Furthermore, if these values have an official status according to their administrations, then these values are no more jurisdiction of the author of the Manifestation, i.e., part of the markup, but jurisdiction of the author of the Expression, i.e., part of the content, and therefore must be specified within the XML appropriately.
Monica:
No, we should not require both attributes. Renumbering, although frequent in a few context, is still a substantially rare occurrence overall, and it is unheard of in many document classes. It would be overkill to require two separate id attributes whose values would be identical and unchanging and redundant in 90% of the documents just because in 10% documents (or less) their value might be different.
Also, regarding digital signature of multi-versioning documents: each multi-version document is a separate and different Manifestation of a document. Digital signatures act on Manifestations, so there is NO expectation of a specific signature to hold for subsequent manifestations. Each signature refers a universe of its own, and it would be just a coincidence for two Manifestations to have fragments that are identically signed. Also, regarding multi-versioned document: did it ever occur to you that if you let ids change their values version after version then all the ids in the passiveModification section of a multi-versioned document would need to be continually updated to the new values whenever a renumbering occurs? Permanent ids have no such problem.
Finally, a positive note: you may ask yourself, how much would this solution that fabio is proposing cost in terms of time or modifications to the schema? Well the answer is: none at all. The solution I hereby proposed is ALREADY IMPLEMENTED in the current version of the schema, and has been implemented for quite a while now.
So please, while I understand you will hate my proposal because it is so much worse and so much uncomfortable wrt to the solution you proposed, please consider the objections you would have if someone else's proposal was to be established instead, and decide which would be worse.
Ciao
Fabio
--
Il giorno 20/ago/2013, alle ore 17:28, "PARISSE, Véronique" <V.PARISSE@aubay.lu> ha scritto:
> Dear Monica, Fabio and Grant
>
> Here is my small stone to the subject.
>
> First, the users want a standardised way for referencing of a block of text (a business reference without the typographic irrelevant information). This business reference is based on the type of the block structure and on its number (<num> element), sometimes with a hierarchical context.
> So, the value of this field will evolve when the structure is renumbered or when his type change (a paragraph becomes a list of points).
> But what is a "standardised way" ?
> We need to define when the reference must be expressed as a hierarchical reference or not (in an act at EP, the article number can be enough, without mention of his chapter, for example, but I am not sure that it is always the case).
> Another question is whether this reference will be alinguistice or not ("article 1a" in one language is "article 1 bis" in another one; sometimes, an "article" in french is a "rule" in english, sometimes, not)
>
> Secondly, we need an unique identifier of the block of text. This must be persistent as we want to follow the same piece of text through the Expressions. It is also nice if the identifier will be managed to be identical between linguistic version.
>
> Because we need the persistence of the id value, it becomes very complicated if we build this value on a semantic information that is not permanent. It will be more disturbing than helping : when the value at the basis of the id evolves, the meaning of the id is erroneous.
> For applications that manage bills, this type of change is frequent, the renumbering is implicit and furthermore, the old version has no more interest except for historical reason.
> The id build on semantic meaning is also difficult to manage with complex documents like documentCollection or document with attachments when we want to group all the documents in one xml instance (the id must be unique for the xml instance so we need algorithms to garantee this).
>
> After discussion, we arrive, at the European Parliament, at the same conclusion as Grant (and the Commission) : the id is a meaningless value (a sequential number). (Finally, it is like a "number of national register" that identify the people)
> We understand the need for standardised referencing of piece of text, but before implementing it, we need to define it clearly. And the value of the reference does not need to be unique inside the xml instance : if a bill has as attachment another bill, it is normal that we have in the xml instance two "article 1". When referencing, the user need to specify if he search inside the attachment or the main bill.
>
> Kind regards
>
> Véronique
>
>
>
> Véronique Parisse
>
> 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 Grant Vergottini [grant.vergottini@xcential.com]
> Envoyé : mardi 20 août 2013 7:02
> À : Monica Palmirani
> Cc : legaldocml@lists.oasis-open.org; Fabio Vitali [fabio@cs.unibo.it]
> Objet : Re: [legaldocml] On ids for structures in multipleVersions documents
>
> Dear Monica and Fabio,
>
> There is a very important consideration when if comes to the @id attribute - how easily Akoma Ntoso can coexist with the infrastructure that is already in place. For this reason, I think that the @id attribute recommendations cannot be normative.
>
> I think that it is highly unlikely that Akoma Ntoso will be deployed into a new environment that has been built from the ground up. More likely, Akoma Ntoso will need to coexist with existing systems - and initially in a support role rather than in a primary role until confidence in the Akoma Ntoso model grows. I'm guessing that initially Akoma Ntoso will be made available through a transform as an output rather than being the internal model.. I am already finding that customers are reluctant to adopt something unproven that is not designed precisely to their spec. But they are willing to adopt it as a transform where the risk is less. In that case, the @id conventions are already in place in the internal model and cannot be modified for the convenience of Akoma Ntoso.
>
> And even if the jurisdiction is willing to adopt Akoma Ntoso more extensively, they probably already have a system with assigned ids in place and it would be preferable, in order to preserve compatibility with existing infrastructure, to preserve those ids.
>
> In California, Hong Kong, and in the U.S. House, the @id attribute is already well established. In all three cases, ids are defined as long meaningless GUIDs. In all three cases, this convention goes back a decade or more (2003 in California, 2000 in the U.S. House, and 1997 in Hong Kong). All three jurisdictions came to the same conclusion independently without any interaction or relationship at all - so I'm quite willing to guess that the three jurisdictions I am dealing will aren't the only ones.
>
> In all three jurisdictions, as we move forward, we are preserving the existing id attribute values to ensure that systems we aren't modifying, which have dependencies on the @id attribute, won't break. It is very important that we allow this in order to allow Akoma Ntoso to be adopted with too much upheaval.
>
> Regards,
> Grant
>
>
> On Tue, Aug 13, 2013 at 12:01 PM, Monica Palmirani <monica.palmirani@unibo.it> wrote:
> Dear Fabio,
>
> thank you very much for your email. It is really clear and nice (especially in the part where you list the obvious things :-)), but let me list some doubts coming from my experience with the end-users (and form about 100.000 XML legal documents marked-up with NormeinRete and Akoma Ntoso).
>
> I want to beg pardon to the TC members for this long email and I am also sorry for the English mistakes, but it is a sort of analysis report on the ID. I hope Fabio will find it useful and, as usual, he could find the best solution for the success of Akoma Ntoso.
>
> I have decided to proceed in the analysis with critical questions.
>
> Should ID naming convention be mandatory and normative in LegalDocML specs?
> I am convinced that the ID convention should be maintained apart from the XML-schema (that is normative) in our LegalDocML workplan. Considering also that OASIS thinks to open a new TC inside of LegalXML-sc called “Universal Legal Citation”, it is reasonable not to close Akoma Ntoso only to our ID naming convention, but to permit also other ID policies. For this reason also alternative naming conventions could be eligible if they respect the pillars of Akoma Ntoso. Just for example, if instead of “sec9” an institution would like to use “section9” it is not the end of the world.
>
> In my option LegalDocML TC can suggest or recommend something about ID, but not impose strong rules on the syntax, simply because this topic (ID policy) depends often to institutional decisions, internal workflow, integration with other legacy systems, archiving national rules, digital signature processes, complicated and convoluted internal reasons, and so.
>
> An important goal, in my opinion, for our TC is to define some strong pillars concerning the ID for permitting:
> 1) a robust mechanism for those institutions that start from scratch;
> 2) good practices for interoperability;
> 3) a mapping mechanism between existing naming convention and our Akoma Ntoso system.
>
> Should ID be meaningful and unique?
> Yes, for sure. These are pillars. For the Art. 8 we have something like “art8” and for section 9 something like “sec9”. For the Section 9A we have “sec9A”. Not something like x4956.
>
> Do we need evolvingID?
> Yes, for sure. We need to have two IDs:
> - one is the original ID, persistent and not changeable
> - one is the new ID according with the naming convention and aligned with the textual changes in the legal document. We could use this ID also for the references (e.g. /us/act/GovernemntCode/main#art11343.4).
>
> Which role has evolvingID?
> Following the current version of the release note evolvingId is so defined:
> “the id attribute contains the persistent identifier, while the evolvingId attribute contains the identifier that should be used if this fragment was alone, without previous history or similarly named fragments.”
> My proposal is to invert the functionalities of the two IDs for the reasons that I am trying to explain later.
> “the evolvingId attribute contains the persistent identifier, while id the attribute contains the identifier that should be used if this fragment was alone, without previous history or similarly named fragments.”
> And to change the name of evolvingId in persistentID.
>
>
> Should ID be changeable?
> The release note says “NO” and for sure at least one between Id and evolvingId must not change.
> My proposal is: to maintain not changeable evolvingId. In case the name should be changed in persistentID and make it mandatory.
>
> Let me list some motivations in support of my thesis.
>
> 1) Isomorphism with the text
> The text says "art. 8" and you don't know in which version you are when you start to mark-up. You don’t know if in the world (e.g. in some committee, in the same chamber or in another chamber) exists a previous version where "art. 8" previously was "art. 3". You know only that the text says: "art. 8" so the only option that you have is to coordinate the ID attribute with the text. Bill is often in this situation during the legal drafting and we really risk to have a strange ID attribute. Any other information (evolvingID) is about additional legal knowledge and it doesn’t belong to the basic evidence from the text. If the art. 8 was before art. 3 is an extra legal knowledge that needs interpretation and human effort.
>
> 2) NLP tools
> If we don’t use the isomorphism principle abovementioned, NLP tools could not be useful for extracting in automatic way the ID properly from the text. If the text says "art. 8" the NLP parser can only to produce an id="art8", not "art3". Otherwise we should know other information that could not be in our hands or need more effort (e.g. human, automatic tools, open the old document, etc.. ).
>
> Also in the references we have some problems.
> A fragment of text like this that was renumbered and changed several times:
> “Section 11343.4 of the Government Code”
> is marked up in this way (using NLP tools):
> <ref id="ref1" href="/us/act/GovernemntCode/main#art11343.4">Section 11343.4 of the Government Code</ref>
>
> Since the URI uses the ID attribute as a fragment part for specifying the internal anchor of the document, we have an evident pointer that we don’t know if it works. Probably due to several modifications of the GovernementCode the original, persistent ID attribute is completely different from the current version. In this case we need a piece of software (resolver and database) to resolve properly the navigation to the correct part of the GovernmentCode.
>
> 3) disHarmonization: two IDs, many different uses
> In the same document we could have some sections/articles with the evolvingID and some other without it. Some IDs could be coherent with the text and other be not (e.g. id=”art2new”). Simply because in a bill not all the sections/articles are affected by modifications or renumbering actions, we have a very variety of kind of IDs metaphor.
>
> That means that we could have a not harmonized situation like this:
> - ID=”art3” that is art3 because it was not affected at all to any modification
> - ID=”art3” that is art2 because it was renumbered
> - ID=”art2new” that is a new element because it never exists before
> - ID=”art2fra” that is the version in France
> - ID=”art2v1” that is the new version in multi-versioning document.
>
> What happens if I have a multi-versioning bill in French and I need to renumber the new version in the 20th step of the legislative process?
> Id=”art2franewv20” evovlingID=”art3”
>
> I think we need to harmonize a little bit the naming convention in order to make the mark-up easier and usable with automatic tools.
>
> 4) Navigability: backward or forward?
> If the art. 2 becomes art.3, the XML fragment, following the release notes, it will be the following:
>
> <article id="art1">
> <num>1</num>
> <content><p>Originally article 1</p></content>
> </article>
> <article id="art2new" evolvingId="art2">
> <num>2</num>
> <content><p>New article 2</p></content>
> </article>
> <article id="art2" evolvingId="art3">
> <num>3</num>
> <content><p>Originally article 2</p></content>
> </article>
> <article id="art3" evolvingId="art4">
> <num>4</num>
> <content><p>Originally article 3</p></content>
> </article>
>
> The main problem here is the references (<ref>) among the connected documents to a bill (motion, explanatory summary, motivos).
>
> Take in consideration this reference:
> <ref id="ref1" href="/uy/act/1967/Constitucion/main#art1">article 1</ref>
> This reference, when it is transformed in HTML link, should point out to the article 1. The resolver needs to use the ID attribute because article 1 has only this attribute.
>
> Take in consideration this reference:
> <ref id="ref2" href="/uy/act/1967/Constitucion/main#art3">article 3</ref>
> This reference, when it is transformed in HTML link, should point out to the art. 4 using the ID attribute or the evolvingID?
> It depends to the date of the document in which the link is included and how many renumberings the art. 3 has had.
> The resolver of those links is really a difficult task to manage between ID, metadata and evolvingID.
>
> If we have the following fragment of XML:
> <article id="art1" persistentID="art1">
> <num>1</num>
> <content><p>Originally article 1</p></content>
> </article>
> <article id="art2" persistentID="art2new">
> <num>2</num>
> <content><p>New article 2</p></content>
> </article>
> <article id="art3" persistentID="art2" >
> <num>3</num>
> <content><p>Originally article 2</p></content>
> </article>
> <article id="art4" persistentID="art3">
> <num>4</num>
> <content><p>Originally article 3</p></content>
> </article>
>
> We could use always the ID and metadata for deciding the correct navigation and the persistentID for any other purpose.
> Pros:
> We can navigate easily the nodes using an harmonized metaphor and a clear algorithm.
> We could use NLP tools for detecting the fragment of the text and use it for the ID. The same for the legal references.
> We have in any case a persistent ID.
>
> Finally since the evolvingId is not mandatory, it is possible that we may not have enough information.
> For this reason I suggest to make this attribute evolvingId mandatory.
>
> 4) Digital signature
> Bills, acts and legal documents more and more are managed with digital signature (also in US).
> XadES, a new format of digital signature in XML, permits to sign some nodes of an XML document only.
> CadES permits to sign all the document.
> In EU these kinds of digital signatures are legally valid and used in the majority of Official Gazette or Journal (e.g. Austria, Italy, France, etc.).
> If a bill is signed with digital signature and we adopt the multi-versioning, we can’t modify the previous multi-versioning parts.
> So the following fragment is not eligible because the “old version of art. 2” was signed in T1 and it is not modifiable.
>
> <art id="art2" evolvingId="art2">
> <num>2</num>
> <content>
> <p>New version of art.2</p>
> </content>
> </art>
> <art id="art2v1" evolvingId="art2">
> <num>2</num>
> <content>
> <p>Old version of art.2</p>
> </content>
> </art>
>
> For this reason it is eligible the following fragment (using XadES that permits signature on XML nodes) where the persistentID was not modified and the id is incremental:
>
> <art id="art2-v1" persistentID="art2">
> <num>2</num>
> <content>
> <p>New version of art.2</p>
> </content>
> </art>
> <art id="art2" presistentID="art2">
> <num>2</num>
> <content>
> <p>Old version of art.2</p>
> </content>
> </art>
>
> This is reasonable also for maintaining navigable the links from the old documents, already signed and fixed, without any further changes.
>
> Moreover if we have an internal reference to art.2 to the first version fixed in the t1, we have this fragment of XML:
> <ref id="ref2" href="#art2">article 2</ref>
> we need to change also all the internal references to the multi-versioning fragments in this:
> <ref id="ref2" href="#art2v1">article 2</ref>
>
> 5) Additional issue for the ID
> The components inside of the <documentCollection> need to be regulated as well with some rules.
> If I have three different versions of the same bill included in the same <documentCollection> (it is possible, those bills come from three different parties/committees in the meantime and presented to the parliament) I will have some problems to manage the conflicting ID.
> The same bill in three different variants needs some extra rules not included in the release notes yet .
>
> Another similar scenario is to have three different bills (three different works) included in the same <documentCollection> with conflicting IDs.
>
>
> Recap of my proposals (listed by priority and in alternative):
> 1) evolvingID changes role and it is a persistence ID (never change) and the navigation is based always on ID attribute (no modifications in the XSD but in the release notes).
> 2) evolvingID is mandatory. All the navigation is based always on evolvingID. Also the internal references use it (little impact on current release).
> 3) to permit both role of evolvingID: presistence ID or changeable ID (not a nice solution but backward compatible).
>
> What do you think? I hope your good answers will be more than my doubts.
>
> Have a good holiday,
> Monica
>
> Il 10/08/2013 10:02, Fabio Vitali ha scritto:
>
> 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/
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
> .
>
>
>
>
>
> --
> ===================================
> 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
> ====================================
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]