Common Data Model Entities
The entities that make up the Common Data Model are Legal Data Models (logical entities), Legal Data Objects (physical entities), and Legal Snippets, which are aggregates of Legal Data Objects with a unitary semantic.
Legal Data Object
A Legal Data Object is a physical entity that can be serialized (i.e., stored, transmitted, and retrieved) in multiple file formats (JSON, XML, etc.) and materialized in any programming language.
The design of Legal Data Objects focuses on documents but is also used to represent arbitrary data structures in other legal content experiences such as Cases, Workflows, Dashboards, predictive analyses, etc. Looplex has developed numerous application programming interfaces (APIs) to assist in processing Legal Data Objects.
Legal Snippets
Legal Data Objects can be aggregated or composed with other Legal Data Objects. When a set of Legal Objects has a unitary semantic meaning, it becomes a Legal Snippet.
Values of an object reported against another metadata are just that: a value, whether numerical, monetary, textual, graphical, or even an image or visual element. For example, a 10% value might be associated with the concept of a penalty or a fine clause.
However, this value-concept pair lacks significant meaning unless the data is provided with additional contextual information. For instance, the fine relates to the violation of which clause? What is the base value to which this percentage applies—what has already been paid, the total price of the service, or something else? Is it recurring, such as a daily fine, or applied only once? And so on.
Combining the concept of a Legal Data Object with the values and concepts of other Legal Data Objects capable of instantiating a comprehensible and isolable rule or set of rules within a document creates the complex object called a Legal Snippet.
A Legal Snippet can be a contractual clause, a logical proposition or factual claim in the cause of action of a petition, a sequence of arguments, documents, or evidence supporting a specific proposition (subsidiaries), a timeline event in a case, and many other minimal instantiations.
Since the law is essentially expressed in natural language, a Legal Snippet is almost invariably associated with a combination of constant text, labels (displayNames), and variables derived from already mapped concepts.
However, Legal Snippets can also be manifested as interface visual elements (Legal Visual Objects), which should be considered if they have their own semantic meaning.
Legal Topic
A set of Legal Snippets can be aggregated into a Topic (or Branch in Lawtex). It becomes an identifiable complex object whenever it can be assigned a specific semantic meaning to that aggregation. A topic could be a chapter (or clause) containing the rules for transferring ownership of real estate, the proximate cause of action in an initial petition, or a set of statements and guarantees from one of the parties, among other examples.
Document
Finally, a set of Topics can be composed into a Document. The Document is the instantiation of topics and snippets that lawyers and laypeople commonly associate with legal content artifacts: a sales contract, a contestation petition, an ordinary law, a memorandum, an audit letter, etc.
The Document is thus a view of instantiation of a business or legal matter. However, a combination of Legal Data Objects can generate other views with specific semantic meanings for users, such as a Dashboard or Workflow diagram.
Legal Solution
A combination of Documents and other artifacts composed of different BI views, Workflows, Cases, or even functions, such as an RPA, constitutes a Solution or Legal Solution whenever it is possible to assign a greater semantic meaning to a given legal experience.
A Solution could be a packaged and parameterizable flow for supplier contract management, automation of stages and management of an execution judicial process or inventory, governance of entities and corporate governance of a group of companies, or many other examples.
For more information on aggregation design patterns, see here.
Legal Data Model
The Legal Data Model is a logical entity specifying how to formally describe the schema of elements of a Legal Data Object (LDO) and can be treated as a programming object.
The schema of a Legal Data Model is an abstract representation of the characteristics of an entity or object and its relationship with other objects. Creating the schema of a Legal Data Model involves analyzing its structure and defining each structural element found.
Legal Functions
Legal Functions are not part of the Common Data Model (they are not data schemas and are not data) but need to be mentioned.
Legal Functions are stored in the EJ-Verse and are also objects (code) that take the Cartesian product of Legal Data Objects and alter one of their dimensions, transforming them into another Legal Data Object. Examples of Legal Functions include transclusions, sendMail, visual law Render, JS Box, and others, which can be found on the technical references page of Looplex.
Logical Entities: Legal Data Model
Glossary of definable objects
Trait - Annotation objects that express semantic meaning. Traits can contain a set of named argument values.
DataType - A named collection of traits to represent commonly used concepts combining data format, data value constraints, and semantic meanings. Example data types include integer and firstName.
Attribute – A simple (data type) or complex (entity) typed and named description of data values used to represent a specific idea or purpose. For example, the data type firstName can create an attribute called partnerFirstName.
Entity - A container that gathers a collection of traits and attributes so the collection represents a logical concept, business process, event, or other object. Examples include Customer, Purchase, and Task.
Purpose - A named collection of traits to represent commonly used reasons or purposes that an attribute serves in an entity. Purpose may be part of the entity definition to identify ideas like “default display text,” “primary key,” or “default sorting column.”
AttributeGroup - A named collection of attributes that functions as a macro.
ConstantEntity - An association between an entity schema and a constant array of data values that exist only in metadata documents. Used to represent lookup tables.