Legislative documents are by their own nature subject to interpretation, and interpretations of one document can diverge. In this paper we discuss the mechanism proposed by LegalRuleML to capture alternative interpretations or renderings of a legal source. LegalRuleML allows for mutually incompatible renderings (or interpretations) of a legal source to coexist in the same LegalRuleML document, and provides facilities to identify the interpretations and to select them. The mechanism is illustrated with an example form Italian Jurisprudence.
A common trait of legal reasoning and practice is that it is often possible to have multiple interpretations of one and the same textual provision, where there is no true interpretation. Such alternative interpretations might be mutually incompatible. This is often the case in legal disputes where the parties involved put forward their interpretations and where the judge has to select one of them or propose another interpretation.
In this paper we report on the e orts of the OASIS LegalRuleML Technical
Committee to capture the phenomenon of multiple interpretations in the LegalRuleML standard
[
The work on interpretation in LegalRuleML is set in the more general context of
interpretation in Linguistics in general and Forensic Linguistics in particular. In
Linguistics, issues about interpretation have long been of central concern (from [
In Forensic Linguistics, such considerations are applied to legal texts [
LegalRuleML endeavours not to account for how di erent interpretations arise, but to provide a mechanism to record and represent them. The main novelty of this paper is the presentation of a formal representation of legal interpretation. In Section 2 some of the relevant background literature is reviewed. The running example is presented in Section 3. The case study is formalised in LegalRuleML in Section 4. The paper concludes with Section 5. 2
Norms, guidelines and rules are found in a variety of legal texts. As text, the semantic content (including meta-data) is di cult to exchange between parties or to otherwise process or reuse by automated applications. Yet it is essential to eGoverment and eCommerce services that such content has a machine-readable form such that applications can be deployed. The LegalRuleML TC, which was set up inside of OASIS (www.oasis-open.org), aims to produce a rule interchange language for the legal domain. Using the representation, developers can provide applications to process legal contents for data interchange, comparison, evaluation, and reasoning.
Over the last twenty years, the Artificial Intelligence (AI) and Law communities
have converged on modelling legal norms and guidelines using logic and other formal
techniques. With existing methods, a Legal Knowledge Engineer analyses the text,
scopes the analysis, extracts the norms and guidelines, applies models and a theory
within a logical framework, and finally represents the norms using a particular formalism.
In the last decade, several Legal XML standards have been proposed to describe legal
texts [
Legal Knowledge Interchange Format (LKIF) is a specification that includes a
legal core ontology and a legal rule language that closely represents legal knowledge
and reasoning [
RuleML is a family of languages, whose modular system of schemas for XML permits high-precision web rule interchange (http://wiki.ruleml.org/index.php/ RuleML_Home). LegalRuleML is part of this family of languages. RuleML distinguishes deliberation from reaction rules. Deliberation rules include modal and derivation rules, e.g. facts, queries, and Horn rules. Reaction rules include Complex Event Processing, Knowledge Representation, Event-Condition-Action, and Production. RuleML rules can combine derivation and reaction rules, allowing uniform XML serialization across rules.
RIF (http://www.w3.org/2005/rules/wiki/RIF_Working_Group) is a W3C recommendation for a standard Web Rule Interchange Format to exchange rule sets among di erent rule systems. It makes use of Internationalized Resource Identifiers and supports XML Schema data types. The RIF architecture is conceived as a family of languages. A RIF dialect is a rule-based language with an XML syntax and a well-defined semantics. RIF does not provide direct support for adequate representation of legal rules and legal reasoning since they do not support e.g. logic-based negation, non-monotonic reasoning, events and temporal metadata, among other relevant features.
The Semantics of Business Vocabulary and Business Rules (SBVR) [
Given this context, the LegalRuleML Technical Committee has focused on three
specific needs [
The main novelty of LegalRuleML and the contribution of this paper is that it provides a formal representation for alternative interpretations of a legal source (textual provision), which is not found in other formal modelling languages. 3
In this section we propose a real life case (taken from the Italian legal system and
jurisprudence, originally discussed in [
The benefit referred to in comma 1 shall be paid in an amount equal 80 per cent of five-twelfths of the income earned and reported for tax purposes by the freelancer in the second year preceding the year of application.1 The case 18/96, Bologna Tribunal, Imola Section, concerns the interpretation of the conjunction in the income earned and reported for tax purposes. . . .
A fundamental and unalienable principle of legal language is its close connection with natural language; in particular, the interpretation of a textual provision should be the ordinary meaning conveyed by the text of the provision taking into account its context in the act in which it appears and the purpose or object underlying the act. For example, in the Italian legal systems this connection is prescribed by Article 12 of the Preleggi, Italian Civil Code, stating
In applying a statute, the interpreter should not attribute to it a meaning di erent from that made evident by the proper meaning of the words and by their connection, as well as by the intention of the law maker.2 Accordingly, the literal interpretation of the norm is given by the rule
earned(x; y 2) ^ reported(x; y 2) ) fOBLbaeuaxirleira=rye=mfpreloeylaenrcer g paybenefit( f (x); y) (1) The arguments of the predicates earned and reported are the income x earned/reported in the year in the second argument (y 2). Similarly for paybenefit where the function f encodes the computation of the value of the benefit based on the value of the income x. However, according to the Italian taxation legislation in force at the time of the dispute the income received in one year is reported for tax purpose the year after the year it has 1 L’indennità di cui al comma 1 viene corrisposta in misura pari all’80 per cento di cinque dodicesimi del reddito percepito e denunciato ai fini fiscali dalla libera professionista nel secondo anno precedente a quello della domanda. 2 Nell’applicare la legge non si può ad essa attribuire altro senso che quello fatto palese dal significato proprio delle parole secondo la connessione di esse, e dalla intenzione del legislatore. earned(x; y) ! reported(x; y + 1) reported(x; y) ! earned(x; y 1) Consider now the Income constant obtained by applying the Russell’s definite description operator ( ) on the conjunction in the left-hand side of (1).
Income = x (earned(x; y) ^ reported(x; y)) been earned. Thus, for example, the income earned in 1995 is reported in 1996. This principle can be formulated as follows: (2) (3) (4) (5) (6) The conclusion is that the constant Income is not denoting, i.e., the interpretation of Income is ;, thus there is no income “entity” that is earned and reported in one and the same year. Hence, the left hand side of the rule in (1) never holds, and the rule never fires, against the intentions of the legislator.
Based on the textual provision two possible interpretations are possible: in the first interpretation the temporal expression “in the second year preceding the year of application” refers to the income earned in the second year preceding the application, while in the second interpretation it refers to the income reported for tax purposed in the second year preceding the application. For example, for an application in year 1998, the first interpretation bases the computation on the income earned in 1996 (and reported in 1997), while for the second interpretation, the value of the benefit is computed starting from the income reported in 1996 (and earned in 1995). Accordingly, the first interpretation, the interpretation proposed by the freelancer in the case, can be formalised by the rule earned(x; y 2) )
fOBLbaeuaxirleira=rye=mfpreloeylaenrcer g paybenefit( f (x); y) Similarly the second interpretation, the interpretation proposed by the employer, can be represented by the rule3 reported(x; y 2) )
fOBLbaeuaxirleira=rye=mfpreloeylaenrcer g paybenefit( f (x); y) The task of the Judge was to decide which of the two interpretations has to be used for the application of the norm. In the case the Judge argue in favour of the interpretation advanced by the freelancer. 4
In the previous section we presented three possible interpretations of the norm, the literal interpretation, the interpretation of the freelancer and the interpretation of the 3 Alternatively, we could use earned(x; y
3) ) while, from a formal point of view, it is semantically equivalent to (6) it is less close in meaning to the textual provision than its counterpart: the temporal reference in the argument would “third year preceding the year of the application”.
OBLbaeuaxirleira=rye=mfpreloeylaenrcer paybenefit( f (x)), employer. Here we are going to present the LegalRuleML fragments required to encode the formalisations corresponding to the three interpretations. The formalisations of these three statements can be represented as prescriptive rules which are encoded by <lrml:PrescriptiveStatement> blocks in LegalRuleML, each containing one <ruleml:Rule> Template. The following fragment corresponds to the literal interpretation, i.e., (1) Since LegalRuleML is built on top of RuleML we can reuse all RuleML facilities, in particular we can use <ruleml:Expr> and <ruleml:Fun> to encode the computation of the benefit to be paid to the freelancer.
The next snippet captures the interpretation of the freelancer, i.e., (5). <lrml:PrescriptiveStatement key="freelancer"> <ruleml:Rule closure="universal" key=":freelancer-template"> <ruleml:if>
<ruleml:Atom keyref=":atom-earned"/> </ruleml:if> <ruleml:then>
<lrml:Obligation keyref="#obl-paybenefit"/> </ruleml:then> </ruleml:Rule> </lrml:PrescriptiveStatement> Notice that inside this statement we can use keyrefs to refer to the elements already defined in the block corresponding to the literal interpretation. Similar considerations apply to the block modelling (6), the employer’s interpretation, below. <lrml:PrescriptiveStatement key="employer"> <ruleml:Rule closure="universal" key=":employer-template"> <ruleml:if>
<ruleml:Atom keyref=":atom-reported"/> </ruleml:if> <ruleml:then>
<lrml:Obligation keyref="#obl-paybenefit"/> </ruleml:then> </ruleml:Rule> </lrml:PrescriptiveStatement> The following LegalRuleML Constitutive Statement represents the principle expressed in (2), that earned income will be reported in the following year. Because a Constitutive Statement defines concepts and does not prescribe behaviours, the consequent of its <ruleml:Rule> Template does not contain deontic operators. Similarly, the following fragment represents the principle that reported income was earned in the previous year, as expressed in (3). After the renderings of the alternative interpretations and the relationships between the predicates earned and reported given by the three constitutive rules, we have to specify that they are mutually exclusive formalisation of the same norm. This can be achieved by following Alternatives block that represents a mutually-exclusive collection of renderings of the Legal Norms from the Legal Source #ls1. The <lrml:LegalSource> with key #ls1, not shown in the text, contains the references to the actual text of the norm. <lrml:Alternatives key="maternity-alts"> <lrml:Comment> These alternatives are mutually
incompatible formalizations of the same legal source: keyref="#ls1". </lrml:Comment> <lrml:hasAlternative keyref="#literal" /> <lrml:hasAlternative keyref="#freelancer" /> <lrml:hasAlternative keyref="#employer" /> </lrml:Alternatives> A <lrml:Context> block is used to render a collection of Associations, e.g. the Association of a Legal Source with a rendering of it as a LegalRuleML Statement, or to constrain other Contexts with respect to Alternatives. The following Context establishes a constraint that at most one of the Alternatives from the collection #maternity-alts may be selected by each Context: <lrml:Context key="maternity-alts-ctxt"> <lrml:appliesAssociations keyref="#asn-alts"/> <lrml:appliesAlternatives keyref="#maternity-alts"/> </lrml:Context> The Context metadata, e.g. authorship, source, authority, temporal and jurisdictional properties, are specified in an external (to the Context) Association block with identifier asn-alts, not shown in the paper, which is referenced using keyref. Similarly other Context blocks (also not shown in the paper) are given with the metadata about the authors of the various Statements. This permits to establish the provenance of the interpretations.
In the following fragment, a particular Alternative – that proposed by the freelancer – is selected, leading to the generation of the corresponding <ruleml:Rule> from the rule Template :freelancer-template. <lrml:Context key="adjudication"> <lrml:appliesAssociation keyref="#asn-adjudication"/> <lrml:inScope keyref="#freelancer"/> </lrml:Context> Unlike the first Context block, this one contains an <lrml:inScope> element. Such Contexts render interpretations that select one or more Statements as their scope of interpretation. When a Context is processed for presentation or inference, Legal Rules4 are generated from the <ruleml:Rule> Templates of in-scope Statements, annotated and optionally modified semantically by the Associations of the Context.
In this example the external Association asn-adjudication links the metadata for the adjudication of the case with a particular rendering of the norm, the rendering freelancer, corresponding to the interpretation proposed by the freelancer and confirmed by the judge5. 5
In this paper, we presented the mechanisms for the representation of (mutually incompatible) alternative interpretations of legal sources (textual provisions) in a LegalRuleML document. Specifically, we introduced the <lrml:Alternatives> element that is to be used to specify alternative formal renderings of a legal source, where the alternatives in a block are mutually exclusive. The key idea is that each rendering corresponds to an interpretation of the legal source. Using <lrml:Alternatives> along with <lrml:Context> blocks, we can specify the di erent formal renderings of a legal source and their metadata that associates them with other elements in a LegalRuleML document, e.g. the interpreter of the legal sources, the time of such interpretations, and the context where 4 In this paper, we focus on Prescriptive and Constitutive Statements, which always lead to generated Legal Rules. However, in the general case, e.g. <lrml:FactualStatement>, something other than a Legal Rule may be generated when a Statement is in scope. 5 The full example is available from https://tools.oasis-open.org/version-control/ browse/wsvn/legalruleml/trunk/examples/approved/maternity_alternatives_ compact.lrml such interpretations apply. Furthermore, we presented a real life case that illustrates how to use <lrml:Alternatives> to model the di erent interpretations of an ambiguous legal source such as arise in a legal dispute. An important advantage of the use of <lrml:Alternatives> is that it reduces redundancies in encoding the formalisation of a legal document. Di erent interpretations of a legal document can occur for many reasons (e.g., di erent readings of one norm by the parties involved in a legal dispute, di erent granularity of representation required by di erent applications, di erent interpretations with respect di erent (sub-)jurisdictions, the change of interpretation of terms over time, . . . ). The mechanism we have proposed does not force the author of a LegalRuleML document to duplicate and modify the document just to accommodate every di erent interpretation of a legal source. All the author has to do is to create an <lrml:Alternatives> block in a single LegalRuleML document, add the various alternatives in the block, and refer to it from <lrml:Context> blocks that associate metadata with sets of statements. Then by filtering with respect to the metadata associated with an alternative, one can generate the manifestation of the document corresponding to alternative interpretations selected by the filtering conditions, employing the <lrml:Alternatives> expression to ensure that mutually incompatible alternatives are not simultaneously asserted in the same context.
The LegalRuleML syntax for the metadata collections, e.g. Alternatives, Jurisdictions, LegalSources, was designed to facilitate the exposure of these relationships as Linked Open Data (LOD). The RDF Collection structure is particularly appropriate for this, because it can be closed, indicating that the collection contains only the entities explicitly asserted to belong to it. An XSLT transformation will be developed to convert the LegalRuleML XML into RDF, while an RDFS metamodel will capture additional constraints. We envision that the major benefits of the RDF representation of LegalRuleML are the possibility to integrate the legal knowledge with information stored in other Open Data repositories and triple stores, and the ability to use tools such as SPARQL reasoners for preprocessing LegalRuleML documents before passing data to specialised legal reasoners.