ContractFrames: Bridging the gap between
Natural Language and Logics in Contract Law ?
Marı́a Navas-Loro1 (orcid.org/0000-0003-1011-5023), Ken Satoh2 , and Vı́ctor
Rodrı́guez-Doncel1 (orcid.org/0000-0003-1076-2511)
1

Ontology Engineering Group, Universidad Politécnica de Madrid, Spain{mnavas,vrodriguez}@fi.upm.es
2
Principles of Informatics Research Division, National Institute of Informatics
ksatoh@nii.ac.jp

Abstract. This paper introduces ContractFrames, a framework able totranslate natural language texts referring to the different events related
to the status of a purchase contract to logic clauses from a legal reasoning
system called PROLEG. Diverse frames and rules have been developed
for the extraction and storage of this information before its conversion
to logic clauses. Our framework uses natural language tools and rules toextract relevant information, store it in the form of frames, and return
the PROLEG version of the input text. Also an ontology, called theContract Workflow Ontology, has been developed to represent all the
relevant information of the events related to a contract. The frameworkhas been tested in a syntethic dataset, and shows promising results.
Keywords: Legal NLP · PROLEG · Contract Life-cycle · Legal Ontology.

1Introduction

Making machines to understand commercial contracts is a challenging and multidisciplinary task. Natural Language Processing (NLP) techniques are required
to analyze different documents to extract relevant information, which can be
expressed in very different formats and records. Once obtained, this informationneeds to be properly represented, via some knowledge representation system. Finally, reasoning methods are also required to extract new knowledge consideringcollected information.
Focusing on the legal domain, there exist different proposals for formalizing
legal information in the form of logical predicates. We find among them PROLEG[25], a legal reasoning system able to represent and reason about contract status?

This work was partially supported by JSPS KAKENHI Grant Number 17H06103
and by a project with funding from the European Union’s Horizon 2020 researchand innovation programme under grant agreement No 780602. It has been also partially supported by a Predoctoral grant from the I+D+i program of the Universidad
Politécnica de Madrid. This work has been done during an internship funded by the
National Institute of Informatics.

M. Navas-Loro et al.

and derive information such as its validity or the right or reason of a rescission,
among others. Nevertheless, in spite of having all the contract law logic needed
already coded, how to automatically transform the input text into logic facts
remains still as an open and important challenge. Currently, the translation of
texts describing contract events must be manually coded, being therefore very
inefficient in terms of cost and time, and remaining unsolved the fact that any
ulterior change would need manual curation. A bridge between NLP and thislogical system is therefore needed to automatically retrieve all relevant facts fromtext to populate the PROLEG fact knowledge base.
In this paper, we propose a framework, called ContractFrames, able to translate natural language texts referring to the different status of a purchase contract
into PROLEG clauses. These texts are not normative texts nor regular texts(being both types extensively studied in previous literature), but some natural
language text at a mid point between regular language and pure legal language;
an example of one of these texts can be found in Fig. 1, along with its translation into PROLEG. To the aim of expressing these texts in a full logical legal
language, we have developed different frames3 and rules for representing andextracting the relevant information that will feed the PROLEG reasoner. These
resources are integrated into a natural language processing pipeline able to takea natural language text as an input and return its PROLEG version. Also an
ontology, called the Contract Workflow Ontology, is proposed for representing
the extracted information in a standard way.
‘person A’ bought this real estate from ‘person B’ at the price of 200000 dollars bycontract0 on 1/January/2018. But ‘person A’ rescinded contract0 because ‘person A’
is a minor on 1/March/2018. However, this rescission was made because ‘person B’
threatened ‘person A’ on 1/February/2018. It is because ‘person B’ would like to sellthis real estate to ‘person C’ in the higher price. So, ‘person A’ rescinded rescission ofcontract0 on 1/April/2018.
minor(personA).
agreement_of_purchase_contract(personA,personB,this_real_estate,200000,2018
year 01 month 01 day,contract0).
manifestation_fact(rescission(contract0),personA,personB,2018 year 03 month 01 day).
fact_of_duress(personB,personA,rescission(contract0),2018 year 02 month 01 day).
manifestation_fact(rescission(rescission(contract0)),personA,personB,2018 year
04 month 01 day).

Fig. 1. Example of an input text and its expected output.

