![[AQDIJ]](/img/aqdij.gif)
Illinois Institute of Technology
Computer Science Department
10 West 31st Street
Chicago, IL 60616
manoale@karl.iit.edu
mwe@schur.math.nwu.edu
ABSTRACT
We propose some possible applications of hypertext techniques that could improve the existing computer based case research technologies.
Improving the performance and lowering the cost of legal information retrieval systems is achievable by easing the navigation problems and thereby eliminating the redundancy created by the parallel citations of cases. A unique update protocol model of transaction filter in front of a database that supports the case law hypertext is proposed. Single step shepardizing of the parallel citations is achievable. New computer oriented navigation technologies for case law research should be developed.
A modern case law information system in addition to the traditional retrieval techniques should provide the user with: non-redundant knowledge presentation (collapsed knowledge presentation);;hypermaps;;same hypertext navigation technique for the citing-cited ;;and cited-citing directions of citation links;;automated link maintenance.
INTRODUCTION
In this paper we will discuss some problems of the application of computer hypertext to case law information research. Recognizing the characteristics of case law information and the process of case law research, as well as the level of computerization found in the field, we propose some possible applications of hypertext techniques that could improve the existing computer based case research technologies.
With the goal of improving the performance and lowering the cost of legal information retrieval systems, Tapper [Tapper, 1982] experimented with using citation vectors to identify and group together common law cases having significant points of similarity. We propose to achieve the same goal by easing existing navigation problems and thereby eliminating the redundancy created by the parallel citations of cases. A unique update protocol model of transaction filter in front of a database that supports the case law hypertext is proposed. Single step shepardizing of the parallel citations is achievable.
Hypertext is not a new concept for the law [Johnson, 1991, p. 260]. Lawyers are used to searching and reading text in a nonsequential manner, i.e., jumping between paragraphs from different legal authorities. Also, when writing they use citations extensively to link their documents with the knowledge already incorporated in statutes, court decisions and treatises. That is why we can hardly agree with Nielsen that "Hypertext applications, ... , only make sense if you have a computer." [Nielsen, 1990, p. 12]. Hypertext makes very good sense for lawyers even if they do not have or do not use computers.
CHARACTERISTICS OF THE CASE LAW INFORMATION
Case law information is available from printed sources (Reporters, Slip Opinions, Advance Sheets) and in electronic versions (LEXIS, WESTLAW, etc.). The best, albeit most expensive way of using it, is through on-line communications. Even WEST's CD-ROM publications need to be used in conjunction with on-line updates to accommodate recent changes.
Case law information has a large volume and is dynamically updated. Over three million cases have been published in the US and over 100,000 new cases are issued each year [Cohen, 1989, p. 2].
The same cases are published (verbatim reprinted) several times under different names in different case reporters. We should consider such cases as synonyms. As long as these synonyms exist the rule of a unique primary source of information will be violated and produce redundant complexity for case navigation.
CHARACTERISTICS OF THE CITATION LINKS BETWEEN CASES
The text of the cases contains references to other cases, legislation, treatises, articles and dictionary definitions. The references present hypertext links in a multi-document hypertext space. These links are "read-only hypertext" - once stated by the court they are not to be changed by the case users. In this paper we will discuss only citations between cases.
The citation links between cases start and end at some point inside the text. Thus the "practical rule" proposed by Martin [Martin, 1990, p. 170], to restrict the target of Go-to links to an "envelope" (rather than to a detail within the "envelope") is not applicable here. It is much more comfortable for the user to have the target within the "envelope," or in other words the citation to the proper offset within the case.
Links connect issues and not simply cases. Multi-issue cases are not rare. When reading through such a case the user might be interested not in the whole case but only in the presence of the issue of interest in the given case. Different research paths may cross as they pass through the same case.
There exist a;large volume of citation links. Citation links between cases are bidirectional. A study showed that a case cites on average 13.45 other cases and is cited on average by 7.57 other cases [Tapper, 1982, p. 10]. This, against the background of the number of existing cases, shows the avalanche potential of any kind of redundancy of the links.
Uniform rules of citation are followed [A Uniform System of Citation, 1991; Maroonbook, 1989]. Tools that find citations in the text automatically, therefore have an advantage.
Links are dynamically updated. Each new case updates the set of citation links and may make a previous research on a case incomplete or obsolete.
All links are indexed manually and are published. Shepard's McGraw-Hill identifies, classifies and publishes about 150 million legal citations a year [Gibney, 1989]. The cases are referenced by their short names, which makes parallel publications indistinguishable when working only with citators. The human indexers include the treatment of the cited case (whether it was followed, overruled, distinguished, etc.), which seems to be an insuperable obstacle for automation.
The parallel publication of verbatim reprinted cases creates parallel citations, which indeed are redundant citation links. They are created when different reprints of the same case cite a given case, or a case cites different reprints of a given case, or different reprints of a given case cite different reprints of another case.
CHARACTERISTICS OF THE CASE LAW RESEARCH
Case Research is a time consuming and expensive procedure.
Lawyers use both directions of citation links. Following the citing-cited direction of citation links between cases, as well as the cited-citing direction is a significant part of any case law research. The research follows nonlinear paths. The user jumps between paragraphs of cases instead of reading sequentially from the beginning of the text.
The relevant cases have to be "shepardized." The researcher must make sure that the relevant cases still present "good law," in other words that they are not overruled. In general, the researcher has to check if any other case cites these cases. This process is called shepardizing and it gives the history and the treatment of cases. When shepardizing a case that has parallel publications, all parallel citations have to be shepardized also, which requires a lot of time and effort. The "good" cases are used to support a given issue. Overruled cases are used to contradict the same issue.
Both manual and computer-assisted techniques are used for case law research. Research can be done manually through the use of printed Reporters or with a computer through communication with legal information systems like LEXIS and WESTLAW.
While shepardizing parallel citations manually the researcher has to open many different Reporters to find all the relevant information. Using the available computer services for shepardizing one gets the same information faster but again uses technologies that simulate the manual ones. Our opinion is that new computer oriented shepardizing technologies should be developed. Speaking more generally new computer oriented hypertext technologies for case law information research are needed. Such technologies should perform better than the computer simulations of manual technologies.
CURRENT STATE OF COMPUTER ASSISTED CASE HYPERTEXT
WESTLAW's CD-ROMs are the best hypertext products on the market. Using buttons the user can easily follow citation links from the citing case to the cited case. The opposite direction - from cited case to citing case has to be performed by shepardizing. In both LEXIS and WESTLAW, shepardizing of parallel citations must be performed separately for each parallel citation. This requires much time and effort. In general, the techniques used for following links from citing case to cited case are different from the techniques used for following links from cited case to citing case. We propose a way to eliminate this difference.
HYPERTEXT IMPROVEMENTS TO THE CURRENT COMPUTER-ASSISTED
CASE LAW RESEARCH TECHNOLOGIES
Our opinion is that a modern case law information system in addition to the traditional retrieval techniques should provide the user with:
-;non-redundant knowledge presentation (collapsed knowledge ;;presentation)
-;hypermaps (some authors call these overview maps)
-;same hypertext navigation technique for the citing-cited ;;and cited-citing directions of citation links
-;automated link maintenance.
A discussion of how this could be achieved follows.
LINK DATABASE
A Link Database should be created to support the hypertext system. We can hardly agree that "A hypertext information base has no central definition and no regular structure.," as Nielsen has suggested [Nielsen, 1990, p. 8]. More particularly we could agree with Nielsen with reference to manually created and manually maintained hypertext links, which are created without a central definition and a regular structure. When we consider automatic hypertext creation and automatic maintenance, however, a central definition and structure is necessary.
The Entity-Relationship Data Model defining the data in the Link Database is shown below:
_______
/ \
| case_id |
\_______/
|
----------
-----| CASE |-----
| N ---------- N |
| N| |N |
/ \ | | / \
/ \ | | / \
/CITATION \__| |__/ SYNONYM \
\ LINK / \(verbatim/
\ / \repr)/
\ / \ /
The relational model defining the same data consists of two relations:
LINK (citing_case_id, cited_case_id, citing_offset, sited_offset)
with a two attribute key - citing_case_id and cited_id, and
SYNONYM (case_a_id, case_b_id), with a two attribute key -
case_a_id and case_b_id.
The short names of the cases might be used for case_id. The citing and cited offsets might be presented by the number of the WESTLAW paragraph, by the page number within the case, or by the absolute distance in characters from the beginning of the case. The above two relations will provide the foundation for the filtering of the redundant links that are due to the parallel publications.
FILTERING (COLLAPSING) OF CITATION LINKS
Based on the Link and Synonym Relations we can maintain the Link Database filtered of redundant links. An Update Protocol Model for such a filter has been developed [Manov, 1991]. The Updade Protocol Model (UPM) is a formal language for the expression of the semantics of database update. UPM consists of a collection of "update protocols" defined over a relational database. An update protocol consists of a list of protocol contexts, and two optional lists - of constraint and trigger expressions [Carlson and Arora, 1985, p. 966].
Some of the characteristics of our filter are given below:
-;when inserting in the LINK relation the filter prevents insertion of links between synonym cases, prevents insertion of link from a synonym case of a citing case, prevents insertion of link to a synonym of a cited case, and prevents insertion of a link if it already exists between synonym cases;
-;when deleting a link from the LINK relation, the filter prevents loss of links from synonym citing cases, and prevents loss of links to synonym cited cases;
-;when inserting in the SYNONYM relation, the filter avoids inserting an inverted relation, deletes the redundant links between synonyms, deletes the redundant links to synonyms, and deletes the redundant links from synonyms;
-;when deleting from the SYNONYM relation, the filter avoids loss of a link to a cited case, and avoids loss of a link from a citing case.
In 1991 the filter was developed without using citing_offset and sited_offset attributes. Thus we were "overfiltering" - and were losing the ability to follow different issues in a same case. In the appendixes of this paper we present an improved filter that avoids the overfiltering.
To describe the model we use the Update Protocol Model notation from Carlson [1991] with some slight modifications, given in APPENDIX 1.
The improved Update Protocol Model of the Transaction Filter in Front of a Full, Semantically Non-redundant Knowledge Database for a Case Law Hypertext System with Citation Links consists of four statements - INSERT for the LINK relation, INSERT for the SYNONYM relation, DELETE for the LINK relation and DELETE for the SYNONYM relation. We will illustrate how our model works with examples given below. An unique number in braces precedes every example and corresponds to the number in braces that precedes the corresponding model structure in the appendixes. All possible cases of insertion and deletion are illustrated. The ease the reading of the examples we will use the letters A, B, C, ... to name cases.
APPENDIX 2 presents insertion in the LINK relation. And here we give the corresponding examples:
{1} Avoid insertion of a link from case A to case A.
{2} If a link between case A and case B already exists in the LINK relation then avoid inserting it again provided the citing_offset and the cited_offset of the new tuple are equal to the citing_offset and the cited_offset in the old one.
{3} If a synonym relation between case A and case B or between case B and case A already exists in the SYNONYM relation then avoid inserting a link between case A and case B in the LINK relation.
{4} If a link between case A and case D already exists in the LINK relation and a synonym relation between case C and case A already exists in the SYNONYM relation then avoid insertion of a link between case C and case D in the LINK relation provided the citing_offset and the cited_offset of the new LINK tuple are equal to the citing_offset and the cited_offset of the old LINK tuple.
Similarly, if a link between case A and case D already exists in the LINK relation and a synonym relation between case A and case C already exists in the SYNONYM relation then avoid insertion of a link between case C and case D in the LINK relation provided the citing_offset and the cited_offset of the new LINK tuple are equal to the citing_offset and the cited offset of the old LINK tuple.
{5} If a link between case A and case D already exists in the LINK relation and a synonym relation between case B and case D exists in the SYNONYM relation than avoid insertion of a link between case A and case B in the LINK relation provided the citing_offset and the cited_offset in the new LINK tuple are equal to the citing_offset and the cited_offset in the old one.
Similarly, if a link between case A and case D already exists in the LINK relation and a synonym relation between case D and case B exists in the SYNONYM relation than avoid insertion of a link between case A and case B in the LINK relation provided the citing_offset and the cited_offset in the new LINK tuple are equal to the citing_offset and the cited_offset in the old one.
{6} If a link between case A and case B exists already in the LINK relation, a synonym relation between case C and case A in the SYNONYM relation, and a synonym relation between case B and case D in the SYNONYM relation then avoid insertion of a link relation between case C and case D in the LINK relation, provided the citing_offset and the cited_offset in the new LINK tuple are the same as in the old one.
Similarly, if we already have a link between case A and case B in the LINK relation, a synonym relation between case C and case A in the SYNONYM relation, and a synonym relation between case D and case B in the SYNONYM relation then we should not insert a link relation between case C and case D in the LINK relation, provided the citing_offset and the cited_offset in the new LINK tuple are the same as in the old one.
If we already have a link between case A and case B in the LINK relation, a synonym relation between case A and case C in the SYNONYM relation, and a synonym relation between case B and case D in the SYNONYM relation then we should not insert a link relation between case C and case D in the LINK relation, provided the citing_offset and the cited_offset in the new LINK tuple are the same as in the old one.
Similarly, if we already have a link between case A and case B in the LINK relation, a synonym relation between case A and case C in the SYNONYM relation, and a synonym relation between case D and case B in the SYNONYM relation then we should not insert a link relation between case C and case D in the LINK relation, provided the citing_offset and the cited_offset in the new LINK tuple are the same as in the old one.
APPENDIX 3 presents deletion in the LINK relation. And here we give the corresponding examples:
{7} If we have to delete a link between case C and case D from the LINK relation and we have a synonym relation between case C and case A in the SYNONYM relation we should insert a link relation between case A and case D in the LINK relation keeping the same citing_offset and cited_offset.
Similarly, if we have to delete a link between case C and case D from the LINK relation and we have a synonym relation between case A and case C in the SYNONYM relation we should insert a link relation between case A and case D in the LINK relation keeping the same citing_offset and cited_offset.
{8} If we have to delete a link between case C and case D from the LINK relation and we have a synonym relation between case D and case F in the SYNONYM relation we should insert a link relation between case C and case F in the LINK relation keeping the same citing_offset and cited_offset.
Similarly, if we have to delete a link between case C and case D from the LINK relation and we have a synonym relation between case F and case D in the SYNONYM relation we should insert a link relation between case C and case F in the LINK relation keeping the same citing_offset and cited_offset.
APPENDIX 4 presents insertion in the SYNONYM relation. And here we give the corresponding examples:
{9} If a synonym relation between case A and case B already exists in the SYNONYM relation then avoid insertion of a synonym relation between case B and case A.
{10} If we insert a synonym relation between case A and case B we should delete the link between case A and case B in the LINK relation, provided it exists, or we should delete the link between case B and case A, provided it exists.
{11} If we insert a synonym relation between case A and case B in the SYNONYM relation then we have to delete one of the following links, provided they both exist: the link between case F and case A in the LINK relation or the link between case F and case B in the LINK relation.
{12} If we insert a synonym relation between case A and case B in the SYNONYM relation we have to delete one of the following links, provided they both exist: the link between case A and case F in the LINK relation or the link between case B and case F in the LINK relation.
APPENDIX 5 presents deletion in the SYNONYM relation. And here we give the corresponding examples:
{13} If we delete a synonym relation between case A and case B or a synonym relation between case B and case A, and we have a link between case C and case A in the LINK relation, then we have to insert a link relation between case C and case B, keeping the same citing_offset and cited_offset.
{14} If we delete a synonym relation between case C and case D or a synonym relation between case D and case C and we have a link relation between case C and case A, then we should insert a link between case D and case A in the LINK relation, keeping the same citing_offset and cited_offset.
HYPERMAPS
For better navigation the user should be provided with the ability to jump from the full text of a case to a hypermap [Seyer, 1991, p. 97; Jonassen, 1989, p. 62] of the closest surrounding level of cited and citing cases. This hypermap should be supported by our Link Database. On the screen one should see the name of the case being browsed and three windows: a window with the names of the synonym cases, a window with the names of the cited cases and a window with the names of the citing cases. The user should have the option to move to any node name in any window of the hypermap and receive the corresponding hypermap. Thus the lawyer is exploring a flexible computer map of the law [Staudt, 1991, p. 182]. This will be a dynamic partial hypermap (the whole map is to big and dense to be presented). We should also keep in mind that "A hypertext system works in collaboration with the user who has the intelligence to understand the semantic concepts of the various nodes and determine which of its outgoing links to follow." [Nielsen, 1990, p. 13] The non-redundant filtered Database enables us to create non-redundant hypermaps. The non-redundant hypermaps are less dense and easier to navigate. A controlled experiment is needed to determine what is the expected degree of simplification.
Jumping to one of our new hypermaps accomplishes shepardizing simultaneously. This technique should work much faster than the current ones, because shepardizing of all parallel publications is achieved at one single step.
At any time a jump to the full text of the current node should be available.
If needed the collapsed (non-redundant) map should be exploded and presented to the user.
While reading the full text of a case the user should be provided with embedded citing-cited links and an optional window with citing-cited links to the displayed portion of the given case. This has not been provided by any system yet. We can achieve it easily due to the supporting Database. Jumping in both cited and citing directions should be available.
To avoid getting "lost in hyperspace" a list of all nodes already visited in the research should be maintained.
HOW DO WE OBTAIN INPUT FOR THE LINK AND SYNONYM RELATIONS
There are two possible input sources for the LINK and SYNONYM relations - Shepard's Citators and automated linking. Both approaches have plusses and minuses.
If we start from Shepard's Citators their data should be reorganized. To determine the proper offset of the start of the links, a bridge to a full text case system should be maintained. This is slow and expensive. Also the update delay of the hypertext system will include the waiting time for the availability of Shepard's information.
In the case of automated link finding discovery of the type of the treatment of the cited case is not achievable with the currently known methods and tools. Sophisticated software should be developed to do this. At the same time as soon as the text of the case becomes available it could be processed.
AUTOMATED LINK MAINTENANCE
Manual linking is useful for small hypertext projects with slow changes. For systems with a large volume of dynamically changing information like the case law, automated link maintenance is needed.
NEW DATA MODEL
Studies should be done to determine the best data model for a modern case law hypertext system. All possible candidates for nodes (whole cases, single case paragraphs, single case pages, single issues, etc.) should be tried. The results might show better performance of an issue organized system than of a case organized one.
BRIDGE TO ARTIFICIAL INTELLIGENCE TECHNIQUES
We also see a bridge to Artificial Intelligence techniques. A system could be designed so that for a given case it automatically follows all cited and citing links and shepardizes the nodes to check which of them are followed and which overruled and mark differently the supporting and opposing paths on the hypermap. Although the hypermap might be complex, once processed and properly marked it may become much more readable and helpful. This is another way to speed up and simplify the hypertext navigation.
CONCLUSION
We have presented an approach for simplifying navigation in case law hypertext information through the elimination of knowledge redundancy in the database supporting the hypertext presentation and navigation. The problem was approached by creating an update protocol model of a transaction filter in front of the database. To the best of our knowledge such an approach to this problem has not been discussed in the literature yet. The model should be further extended with update and select statements.
The proposed changes in the case law research technologies will provide many advantages: reduced research time, reduced cost, easier navigation, use of same technique for following of citation links in both directions, combining navigation with shepardizing, faster and uniform update.
The huge volume of case information and the enormous number of citation links makes us believe that the application of the proposed hypertext organization of the information is achievable only in very large and expensive projects, such as WESTLAW, LEXIS, or SHEPARD'S. None of the commercially available hypertext packages seems to be directly applicable for the proposed technology so a software application appropriate for such a huge dynamic database must be specially developed. Although the proposed improvements could be implemented as a separate stand alone service with on-line jumps in the available on-line full text services, it seems that better results could be achieved if the existing full text services adopt and implement them. Processing of the whole amount of ASCII code of the full text of all cases might be needed.
ACKNOWLEDGEMENTS
We would like to thank Mickie Voges, Professor of Law and Director of the Legal Information Center, IIT Chicago - Kent College of Law, Ronald Staudt, Professor of Law and Director of Computer Development, IIT Chicago - Kent College of Law, Michael R. Marget, Administrative Partner of Katten Muchin & Zavis, Chicago, Thomas J. Dimitroff, Attorney at Law at Ronald R. Delmenico & Assoc., Chicago, Loren D. Jones, Senior Applications Consultant at Automation Partners, Chicago, Ania M. Frankowska, Attorney at Law at Altenheimer & Gray, Chicago, and James Sprowl, Attorney at Law at Fitch, Even, Tabin & Flannery, Chicago, for their support, willingness to discuss the ideas presented in this paper, and to read prior drafts of it.
BIBLIOGRAPHY
A Uniform System of Citation. (1991) 15th Edition. Cambridge, MA: The Harvard Law Review Association.
Carlson, C. Robert and Adarsh K. Arora. (1985) Toward the Next Generation of Data Modeling Tools. IEEE Transactions on software engineering, Vol. SE-11, No. 9, September.
Carlson, C. R. (1991) Advanced Data Base Organization. Viking technologies, Inc.
Cohen, Moris, Robert Bering and Kent Olson. (1989) Finding the Law. An Abridged Edition of "How to Find the Law", 9th Ed., St. Paul: West Publishing Co.
Gibney, Jim. (1989) Shepard's Expanding in Springs. Denver Post, Jan. 6, 1989.
Johnson, David. (1991) Building and Using Hypertext Systems in the Practise of Law. In: From Yellow Pads to Computers. Ed. Kathryn Braeman and Fran Shellenberger. Chicago: American Bar Association.
Jonassen, David. (1989). Hypertext/Hypermedia. Englewood Cliffs, NJ: Educational Technology Publications.
Manov, Alexander. (1991) Update Protocol Model of a Transaction Filter in Front of a Full, Semantically Non-redundant Knowledge Database For a Case Law Hypertext System With Citation Links. CS 525 Research Report. Computer Science Department, Illinois Institute of Technology, Chicago.
Maroonbook. (1989) University of Chicago.
Martin, James. (1990) Hyperdocuments and How to Create Them. Englewood Cliffs, New Jersey: Prentice Hall.
Nielsen, Jakob. (1990) Hypertext and Hypermedia. San Diego, CA: Academic Press Inc.
Seyer, Philip. (1991) Understanding Hypertext. Concepts and Applications. Blue Ridge Summit, PA: Windcrest Books.
Staudt, Ronald. (1991) Legal Mindstorms: Lawyers, Computers and Powerful Ideas. Jurimetrics Journal of Law, Science and Technology, Vol. 30, No. 2, Winter 1991, pp. 171 - 185.
Tapper, Colin.(1982) An Experiment in the Use of Citation Vectors in the Area of Legal Data. Noris (36). Norwegian Research Centre for Computers and Law, University of Oslo, Oslo: Universitetsforlaget.
APPENDIX 1
UPDATE PROTOCOL MODEL NOTATION
UPDATE - PROTOCOL ::=
PROTOCOL-CONTEXT-LIST
[CONSTRAINT-EXPRESSION-LIST]
[TRIGGER-EXPRESSION-LIST]
PROTOCOL - CONTEXT ::=
"SPECIFIC UPDATE STATEMENT
(INSERT, DELETE, REPLACE)
FOR A SPECIFIC RELATION"
CONSTRAINT - EXPRESSION ::=
PRECOND PREDICATE EXPRESSION |
POSTCOND PREDICATE-EXPRESSION
PREDICATE-EXPRESSION ::=
[RANGE-EXPRESSION]
BOOLEAN-EXPRESSION
RANGE-EXPRESSION ::=
[QUANTIFIER] TUPLE-VARIABLE
IN RELATION-NAME
[RANGE-EXPRESSION]
QUANTIFIER ::= EXIST | FOR_EVERY | NOT_EXIST
TRIGGER-EXPRESSION ::=
IMPLIES { UPDATE-STATEMENT |
PREDICATE-EXPRESSION }
APPENDIX 2
INSERTION IN THE LINK RELATION
INSERT l_new in LINK
{1} PRECOND l_new [citing_case] NOT_EQUAL l_new [cited_case]
{2} PRECOND NOT_EXIST l_old IN LINK |
l_new [citing_case] = l_old [citing_case]
AND l_new [cited_case] = l_old [cited case]
AND l_new [citing_offset] = l_old [citing_offset]
AND l_new [cited_offset] = l_old [cited_offset]
{3} PRECOND NOT_EXIST s IN SYNONYM |
( l_new [citing_case_id] = s [case_a_id]
AND l_new [cited_case_id] = s [case_b_id] )
OR ( l_new [cited_case_id] = s [case_a_id]
AND l_new [citing_case_id] = s [case_b_id] )
{4} PRECOND NOT_EXIST l_old IN LINK AND NOT_EXIST s IN SYNONYM |
l_old [cited_case_id] = l_new [cited_case_id]
AND l_old [citing_offset] = l_new [citing_offset]
AND ( ( s [case_a_id] = l_new [citing_case_id]
AND s [case_b_id] = l_old [citing_case_id] )
OR ( s [case_b_id] = l_new [citing_case_id]
AND s [case_a_id] = l_old [citing_case_id] ))
{5} PRECOND NOT_EXIST l_old IN LINK AND NOT_EXIST S IN SYNONYM |
l_new [citing_case_id] = l_old [citing_case_id]
AND l_new [cited_offset] = l_old [cited_offset]
AND ( ( s [case_a_id] = l_new [cited_case_id]
AND s [case_b_id] = l_old [cited_case_id] )
OR ( s [case_b_id] = l_new [cited_case_id]
AND s [case_a_id] = l_old [cited_case_id] ))
{6} PRECOND NOT_EXIST l_old IN LINK AND NOT_EXIST s1, s2 IN SYNONYM |
( ( l_new [citing_case_id] = s1 [case_a_id]
AND s1 [case_b_id] = l_old [citing_case_id]
AND ( ( l_old [cited_case_id] = s2 [case_a_id]
AND s2 [case_b_id] = l_new [cited_case_id] )
OR ( l_old [cited_case_id] = s2 [case_b_id]
AND s2 [case_a_id] = l_new[cited_case_id])))
OR ( l_new [citing_case_id] = s1 [case_b_id]
AND s1 [case_a_id] = l_old [citing_case_id]
AND ( ( l_old [cited_case_id] = s2 [case_a_id]
AND s2 [case_b_id] = l_new [cited_case_id] )
OR ( l_old [cited_case_id] = s2 [case_b_id]
AND s2[case_a_id] = l_new[cited_case_id]))))
AND l_new [citing_offset] = l_old [citing_offset]
AND l_new [cited_offset] = l_old [cited_offset]
APPENDIX 3
DELETION IN THE LINK RELATION
DELETE l_old from LINK
{7} IMPLIES
INSERT l_new in LINK
l_new [citing_case_id] = s [case_b_id]
l_new [cited_case_id] = l_old [cited_case_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST s IN SYNONYM |
s [case_a_id] = l_old [citing_case_id]
INSERT l_new in LINK
l_new [citing_case_id] = s [case_a_id]
l_new [cited_case_id] = l_old [cited_case_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST s IN SYNONYM |
s [case_b_id] = l_old [citing_case_id]
{8} IMPLIES
INSERT l_new in LINK
l_new [citing_case_id] = l_old [citing_case_id]
l_new [cited_case_id] = s [case_b_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST s IN SYNONYM |
s [case_a_id] = l_old [cited_case_id]
INSERT l_new in LINK
l_new [citing_case_id] = l_old [citing_case_id]
l_new [cited_case_id] = s [case_a_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST s IN SYNONYM |
s [case_b_id] = l_old [cited_id]
APPENDIX 4
INSERTION IN THE SYNONYM RELATION
INSERT s_new in SYNONYM
{9} PRECOND NOT_EXIST s_old IN SYNONYM |
s_old [case_a_id] = s_new [case_b_id]
AND s_old [case_b_id] = s_new [case_a_id]
{10} IMPLIES
DELETE l FROM LINK
PRECOND EXIST l IN LINK |
( l [citing_case_id] = s_new [case_a_id]
AND l [cited_case_id] = s_new [case_b_id])
OR ( l [citing_case_id] = s_new [case_b_id]
AND l [cited_case_id] = s_new [case_a_id])
{11} IMPLIES
DELETE l2 FROM LINK
PRECOND EXIST l1, l2 IN LINK |
l1 [citing_case_id] = l2 [citing_case_id]
AND( ( l1 [cited_case_id] = s_new [case_a_id]
AND l2 [cited_case_id] = s_new [case_b_id])
OR ( l1 [cited_case_id] = s_new [case_b_id]
AND l2 [cited_case_id] = s_new [case_a_id]))
{12} IMPLIES
DELETE l2 FROM LINK
PRECOND EXIST l1, l2 IN LINK |
l1 [cited_case_id] = l2 [cited_case_id]
AND
( ( l1 [citing_case_id] = s_new [case_a_id]
AND l2 [citing_case_id] = s_new[case_b_id])
OR( l1 [citing_case_id] = s_new [case_b_id]
AND l2[citing_case_id] = s_new[case_a_id]))
APPENDIX 5
DELETION IN THE SYNONYM RELATION
DELETE s FROM SYNONYM
{13} IMPLIES
INSERT l_new in LINK
l_new [citing_case_id] = l_old [citing_case_id]
l_new [cited_case_id] = s [case_b_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST l_old IN LINK |
l_old [cited_case_id] = s [case_a_id]
INSERT l_new in LINK
l_new [citing_case_id] = l_old [citing_case_id]
l_new [cited_case_id] = s [case_a_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST l_old IN LINK |
l_old [cited_case_id] = s [case_b_id]
{14} IMPLIES
INSERT l_new in LINK
l_new [cited_case_id] = l_old [cited_case_id]
l_new [citing_case_id] = s [case_b_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST l_old IN LINK |
l_old [citing_case_id] = s [case_a_id]
INSERT l_new in LINK
l_new [cited_case_id] = l_old [cited_case_id]
l_new [citing_case_id] = s [case_a_id]
l_new [citing_offset] = l_old [citing_offset]
l_new [cited_offset] = l_old [cited_offset]
PRECOND EXIST l_old IN LINK |
l_old [citing_case_id] = s [case_b_id]
![[Table des matièes]](/fr/equipes/technologie/conferences/aqdij/img/up.gif)