This interactive Neo4j graph tutorial covers exchanges of documents that have legal consequences scenarios.
Table of Contents
-
Introduction
-
Scenario
Organizations create large numbers of "legal" documents. These docs define relationships of the organization with persons outside the organization such as customers, suppliers and regulators, and within the organization such as employees, owners and subsidiaries. While there are doc-less solutions to managing some of these relationships (e.g., stock markets and online ordering) organizations still depend on docs for many of their relationships. Docs are often done as free-standing word processing (Word) or similiar flat-file formats such as PDF. The docs collectively form a description of the organization, but as a collage rather than a unified picture. The levels of redundancy and inconsistency are high, as are delays, cost and errors. Companies lose billions in cost, delay, lost opportunities, error and fraud. In litigation, they spend large sums to organize materials after the fact. '''
Most of the problem can be solved by looking beyond the individual documents to the collections of them, the connections among them and the persons and things on which they act. In other words, to reflect their context in a graph.
The end of one person’s graph is the beginning of the next person’s. The edges between these describe relationships among persons and with respect to properties. The legal nature of these edges can be expressed as relationships among nodes of legal text, a legal "code" in the traditional sense of the word.
The full solution is a distributed, user-controlled graph, with instances for each user and for resources such as legal codes.
-
In its sales process, an organization repeatedly creates and negotiates complex documents with customers, such as loan, license or leasing agreements. In some cases it starts from a common master. In others, where the documentation is managed by outside law firms, the forms may be quite different for similar transactions. In both situations, there is back and forth with the customer of flat-text formats documents, in successive iterations. Very large numbers of copies of essentially the same documents are made, a tremendous amount of repetitive reading is done, and all participants usually have access to and have to manage all of the information rather than just what is relevant to them and new.
-
In a second, related scenario, organizations seek to have confidential discussions or submit confidential information to one another. One of them creates a form of agreement that it believes will be competent, favorable to it and roughly acceptable to the other party. In the same process of iteration as before, lawyers for the two parties go back and forth validating the terms of the agreement. While the document is much shorter than in the preceding scenario, the delay, aggrevation and potential error are substantial in aggregate, particularly as the discussions do not themselves generate revenues.
-
In a third scenario, an organization seeks to enforce one of the agreements above. Because the text is unique to the transaction, the other party has substantial opportunities to make arguments about the meaning of the text, in good faith or otherwise.
-
In a fourth scenario, an organization or benefactor seeks to improve the efficiency and outcomes for a group of others. This group might be suppliers, customers, business partners, or category of persons such as entrepreneurs or software engineers.
-
In a fifth scenario, a shared administration (agency, court system or hierarchy) seeks to manage decision-making through a system of document filings. This is often referred to as "bureacracy," which combines the French word for "desk" and the Greek word for "power."
Graph databases offer new methods of expressing relationships. Asciidoc, HTML and other text media that can be worked with generic tools offer opportunities to focus on content and use sophisticated data methods. Wikis, git, email and similar tools allow efficient collaboration.
Graphs allow flexible, compact expression of complex relationships. Traversals allow finding relevant information and showing connections, individual and aggregate.
Legal docs are docs. Docs are documentation. Documentation is a form of code. @mojavelinux. When legal docs are treated as code, the commonalities and inconsistencies can be discovered, refactored and managed.
Legal docs are "run" on gray matter. Often the grayer (the hair of) the gray matter, the more authoritative. On-the-fly testing is difficult. Ordinarily, the gray matter that counts most (a yet-to-be-seated judge or jury) is not available at the time the code is created. Gray matter requires a support system that is insanely complex and subject to such variables as what its bio-support system had for breakfast. The best way to predict the outcome of an actual run of the code is to aggregate prior runs in a kind of neural network. Precedent. The "Delaware effect." '''
becomes:
CREATE (P1 {KV:'Name.First=James<br>Name.Last=Hazard'})
CREATE (DM1 {name:'ABA_MSPA'})-[r:URL]->(URL1 {href:'abanet.org/abastore/index.cfm?section=main&fm=Product.AddToCart&pid=5070636', format:'OrderForm'})
CREATE (DL1 {name: 'NIH_Models'})
CREATE (URL2 {href:'beta.commonaccord.org/wiki/Org_ABA/MSPA_V2_Agt_Library', format:'.Cmaac'})
CREATE (URL3 {href:'www.ott.nih.gov/sites/default/files/documents/docs/cda.doc', format:'.Doc'})
CREATE (DM1)-[:URL]->(URL2)
CREATE (DL1)-[:URL]->(URL3)
CREATE (P1)-[:LIKE]->(DM1)
CREATE (P1)-[:LIKE]->(DL1)
CREATE (URL4 {href:'www.brown.edu/research/policies-and-compliance',format: 'DList',comment:''})
CREATE (URL5 {href:'www.cctec.cornell.edu/forms/index.php',format: 'DList',comment:'Cornell Tech Transfer folks'})
CREATE (URL6 {href:'research.ucdavis.edu/f/f',format: 'DList',comment:''})
CREATE (URL7 {href:'web.mit.edu/tlo/www/misc/forms.html ',format: 'DList',comment:'MIT Tech Licensing Office - NDAs, etc.'})
CREATE (URL9 {href:'www.clausebuilder.org',format: 'DTool',comment:'American Arbitration Assn (adr.org) Clause Building Tool'})
CREATE (URL10 {href:'abanet.org/abastore/index.cfm?section=main&fm=Product.AddToCart&pid=5070636 ABA Model Share Purchase Agreement]',format: 'Book',comment:'ABA - trying to find a list of all their materials. This MSPA is also [[{CmA}Org_ABA/MSPA_V2_Agt_Library]]'})
CREATE (URL11 {href:'books.google.com/books?id=Se6WohjS83sC&printsec=frontcover&dq=inauthor:%22American+Bar+Foundation.+Corporate+Debt+Financing+Project%22&hl=en&sa=X&ei=AXKZUt24NYScjALj-4CwBg&ved=0CEUQ6AEwAQ#v=onepage&q&f=false American Bar Foundation - Model Debenture Indenture]',format: 'DList',comment:'This project from the age of typewriters casts a long shadow. See the discussion of the rationale at page 3 of this reference.'})
CREATE (URL12 {href:'acc.com/contracts/draftingbenchmarking.cfm',format: 'DSite',comment:'Association of Corporate Counsel sample documents and KM Standards project - member sign-in wall'})
CREATE (URL13 {href:'aia.org/contractdocs/index.htm',format: 'DSite',comment:'AIA Docs on Demand'})
CREATE (URL14 {href:'aipn.org',format: 'DL',comment:'Petroleum industry. Member sign-in wall.'})
CREATE (URL8 {href:'astaspice.org/i4a/pages/index.cfm?pageid=1',format: 'DSite',comment:'Spice Association Model Contracts - behind member login wall'})
CREATE (DS2 {href:'http://web.mit.edu/tlo/www/misc/forms.html'})
CREATE (P1)-[:LIKE]->(DS2)
CREATE (URL15 {href:'www.ott.nih.gov/sites/default/files/documents/pdfs/cda.pdf', format:'.pdf'})
CREATE (URL3)-[:HOSTS]->(URL15)
RETURN *
//RETURN URL15.href