The remain of this paper is as follows. Section 2 presents related work. Section
3 introduces problem and the reasoning system PROLEG, describing the clauses
on which the natural language will be translated. In Section 4, an analysis of
the main challenges found is done. Section 5 presents how our framework tackled
these problems, outlining the different steps and its main functionalities. Section
3

According to Minsky [19], a frame is ‘a data-structure for representing a stereotyped
situation’.

ContractFrames: Bridging the gap between Natural Language and Logics

6 presents the outputs of our framework. Finally, Section 7 outlines the main
points of our work along with some conclusions and next steps.

2

Related work

Although work on extracting rules in the legal domain has been extensively
tackled in literature [8, 9, 21, 27], most efforts focus on regulations and normative
text, but not on semi-formal documents dealing with the binding agreements.
The work by Biagioli et al. [3] includes for instance the idea of representing
different types of provisions in normative texts as logical structures or frames;
nevertheless, these frames output are XML files, not logical clauses, where eachprovision has some metadata arguments independent to other provisions. On
the other hand, Araujo et al. [1] consider a series of legal events in Brazilian
Portuguese. Using domain and linguistic knowledge, as well as ontologies, they
develop rules for detecting these events via an OWL reasoner. Similarly, Wyner
et al. [27] use different NLP tools and resources such as VerbNet [26] to extract
events and some related roles from Regulations in English. Other approaches
also use ontologies and resources such as WordNet [18] for obtaining semantic
information about concepts of interest, such as obligation, permission and prohibition [8]. Although semantics is a common approach [1, 8, 15, 27], it must be
noted that not all proposals rely on NLP or semantics, such as the work by
Moulin et al. [21]. Finally, the work by Nakamura et al. [22], later extended todeal with references [14], present a methodology to translate natural language
Japanese law texts to logical forms following the Davidsonian Formalization.
The representation of contracts in a digital form has been made in manydifferent forms for different purposes, but none of them matches well enough therepresentation of PROLEG clauses. The contract itself has been represented indifferent XML forms, from the well structured OASIS eContracts [16] format tothe practical ebXML agreements or the RuleML based business rules [11]. Most
efforts to represent the contract in a formal way lean towards defining deontic logic systems, such as Governatori’s Business Contract Language intended
to address contract violations [10], Daskalopulu’s approach to tackle subjective
visions on the contract [6] or Prisacariu’s effort to consider temporal aspects[23]. However, not many efforts focus on the contract within a workflow, being among the most interesting the Kabilan’s ontologies [13] and Molina’s [20].
Kabilan identifies at least three perspectives under which a contract can be analyzed: the legal one, the business one, and the information systems one. Fromeach of these perspectives, it is not trivial to abstract a common model for the
representation of contracts and contract workflows. Commercial law is different
from jurisdiction to jurisdiction, each organization has its own in-house business policies with respect to contract management and information systems are
simply too diverse.
When it comes to representing contracts with the purpose of publishing andlinking contract information, contract formats are even more scarce. LKIF [12]

M. Navas-Loro et al.

devotes a class to Contract4 , but provides no support to contract workflows.
FrameNet [2] could be used to represent contracts to some extent (using elements such as Documents 5 or Being obligated 6 in FrameNet), but these options
do no reflect the information needed for the related PROLEG clauses. Similarly,
the Commerce buy 7 frame provides a lot of information on the context of thepurchase, but does not consider the contract, focus of our research. The representation of contracts as RDF is not supported by any massively adopted ontology,
and there are not many standards or public ontology-based specifications tochoose from. One of the possible choices is the Media Contract Ontology [24],ISO standard to support the representation of contracts as RDF but nonethelessdomain-specific.

3

The problem

In this section, we will present the problem and introduce the frames developed for representing it, as well as the reasoning system PROLEG. Let us start
analyzing the example exposed in Fig. 1.

ActionItem

Manifester
Manifestee

Date
Contract
Price

Rescission
Frame

Date

DuressFrame

Date

Purchase
Frame
Currency
Manifester
Buyer
SellerManifestee

Fig. 2. The three different frames in the framework (Purchase, Rescission and Duress)and how they interact. An action can be a contract or a rescission, therefore a rescission
can be of a contract or of another rescission. A duress is also necessarily attached to a
rescission.

In the input text, we find different events related to the status of the contract. First, the purchase is uttered via a contract; then, a rescission is claimed,4

http://www.estrellaproject.org/lkif-core/norm.owl#Contract
https://framenet2.icsi.berkeley.edu/fnReports/data/frameIndex.xml?frame=Documents
6
https://framenet2.icsi.berkeley.edu/fnReports/data/frameIndex.xml?frame=Being obligated7
https://framenet2.icsi.berkeley.edu/fnReports/data/frameIndex.xml?frame=Commerce buy
5ContractFrames: Bridging the gap between Natural Language and Logics

adducing the fact that one of the parts was a minor. In the third sentence, a factof duress (threatening) on one of the parts is issued. Additionally, the cause of
the ending of the contract is expressed in the following sentence. Finally, in thelast sentence the former rescission is rescinded, what makes the contract valid
again. It must be noted that we are actually not interested in the informationon the fourth sentence, since we just want information about the contract status
and the ‘real reasons’ behind the fact of its rescission are not relevant, but justthe fact of it being rescinded at some point of time. For modeling the relevant
situations that can involve a contract, we developed three main frames, depicted
in Fig. 2. The framework is also able to extract other relevant events to thesystem, such as if any of the parts involved in the contract is a minor, but mostevents are related to these three frames. Some examples of events involving theseframes are for instance an agreement of a purchase contract, a manifestation ofa rescission or the expression of a duress. The expected representation in PROLEG of the facts relevant to the contract status expressed in the example canbe found in Fig. 1. With these facts and the contract law information encoded
in its rule base (see Fig. 3), the PROLEG system would be able to derive legal
consequences of each of the facts, leading to new conclusions such as if the buyer
has the right of handling the goods purchased at some concrete point in time orif a contract or a rescission becomes invalid for some reason, such as the existence of duress or some legal incompatibility, such as one of the parts involved
being a minor. In Fig. 4 a visualization of this reasoning can be found.

right_to_handing_over_the_goods(Buyer,Seller,Object,ContractID)<=
valid_purchase_contract(Buyer,Seller,Object,Price,Tcontract,ContractID).
valid_purchase_contract(Buyer,Seller,Object,Price,Tcontract,ContractID)<=agreement_of_purchase_contract(Buyer,Seller,Object,Price,Tcontract,ContractID).
exception(
valid_purchase_contract(Buyer,Seller,Object,Price,Tcontract,ContractID),
rescission_by_minor_buyer(Buyer,Seller,ContractID,Tcontract,Trescission)).
rescission_by_minor_buyer(Buyer,Seller,ContractID,Tcontract,Trescission)<=minor(Buyer),manifestation(rescission(ContractID),Buyer,Seller,Trescission),
before_the_day(Tcontract,Trescission).
manifestation(Action,Manifester,Manifestee,Taction)<=manifestation_fact(Action,Manifester,Manifestee,Taction).
exception(
manifestation(Action,Maniester,Manifestee,Taction),
manifestation_by_duress(Threater,Manifester,Manifestee,Action,Taction,Tduress,Trescission)).
manifestation_by_duress(Threater,Manifester,Manifestee,Action,Taction,Tduress,Trecission)<=fact_of_duress(Threater,Manifester,Action,Tduress),before_the_day(Tduress,Taction),
manifestation(rescission(Action),Manifester,Manifestee,Trecission).

Fig. 3. Rulebase of PROLEG.

M. Navas-Loro et al.

Fig. 4. Visualization of the reasoning done by PROLEG from the facts extracted by
our framework.

ContractFrames: Bridging the gap between Natural Language and Logics

4

Analysis of challenges

Before explaining our framework, we will expose in this section the different
difficulties found during the development of the framework. Each one has aletter assigned, so it can be referred in later paragraphs.
[A] Style of the text Legal texts usually use patterns such as “A sells L to B byC”, “Part A established a contract with Part B”, or “‘personB’ threatened ‘person A’”. In these examples, each of the letters are Named Entities that can bemisleading to general NLP tools, that for instance consider A as a determiner,changing the whole grammar structure of the sentence. In our case, a preprocessing was done in order to distinguish among real determiners and ‘A’ parts,
and also to eliminate misleading characters (such as ‘) or blank spaces.
[B] Relevance Differently to other proposals, our aim is not to translate eachsentence of the original text, but to extract just relevant facts to the PROLEG
system. Therefore, not all the sentences in the text are relevant; in fact, some ofthem can be actually misleading.
[C] Factuality Besides relevance, some of the sentences in the text processed do
not refer to actual facts, but to possibilities, intentions or preferences (e.g., ‘A
would like to sell a land to B ’, ‘A preferred to sell it to part D’). In these cases,
some screening should be done in order to prevent these events to enter in ourfacts base.
[D] Paraphrasing There are many different ways to express the information,
both from the syntactical and semantics point of view. While in other domains
a lot of semantic resources are available to palliate this phenomena, the Legal
Domain presents a very specific terminology uneasy to deal with.
[E] Complexity As already reported in previous literature [7], texts in the legal
domain tend to be more complex than texts in other domains. They have higher
parse trees, more words per sentence and different POS distribution. These particularities imply an extra challenge when extracting information from thembeyond the required preprocessing previously mentioned.
[F] Coreferences and nesting In a natural language text, not all the informationof each event is contained in a single sentence. Coreferences are also difficult tohandle, especially when there are several manifestations of a type of event (suchas a rescission). Also, some information is directly not mentioned and must be
inferred using some domain knowledge information. This is the case for instanceof a rescission of a contract; if we know that a contract C involves part A andpart B, and we know there is a rescission of this contract of part A as manifester
but it is not explicitly mentioned who is the manifestee, we can assume thisrole must be Part B. Similarly, the duress manifestation of a rescission must
be coherent with the information we have of this rescission and the contract itapplies to.

M. Navas-Loro et al.

[G] Different information For each of the different events processed we requiredifferent information. That is an important point that implies some ordering in
the rules and preprocessing of the text. An example of this fact is the sentence like
“PersonB rescinded contract because personA was a minor on 1 March 2018.”.
In PROLEG clauses, the predicate minor() has arity one, so there is no dateattached. So even when NLP tools tend to asume that the date mentioned refers
to the verb be and not to rescind (what in fact is linguistically correct and could
also be the inference of a human, is an ambiguous sentence), our framework
should be able to note the difference.
[H] Matching Since some frames are dependent (e.g., a duress must be related
to a rescission), they must be correctly tracked and matched, so the task is notjust about extraction but also about merging.

5

ContractFrames

Our framework ContractFrames makes use of the NLP tool Stanford CoreNLP[17]. We use it for tokenization of the sentences, lemmatization, Part-of-Speech(POS) tagging, Named Entity Recognition (NER) and also for sentence dependence parsing. We also make use of the TokensRegex [4], an annotator thatallows setting rules that produce customized annotations. Differently from otheroptions, such as regex, the rules developed in the TokenRegex format are basedin previous annotators output, such as POS or NER, being therefore more powerful from the semantic point of view. The steps in our framework are explained
below, along with the problems exposed in the previous section that they target:
1. Preprocessing the input text: the first step in our framework deals with problems related to the style of the text and the different information (problems[A] and [G]). The objective of this step is to output a version of the text
easier to be understood by the CoreNLP pipeline. To this aim, the following
functionalities have been implemented, among others:– Algorithm to replace A, ‘person B’, or similar misleading expressions for
the POS-tagger and the parser.
– Replacement of appearances of relevant references like ‘this real state’,that often appear in input texts, to standard strings such as Item1. These
replacements are eventually reversed before producing the final output.
– Standardization of the dates, that might come as ‘dd/Month/yyyy’, aformat that the Stanford CoreNLP temporal tagger (SUTime) is notable to detect.
– Rules to detect the clause with arity one minor(agent), that when foundis added to the list of clauses and deleted from the text to avoid misleading parsing as the one explained in the previous section.
2. Annotation with the CoreNLP pipeline: the annotations include tokenization, sentence splitting, POS-tagging, lemmatization, NER (that includes
SUTime), parse and the application of our event rules via TokensRegex.
The rules developed allows our framework to detect different kind of events

ContractFrames: Bridging the gap between Natural Language and Logics(establishment of contracts, purchases, sales, rescissions, duress...) both inverbal forms (buy, sell, rescind ) or as noun events (purchase, sale, rescission). Each type of event is annotated consequently as a event annotation,so we find the relevant events (problem [B] in the previous section).
3. Parse sentence by sentence: we analyze each sentence separately, assigning
one of each of the possible types of frame. Then we analyze the annotationsof each token separately:(a) If the token has an event annotation, we check if it is negated in thesentence (being therefore not a fact, so we should not transform it into
logic) or if it is an intention or a possibility (in this case, we should
not either consider it), targeting problem [C]. Once we have verified
that it is a fact, we check which type, and then apply different rules tofind each its arguments (if available) and express the information as thecorresponding frame of the sentence. These rules are mainly applied in
the dependency parsing of the sentence, and take into consideration notjust the type of the event but also its form (if it is a noun or a verb,
if it is active or passive). We cover therefore the different paraphrasing(problem [D]) that can express the information relevant for each frame.
Let us analyze for instance the following sentences:(1) landL was sold by PartA to PartB via contractC for 20000 dollars
on 13/October/2017.
(2) On 10/13/2017, PartB established a purchase contractC with PartA
to buy landL at the price of 20000 dollars.
(3) PartA sold landL to PartB by contractC for 20000 dollars on October 13, 2017.
For all of them, the same information is provided, despite of having
different words and syntax; the analysis of the dependencies of eachsentence is depicted in Fig. 5. Therefore, all these three different input
texts imply the same frame (the establishment of a purchase contract)
and their PROLEG output should be the following:
agreement_of_purchase_contract(partB,partA,landL,20000,2017 year
10 month 13 day,contractC).

(b) If the token has any other relevant annotation (namely, it has beentagged as a DATE or MONEY by Stanford CoreNLP annotators or as a
CONTRACT mention by our rules), we store it as relevant informationin the sentence.
Once each token has been analyzed, we check if there is missing information in frames that have been initialized due to some found event. If so, we
complete it with the relevant data we stored (problems [E] and [F]).
4. Once the whole sentence has been processed, we check the information stored
in the frames. If there is any information missing, we look for it explicitly(for instance in the values for DATE and MONEY we stored in the previous

M. Navas-Loro et al.

step for the current sentence), as well as we also check if new information
can complete previous frames. An example of this is the case of a duress: an
expression of duress must be linked to a previous rescission, so we check previously mentioned rescissions and link it to the most suitable one (problem[H]).
5. Finally, once all the sentences have been processed, we complete the information on the final frames using some common sense. Let us imagine for
instance that we have a rescission with Manifester A and Manifestee B,
with a duress where B is the Manifester but with no information on the
text about the threatened. Since we know the two parties in the contract,
we can derive that the Manifestee must be A.
6. Last step involves just transforming the information in our frames in PROLEG clauses, including reversing the replacement done during the preprocessing step. Since all the relevant information has been stored as our standard frames, translation into PROLEG clauses is straightforward (each frame
has one or two clauses whose arguments are among the data in the frame).

nsubjpass
auxpass

NN

VBD

VBN

1 landL was

sold

IN

case

nmod:to
nmod:agent
case

IN

by

nmod:on
punct
nsubj

CD

,

NN

NN

punct

nmod:via

TO

PartA to

case

JJ

DT

case

NN

nmod:forcasenummodIN

CD

PartB via contractC for 20000

NN

det
compound2 On 10/13/2017 , PartB established a purchase

nmod:withcaseNN

nmod:on
case

NNS

IN

NN

.

dollars on 13/October/2017 .

punctadvcl:to

dobj

VBD

IN

IN

contractC with

nmod:at

NN

TO

mark

PartA to

VB

dobj

buy

NN

IN

case
det

DT

landL at the

nmod:of
case

NN

IN

price ofpunct
nmod:ofcase
nummod

CD

NNS

20000

dollars .

NNP

nsubj

3 PartA

VBD

sold

.

dobj

nmod:toNN

TO

landL to

nmod:fornmod:by
case

NN

IN

case

punct

nmod:on

NN

IN

CD

case
nummodPartB by contractC for 20000

NNS

IN

dollars on

case

NNP

nummodpunctnummodOctober

CD ,

CD

.

13 , 2017 .

Open IE:

Fig. 5. CoreNLP online demo’s9 output of the enhanced dependencies of the three example sentences where the challenges of paraphrasing become evident. We can see
for instance how the buyer (PartB ) and the seller (PartA) play different roles in thesentence depending on the voice (active/passive) or the semantics of the verb expressing the purchase frame (buy/sell/establish a contract). Also other information can be
expressed differently, such as the date.

It must be noted that our framework’s NLP pipeline does not involve thecorefence annotator from CoreNLP. Although it was initially included in a firstversion of our framework, we detected that it presented some limitations when
dealing with the same event refered both by using nouns and verbs. While it could9

http://corenlp.run/

ContractFrames: Bridging the gap between Natural Language and Logics

detect that for instance that in “The rescission of the contract was done on 1
February, 2018. This rescission was cancelled later” there was a coreference, it
did not succeed in cases such as “A rescinded the contract with B. This rescission
was cancelled later”. We therefore developed the our own algorithm to detect
previous potentially similar events and merge them, executed in step 4. Fig. 6
depicts the pipeline of our framework.

for eachsentence

Preprocessing

for each
token

INPUT
CoreNLP main
pipeline

YES

RULES
- Event detection- Contracts as NEs

NO

Is it
an event?

NO

Is it arelevant
NE?

NO

YES
Is it
negated?

Store the values

STORE

NO

CompleteframesIs it
a fact?

YES

Check the arguments ofSTORE
the corresponing frame

OUTPUT

FRAMES
Generate
PROLEG
clauses

Link related
framesMerge
informaiton
VALUES

Fig. 6. The pipeline of our framework.

6

Results

The code of ContractFrames10 is publicly available in a GitHub repository11 . A
dataset with several different texts and their expected input is included in therepository. These texts have been generated by legal researchers, some of themtaking no part in the development of the framework. The texts include different types of paraphrasing, both semantic and syntactic, such as the examples
depicted in Fig. 5. Also different levels of nesting and events are represented in
the dataset, that includes texts of different length explaining the workflow of acontract (the establishment of the contract, the rescission or duress), and evensurrounding facts not exploited by the system.
1011

https://mnavasloro.github.io/ContractFrames/
https://github.com/mnavasloro/ContractFrames

M. Navas-Loro et al.

The code, written in Java, provides two main classes. The first allows theuser to input any text and provides it in the form of PROLEG clauses. The
second processes all the files in the dataset, that is also provided and can beextended by the user just by adding new files.
Besides the logic clauses output format, an ontology able to express contract
has been developed. This ontology, called Contract Workflow Ontology12 , is capable of representing the different types of events processed, such as agreements
and rescission, as well as others in the workflow of a general event such as negotiation. A method for generating an output in the form of triples is provided.
Fig. 7 shows the Contract Workflow Ontology.

Fig. 7. The Contract Workflow Ontology.

Additionally, the system also generates a .xml output that allows the visualization of the inner custom annotations in the text, namely events and namedentities like contracts. An example of this visualization (using the tool GATE[5]) can be found in Fig. 8.

7Conclusions

In this paper we have presented ContractFrames, a framework to process input
text written in natural language including technical legal terminology and produce as output its relevant information in the form of PROLEG logical clauses.
The framework is able to recognize several different kind of events, analyze ifthey are actual facts and extract relevant related information in the form of a12

https://mnavasloro.github.io/ContractFrames/datamodel.html

ContractFrames: Bridging the gap between Natural Language and Logics

Fig. 8. Visualization of our custom annotations in XML.

frame, deriving omitted information to some extent. Also, an ontology has beencreated as a data model to store the relevant information of the case and compound the whole contract workflow. This way, any other logical system mightalso benefit of the processing and the information extracted, and would be able
to generate a custom output from this knowledge representation.
Finally, although our framework has been able to successfully process all theexample texts produced by legal researchers not involved in its coding, it still hassome limitations that will be handled as future work. We therefore have several
research lines for improving ContractFrames. For now, the framework is not able
to recognize appositions nor naming statements such as “the contract, entitledfrom now ‘contract0’, (...)” . Despite these expressions are not very common, we
consider that exploring new rules for detecting these kind of alternative paraphrasing, eventually to be added to our framework, will be useful. Also more
frames able to represent other legal situations and rule sets for populating themwill be developed, as well as common sense techniques to derive non explicit
information.

References
1. Araujo, D.A., et al.: Automatic information extraction from texts with inference and linguistic knowledge acquisition rules. In: Proceedings of the 2013
IEEE/WIC/ACM International Joint Conferences on Web Intelligence and Intelligent Agent Technologies-Vol. 3. pp. 151–154. IEEE Computer Society (2013)
2. Baker, C., et al.: The berkeley framenet project. In: Proceedings of the 17th international ACL-Vol. 1. pp. 86–90. Association for Computational Linguistics (1998)
3. Biagioli, C., et al.: Automatic semantics extraction in law documents. In: Proceedings of the 10th ICAIL. pp. 133–140. ACM (2005)
4. Chang, A.X., Manning, C.D.: TokensRegex: Defining cascaded regular expressions
over tokens. Tech. Rep. CSTR 2014-02, Department of Computer Science, Stanford
University (2014)
5. Cunningham, H., et al.: Getting More Out of Biomedical Documents with GATE’s
Full Lifecycle Open Source Text Analytics. PLOS Computational Biology 9(2),1–16 (02 2013)
6. Daskalopulu, A., et al.: Evidence-based electronic contract performance monitoring. Group decision and negotiation 11(6), 469–485 (2002)
7. Dell’Orletta, et al.: The splet–2012 shared task on dependency parsing of legal
texts. In: Semantic Processing of Legal Texts (SPLeT-2012) Workshop Programme.
p. 42 (2012)

M. Navas-Loro et al.
8. Dragoni, M., et al.: Combining nlp approaches for rule extraction from legal documents. In: 1st Workshop on MIning and REasoning with Legal texts (MIREL
2016) (2016)
9. Francesconi, E.: Legal rules learning based on a semantic model for legislation.
In: Proceedings of the LREC 2010 Workshop on the Semantic Processing of Legal
Texts (SPLeT-2010). Malta, May 2010. p. 46 (2010)
10. Governatori, G., Milosevic, Z.: A formal analysis of a business contract language.
International Journal of Cooperative Information Systems 15(04), 659–685 (2006)
11. Grosof, B.N.: Representing e-commerce rules via situated courteous logic programsin ruleml. Electronic Commerce Research and Applications 3(1), 2–20 (2004)
12. Hoekstra, R., Breuker, J., Di Bello, M., Boer, A., et al.: The lkif core ontology ofbasic legal concepts. LOAIT 321, 43–63 (2007)
13. Kabilan, V.: Contract workflow model patterns using bpmn. In: Proceedings of the10th International Workshop on EMMSAD (2005)
14. Kimura, Y., et al.: Treatment of legal sentences including itemized and referential
expressions – towards translation into logical forms. In: New Frontiers in Artificial
Intelligence. pp. 242–253. Springer Berlin Heidelberg, Berlin, Heidelberg (2009)
15. Kiyavitskaya, N., et al.: Automating the extraction of rights and obligations forregulatory compliance. In: International Conference on Conceptual Modeling. pp.
154–168. Springer (2008)
16. Leff, L., Meyer, P.: econtracts 1.0 committee specification. OASIS LegalXML Technical Report, http://docs.oasis-open.org/legalxmlecontracts (2007)
17. Manning, C.D., et al.: The Stanford CoreNLP Natural Language Processing
Toolkit. In: Proceedings of the 52nd Annual Meeting of the ACL 2014, System
Demonstrations. pp. 55–60 (2014)
18. Miller, G.A.: Wordnet: a lexical database for english. Communications of the ACM
38(11), 39–41 (1995)
19. Minsky, M.: A framework for representing knowledge (1975)
20. Molina-Jimenez, C., et al.: Contract representation for run-time monitoring and enforcement. In: IEEE International Conference on E-Commerce. pp. 103–110 (2003)
21. Moulin, B., Rousseau, D.: Automated knowledge acquisition from regulatory texts.
IEEE Expert 7(5), 27–35 (Oct 1992). https://doi.org/10.1109/64.163670
22. Nakamura, M., et al.: Towards translation of legal sentences into logical forms.
In: Satoh, K., et al. (eds.) New Frontiers in Artificial Intelligence. pp. 349–362.
Springer Berlin Heidelberg, Berlin, Heidelberg (2008)
23. Prisacariu, C., Schneider, G.: A dynamic deontic logic for complex contracts. The
Journal of Logic and Algebraic Programming 81(4), 458–490 (2012)
24. Rodrı́guez-Doncel, V., et al.: Overview of the mpeg-21 media contract ontology.
Semantic Web 7(3), 311–332 (2016)25. Satoh, K., et al.: Proleg: An implementation of the presupposed ultimate fact
theory of japanese civil code by prolog technology. In: New Frontiers in Artificial
Intelligence. pp. 153–164. Springer Berlin Heidelberg, Berlin, Heidelberg (2011)
26. Schuler, K.K.: Verbnet: A broad-coverage, comprehensive verb lexicon (2005)
27. Wyner, A.Z., Peters, W.: On rule extraction from regulations. In: JURIX. vol. 11,
pp. 113–122 (2011)