Legal Knowledge Graph Ontology

This version:
http://lkg.lynx-project.eu/def/
Revision:
1.2
Authors:
Víctor Rodríguez-Doncel
Sotiris Karampakis
Filippo Maganza
Socorro Bernardos
Julián Moreno-Schneider
Download serialization:
JSON-LD context file for Lynx Documents
License:

LKG Specification

Abstract

This is an ontology of documents related to compliance. This specification serves as a data model for documents in the H2020 Lynx project.

Table of contents

1. Introduction
2. Description through examples
2.1 Preliminary examples
2.2 Simple examples
3. Validation
4. Ontology description
5. References and acknowledgements
Annex I. Types of documents

1. Introduction

This ontology has been made with the purpose of supporting the representation of Lynx Documents, e.g., any document related to compliance worth to be in a Legal Knowledge Graph. This specification serves as a data model for documents in the Lynx project.

Lynx Documents are compliant with NIF (NLP Interchange Format) specification and heavily reuses ELI metadata elements. Other ontologies have been also considered as a reference: see a broad list here.

If you are going to program in Java to manipulate the data structures described in this document, we recommend you using the library described here.

The H2020 Lynx project is about providing better services on compliance. The added value of the Lynx services revolve around a better processing of heterogenous, multilingual documents in the legal domain. Hence, the most important document is the Lynx Document.Lynx Documents may be grouped in Collections, and may be enriched with Annotations. Thus, the main entities to deal with are three:

2. Description through example

This section describes how to represent LKG documents supported by the ontology through examples. LKG documents can be validated against certain rules.

2.1 Preliminary examples

You may skip this section if you are familiar with NIF, JSON-LD and RDF. This subsection does not contain valid LynxDocument examples and its purpose is to serve as an introduction to those unfamiliar with NIF, JSON-LD and RDF.

Towards a Lynx Document

The listing below show a JSON-LD document, with text property. This is not a valid LynxDocument because it lacks certain metadata elements and because it lacks offset information for the text.

doc001 - Towards a Lynx Document (but not valid LynxDocument) JSON

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc001",
  "@type": "http://lkg.lynx-project.eu/def/LynxDocument",
  "text" : "This is the first Lynx document, a piece of identified text."
}

You may want to look at these lines in detail:

  • The first line declares the context (@context), which describes how to interpret the rest of the JSON LD document, mapping JSON properties into URI. It references an external (and very important) file, the context file. This file makes possible the neat transformation from beautiful JSON-LD to other RDF serializations.
  • The second line (@id) declares the identifier of the document, which must be the full URI --every LynxDocument is identified by a URI.
  • The @type line declares what is the type (rdf:type) of the document. The document must be an instance of lkg:LynxDocument.
  • The text element represents the text of the document. Although this is a text property in JSON, this is mapped to nif:isString as URI. The earliest versions of Lynx code used rdf:value instead.

The JSON-LD version can be automatically converted into other RDF syntaxes. For example, the Turtle version of the same document follows. In any case, they must be syntactically valid RDF. This is validated by validation rule R001. In fact, every instance of nif:String should have a valid URI. This is validated by validation rule R010.

doc001 - Towards a Lynx Document (but not valid LynxDocument) TTL

@prefix lkg: <http://lkg.lynx-project.eu/def/> .
@prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
<http://lynx-project.eu/doc/samples/doc001>
  a lkg:LynxDocument ;
  nif:isString "This is the first Lynx document, a piece of identified text." .

Lynx Document as a NIF document

LynxDocuments are NIF documents because the lkg:LynxDocument is a subclass of nif:Context: they can serve as the context for NIF annotations. The NIF ontology is available online. Of course, explicitly declaring that the LynxDocument is also a nif:Context is possible. Please note that NIF requires beginIndex and endIndex to exist. This second example is a NIF document, but not yet a LynxDocument because some metadata properties are missing.

doc002 - Towards a Lynx Document (but not valid LynxDocument) JSON

{
 "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
 "@id": "http://lynx-project.eu/doc/samples/doc002",
 "@type": ["lkg:LynxDocument","nif:Context"],
 "text" : "This Lynx document is a valid NIF document",
 "offset_ini": "0",
 "offset_end": "41"
}

doc002 - Towards a Lynx Document (but not valid LynxDocument) TTL

@prefix lkg: <http://lkg.lynx-project.eu/def/> .
@prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
<http://lynx-project.eu/doc/samples/doc002>
  a lkg:LynxDocument,nif:Context ;
  nif:isString "This Lynx document is a valid NIF document" ;
  nif:beginIndex "0"^^xsd:nonNegativeInteger ;
  nif:endIndex "41"^^xsd:nonNegativeInteger .
Instances nif:Context are required to have attributed exactly one nif:isString. This is validated by rule R003. The literal with the string must not have a language tag. This is validated by rule R013

Lynx Documents with metadata

Metadata is a collection of pairs property-list of values (such as "subject-testing/documents") and pairs of property-value (such as "title-SecondDocument"). They are introduced with the string metadata in JSON (which turns to be lkg:metadata in RDF). This is better illustrated with the example below. The recommended metadata elements are listed in a Table, useful for both coders in JSON-LD and RDF Turtle. The following excerpt shows a LynxDocument with two metadata records that are mandatory: language (dct:language in RDF) and id_local (eli:id_local in RDF). This is validate with rules R005, R004, R009. LynxDocuments must have a property with the id local, eli:id_local. This is validated with validation rule R009.

2.2 Simple samples

The following example is one of the simplest valid Lynx Document.

doc003 - Simple valid LynxDocument JSON

{
 "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
 "@id": "http://lynx-project.eu/doc/samples/doc003",
 "@type": "lkg:LynxDocument",
 "text" : "Das ist ein Dokument.",
 "offset_ini": "0",
 "offset_end": "20", 
 "metadata" : {
   "language" : "de",
   "id_local": "doc003"
 }
}

doc003 - Simple valid LynxDocument TTL

@prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
@prefix lkg: <http://lkg.lynx-project.eu/def/>
@prefix dct: <http://purl.org/dc/terms/> .
@prefix eli:   <http://data.europa.eu/eli/ontology#> .
<http://lynx-project.eu/doc/samples/doc003>
  a lkg:LynxDocument ;
  lkg:metadata [ 
    dct:language "de" 
    eli:id_local "doc003";
  ] ;
  nif:beginIndex "0"^^xsd:nonNegativeInteger ;
  nif:endIndex "20"^^xsd:nonNegativeInteger ;  
  nif:isString "Das ist ein Dokument." .

URI policy for Lynx Documents

There is no restriction on how LynxDocuments are identified --except that the identifiers must be URIs. A possible pattern is: http://USE-CASE-PART/res/slug, where slug is the local identifier of the document. If the local identifier contains strange characters, the slug will be its URI Encoded version.

Legislative documents must have jurisdiction.

When the type of document is legislation, two additional elements are mandatory: jurisdiction (eli:jurisdiction in RDF) and first_date_entry_in_force (also within eli namespace). This is validated by rule R012 . There can only be one jurisdiction (validated by rule R006), and it must be either an ISO 3166-1 or a ISO 3166-2 code.

Lynx Document with language information

Every LynxDocument must have one and only one main language declared in the metadata section. This is represented with language in JSON, and dct:language in the rest of RDF serializations. In addition to this, some strings (e.g. keywords) can be in other languages, which can be specified in using RDF language tags. The text itself must not have a language tag.

The language codes are those specified by ISO 639-1 codes. The use of language variants is not recommended (e.g. es-mx for the Spanish spoken in Mexico) because services will not recognize it as Spanish (e.g. Timex will refuse the annotation of such unknown language).

The example below shows the specification of language using the metadata element and the RDF language tags of literals. The following metadata elements are expected to have a language tag: title, subject.

doc004 - Simple valid LynxDocument with title and keywords JSON

{
 "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
 "@id": "http://lynx-project.eu/doc/samples/doc004",
 "@type": "lkg:LynxDocument",
 "text" : "Das ist ein Dokument",
 "offset_ini": "0",
 "offset_end": "20",  
 "metadata" : {
   "subject" : {"en" : ["keyword1"], "es":["materia1", "materia2"] },
   "language": "de",
   "id_local": "1234",
   "title" : {"de":"Titel"},
   "jurisdiction" : "at"
 }
}


doc004 - Simple valid LynxDocument with title and keywords TTL

@prefix eli:   <http://data.europa.eu/eli/ontology#> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix nif:   <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
<http://lynx-project.eu/doc/samples/doc004>
 a nif:Context , lkg:LynxDocument ;
 lkg:metadata [ 
   eli:id_local "1234" ; 
   eli:jurisdiction "AT" ; 
   dct:language "de" ;
   dct:subject "materia2"@es , "materia1"@es , "keyword1"@en ;
   dct:title "Titel"@de 
 ] ;
 nif:beginIndex  "0"^^xsd:nonNegativeInteger ;
 nif:endIndex    "20"^^xsd:nonNegativeInteger ;
 nif:isString    "Das ist ein Dokument" .				

The use of a @language in the JSON-LD to define a pre-determined language tag is possible but discouraged --no warranties that it will be processed correctly exist.

Lynx Documents with parts

Lynx Documents usually have a structure. The text is not repeated in the fragments, in order to save space. They are represented as lkg:LynxDocumentPart (formally subclass of nif:Structure).

Parts and structuring information can be included as shown in the next example. Parts are defined by the offset (begin and final character of the excerpt). They can be nested because they have a parent property and they can be possibly identified. Fragment identifiers can be built as described in the NIF specification. The example below (doc006) shows an example of nested fragments.

Every instance of nif:OffsetBasedString must have exactly one nif:beginIndex and one nif:endIndex, and its URI must contain the offsets. (this is validated by rule R011 and by rule R008. Please note that the type of the values of the offset_ini and offset_end must be ^^xsd:nonNegativeInteger.

Parts of the document are lkg:LynxDocumentPart, and they can also be nif:Context.

If in the main document, offset_ini and offset_end have also be provided, in the LynxDocumentPart they must be there as well. The example below also exemplifies how to embed a non-official property (for which there is no official support, such as http://example.org).

doc006 - Structured valid LynxDocument JSON

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc006",
  "@type": ["lkg:LynxDocument", "nif:Context"],
  "offset_ini" : "0",
  "offset_end" : "96",
  "text": "Art.1 Introduction of the sixth Lynx document. Art.2 Hierarchy. Art 2.1. Hierarchy is important.",
  "metadata" : {
    "id_local": "doc006",
    "language" : "en"
   },
  "parts": [
    {
      "@id": "http://lynx-project.eu/doc/samples/doc006#offset_0_47",
      "@type": ["lkg:LynxDocumentPart", "nif:OffsetBasedString"],      
      "referenceContext" : "http://lynx-project.eu/doc/samples/doc006",
      "offset_ini": "0",
      "offset_end": "47",
      "title": {"en" : "Art.1"}
    },
    {
       "@id": "http://lynx-project.eu/doc/samples/doc006#offset_47_96",
       "@type": ["lkg:LynxDocumentPart", "nif:OffsetBasedString"],
       "referenceContext" : "http://lynx-project.eu/doc/samples/doc006",
       "offset_ini": "47",
       "offset_end": "96",
       "http://example.org/searcheable" : false,
       "subject": {"en": ["hierarchy", "clave"] },
       "title": {"en" : "Art.2"}
     },
     {
        "@id": "http://lynx-project.eu/doc/samples/doc006#offset_64_96",
        "@type": ["lkg:LynxDocumentPart", "nif:OffsetBasedString"],
        "parent" : "http://lynx-project.eu/doc/samples/doc006#offset_47_96",
        "referenceContext" : "http://lynx-project.eu/doc/samples/doc006",
        "offset_ini": "64",
        "offset_end": "96",
        "title": {"en:" : "Art.2.1"}
      }
   ]
}
The equivalent piece of RDF in Turtle is:

doc006 - Structured valid LynxDocument TTL

@prefix eli:   <http://data.europa.eu/eli/ontology#> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix lkg:   <http://lkg.lynx-project.eu/def/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix nif:   <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
<http://lynx-project.eu/doc/samples/doc006#offset_0_47>
  a                     nif:OffsetBasedString , lkg:LynxDocumentPart ;
  nif:beginIndex        "0"^^xsd:nonNegativeInteger ;
  nif:endIndex          "47"^^xsd:nonNegativeInteger ;
  nif:referenceContext  <http://lynx-project.eu/doc/samples/doc006> ;
  dct:title             "Art.1"@en .

<http://lynx-project.eu/doc/samples/doc006#offset_64_96>
  a                     nif:OffsetBasedString , lkg:LynxDocumentPart ;
  lkg:parent            <http://lynx-project.eu/doc/samples/doc006#offset_47_96> ;
  nif:beginIndex        "64"^^xsd:nonNegativeInteger ;
  nif:endIndex          "96"^^xsd:nonNegativeInteger ;
  nif:referenceContext  <http://lynx-project.eu/doc/samples/doc006> ;
  dct:title             "Art.2.1"@en: .

<http://lynx-project.eu/doc/samples/doc006>
  a               nif:Context , lkg:LynxDocument ;
  eli:has_part    <http://lynx-project.eu/doc/samples/doc006#offset_64_96> , 
  <http://lynx-project.eu/doc/samples/doc006#offset_47_96> , 
  <http://lynx-project.eu/doc/samples/doc006#offset_0_47> ;
  lkg:metadata    [ eli:id_local  "doc006" ;
                    dct:language  "en"
                  ] ;
  nif:beginIndex  "0"^^xsd:nonNegativeInteger ;
  nif:endIndex    "96"^^xsd:nonNegativeInteger ;
  nif:isString    "Art.1 Introduction of the sixth Lynx document. Art.2 Hierarchy. Art 2.1. Hierarchy is important." .

<http://lynx-project.eu/doc/samples/doc006#offset_47_96>
  a                     nif:OffsetBasedString , lkg:LynxDocumentPart ;
   false ;
  nif:beginIndex        "47"^^xsd:nonNegativeInteger ;
  nif:endIndex          "96"^^xsd:nonNegativeInteger ;
  nif:referenceContext  <http://lynx-project.eu/doc/samples/doc006> ;
  dct:subject           "clave"@en , "hierarchy"@en ;
  dct:title             "Art.2"@en .

The nif:beginIndex and nif:endIndex values should be xsd:nonNegativeInteger, however, decimals should also be accepted (documents become more readable)

Lynx Documents with annotations

Annotations can be naturally represented in RDF with NIF.

doc007 - Simple valid LynxDocument with annotations JSON

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc007",
  "@type": ["lkg:LynxDocument","nif:Context"],
  "text": "Welcome to Madrid in 2019, specifically Cercedilla.",
  "offset_ini": "0",
  "offset_end": "51",
  "metadata" : {
    "id_local": "doc007",
    "language" : "en"
   },  
  "annotations" : {
     "@type": ["nif:OffsetBasedString","lkg:LynxAnnotation"],
     "@id": "http://lynx-project.eu/doc/samples/doc007#offset_21_25",
     "referenceContext": "http://lynx-project.eu/doc/samples/doc006",
     "offset_ini": "21",
     "offset_end": "35",
     "anchorOf": "2019",
     "annotationUnit" : [
      {
        "@type": "nif:AnnotationUnit",
        "taAnnotatorsRef" : "http://annotador.oeg-upm.net",
        "taClassRef" : "http://www.w3.org/2006/time#TemporalEntity", 
        "taIdentRef" : "lkg:Date", 
        "taConfidence" : "0.9",
        "value" : "2019"
      }
     ] 
   }
}

doc007 - Simple valid LynxDocument with annotations TTL

				
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix itsrdf: <http://www.w3.org/2005/11/its/rdf#> .
@prefix lkg: <http://lkg.lynx-project.eu/def/>

<http://lynx-project.eu/doc/samples/doc007>
  a lkg:LynxDocument, nif:Context ;
  lkg:metadata    [ eli:id_local  "doc007" ;
                    dct:language  "en"
                  ] ;  
  nif:beginIndex "0"^^xsd:nonNegativeInteger ;
  nif:endIndex "51"^^xsd:nonNegativeInteger ;
  nif:isString "Welcome to Madrid in 2019, specifically Cercedilla." .
  
<http://lynx-project.eu/doc/samples/doc007#offset_21_25>
  a lkg:LynxAnnotation, nif:OffsetBasedString ;
  nif:referenceContext <http://lynx-project.eu/doc/samples/doc007> ;
  nif:anchorOf "2019" ;
  nif:beginIndex "21"^^xsd:nonNegativeInteger ;
  nif:endIndex "35"^^xsd:nonNegativeInteger ;
  nif:annotationUnit [
    a nif:AnnotationUnit ;
    itsrdf:taAnnotatorsRef <http://annotador.oeg-upm.net/> ;
    itsrdf:taClassRef <http://www.w3.org/2006/time#TemporalEntity> ;
    itsrdf:taConfidence 0.9 ;
    itsrdf:taIdentRef lkg:Date ;
    rdf:value "2019" 
  ] .

Please note that the taClassRef should take, whenever defined, values from the Table, such asTemporalEntitye in the listing above. Other examples of annotations can be found online.

3. Validation

This Section is under review and the contents do not currently hold.

Lynx Document Validator Sandbox

Sample LynxDocuments
The first validation takes ~20 sec.

No output

Validation rules

These rules are under revision.
#Description
R001The document MUST be a valid RDF document in any serialization (TTL, JSON-LD, etc.)
R002The document must contain exactly an instance of the LynxDocument class (or its subclasses).
R003There MUST be exactly one text value (nif:isString) in the instances of LynxDocument.
R004There can be at most one ELI value.
R005Instances of LynxDocument MUST have exactly one metadata element.
R006There can be at most one jurisdiction.
R007Begin index has to be smaller than end index. PENDING
R008Instances of nif:OffsetBasedString should have a URI pattern conforming to the pattern '#offset_{beginIndex}_{endIndex*}'
R009Instances of LynxDocument MUST have exactly one id_local.
R010Instances of nif:String should have a valid URI.
R011A nif:OffsetBasedString must have exactly one nif:beginIndex and one nif:endIndex
R012If the document is a lkg:Legislation document, there should be eli:jurisdiction and eli:date
R013The language tag of the text element (nif:isString) must NOT have language tag.
R014There can be at most one ELI value.
R015nif:beginIndex and nif:endIndex should match the number of word positions in nif:isString.

See the SHACL Shapes for NIF plus other SHACL Shapes for the validations.

4. Ontology description

Namespace declaration

This ontology is identified by this URI:

http://lkg.lynx-project.eu/def/
and uses the prefixes listed in the table below.

Table: Namespaces used in the document
def <http://lkg.lynx-project.eu/def/>
xsd <http://www.w3.org/2001/XMLSchema#>
rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
rdfs <http://www.w3.org/2000/01/rdf-schema#>
owl <http://www.w3.org/2002/07/owl#>
dct <http://purl.org/dc/terms/>
dc <http://purl.org/dc/elements/1.1/>
prov <http://www.w3.org/ns/prov#>
vann <http://purl.org/vocab/vann/>
nif <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#>
rdflicense <http://purl.org/NET/rdflicense/>
foaf <http://xmlns.com/foaf/spec/>
eli <http://data.europa.eu/eli/ontology#>
itsrdf <https://www.w3.org/2005/11/its/rdf#>

Ontology description

Classes

Agreement c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/Agreement

Type of LynxDocument for private or public agreements, such as contracts
has super-classes
Lynx Document c

Case Law c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/CaseLaw

Type of LynxDocument for judgments or related documents
has super-classes
Lynx Document c

Collective Agreement c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/CollectiveAgreement

Type of LynxDocument for collective agreements, collective labour agreements (CLA) or collective bargaining agreements (CBA)
has super-classes
Lynx Document c

Legislation c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/Legislation

Type of LynxDocument for legislation (constitutions, acts, royal decrees, presidential decrees, etc.)
has super-classes
Lynx Document c

Lynx Annotation c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/LynxAnnotation

Declares a NIF annotation. The Annotation contains annotation units

The following is a list of some NIF-related properties and their values.

Table 5: Recommended entities in annotations
Element Meaning Values / example
itsrdf:taClassRef Class of the annotated context dbo:Person, dbo:Location, dbo:Organization, https://www.w3.org/2006/time#TemporalEntity, https://tilde.com/mt/systems/translation/
itsrdf:taldentRef URL from external resource, such as DBPedia, Wikidata, Geonames, etc. http://dbpedia.org/resource/London
itsrdf:taConfidence Confidence [0..1]
itsrdf:target Target, used for translations (string to be translated?)
nif:summary Summary text
has super-classes
annotation

Lynx Document c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/LynxDocument

Any document related to compliance worth to be in a Legal Knowledge Graph.

Because most of the AI algorithms dealing with documents focus on text -manipulation of images, videos or tables is less developed-, the essence of a Lynx Document is its text version. Thus, the key element in a Lynx Document is an identified piece of text. This document can be annotated with an arbitrary number of metadata elements (creation date, author, etc.), and eventually structured for a minimally attractive visual representation.

The elements in a complete Lynx Document, with annotations, are depicted in the following figure. Metadata is defined as a list of pairs attribute-values. Parts are defined as text fragments delimited by two offsets, possibly with a title and a parent, so that they can be nested. Annotations also refer to text fragments delimited by two offsets, and describe in different manners such a fragment (e.g. ‘it refers to a Location which is Madrid, Spain’).

LynxDocuments are NIF documents because the lkg:LynxDocument is a subclass of nif:Context: they can serve as the context for NIF annotations.

There is no restriction on how LynxDocuments are identified --except that the identifiers must be URIs. A possible pattern is: http://USE-CASE-PART/res/slug. The general type of a document can be specified by making the LynxDocument to have an additional type, such as eli:Legislation, lkg:Agreement (and lkg:CollectiveAgreement), lkg:CaseLaw or lkg:TechnicalSpecification. The more specific type of document can be given using the property rank property in the metadata, namely the eli:type_document in RDF, and whose recommended values are given in Annex I.

Table: Elements in a LynxDocument
JSON Property Usage RDF property Cardinality
@id Lynx identifier of the document [in RDF this is the URI of the document] 1
@type Document type. At least LynxDocument, also recommended nif:Context. Can be others: lkg:Legislation, lkg:CaseLaw, lkg:Doctrine, lkg:Standard rdf:type 1-*
text Text of the document. nif:isString 1
metadata Document metadata. See the properties under this elements in the Table lkg:metadata 1
parts Parts of the document. This property may not be used even if parts exist (but they are stored somewhere else). Objects under parts are described with the elements in Table eli:has_part 0-*
annotations Annotations of the document. This property may not be used even if annotations exist (but they are stored somewhere else). See examples in Table lkg:annotation 0-*
translations Translation of the document. This property may not be used even if translations exist (but they are stored somewhere else). lkg:translation 0-*
offset_ini Begin offset. Type: xsd:nonNegativeInteger. nif:beginIndex 1
offset_end End offset. Type: xsd:nonNegativeInteger. nif:endIndex 1
has super-classes
context
has sub-classes
Agreement c, Case Law c, Collective Agreement c, Legislation c, Standard c, Technical Specification c
is in domain of
metadata op

Lynx Document Part c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/LynxDocumentPart

Part of a LynxDocument.

LynxDocumentParts are related to LynxDocuments in three forms.

  • First LynxDocument aggregates different parts with the lkg:part relation.
  • Second, every LynxDocumentPart is related to the LynxDocument through the nif:referenceContext.
  • Third, LynxDocumentParts are related to their inmediate container through lkg:parent
The following table defines which properties can be used below a LynxDocumentPart.
Table: Elements below LynxDocumentPart
JSON Property Usage RDF property Cardinality
title Title of the document, such as "Article 3: on rights and obligations" dct:title 0-1 (per language)
referenceContext Reference context for the part. nif:referenceContext 1
parent Parent of the part. If non-existing, this part will be considered a root part. lkg:parent 0-1
offset_ini Begin offset. Type: xsd:nonNegativeInteger nif:beginIndex 1
offset_end End offset. Type: xsd:nonNegativeInteger nif:endIndex 1
has super-classes
structure
is in domain of
parent op

Metadata c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/Metadata

Declares the metadata element of a LynxDocument. As an "intellectual realisation of a legal resource", it is considered an eli:LegalExpression.

Table: Recommended metadata elements
Group JSON Property Usage RDF property Cardinality
general language Language of the document. Preferrably non-capitalized, no dialect variations. This metadata element is mandatory dct:language 1
type_document Sub-type of document (constitution, law, etc.). Defined for every legislation. For example, in Spain, the controlled vocabulary is here. Values in Appendix below. See also more strings in the controlled vocabulary here eli:type_document 0-1
jurisdiction Jurisdiction using ISO. Capitalized form preferred, both acceptable. ES, etc. Regions also posssible: ES-MA. eli:jurisdiction 0-1
title Title of the document. Language-tagged strings (one per language). dct:title 0-1 per language
hasAuthority Authority issuing the document. Single string with no language tag. See many elements in the NAL lkg:hasAuthority 0-1
alternative Alternative names of the document dct:alternative 0-*
version Consolidated, draft or bulletin. The value is string from a controlled vocabulary, for example 'con' (e.g. for Spain). eli:version 0-1
subject Subjects or keywords of the document. Array of language-tagged strings. dtc:subject 0-*
summary Summary of the text of the document. Language-tagged strings (one per language). lkg:summary 0-1 per language
identifiers. id_local Local identifier (e.g. BOE-A-2019-1234).This metadata element is mandatory. Single non-language tagged string. eli:id_local 1
accessGroup Determines to which access groups a document belongs. E.g. "CocaCola". Array of non-language tagged strings. lkg:accessGroup 0-*
dates first_date_entry_in_force Date when enters into force. In the form yyyy-mm-dd. eli:first_date_entry_in_force 0-1
date_no_longer_in_force Date when repealed / expired. In the form yyyy-mm-dd. eli:date_no_longer_in_force 0-1
version_date Date of publication of the document. In the form yyyy-mm-dd. eli:version_date 0-1
Provenance creator Creators of the documents in Lynx (person or software) dct:creator 0-*
created Date when created in Lynx (internal). XSD datetime. dct:created 0-1
rightsHolder Who is the rightsholder (e.g. http://example.com/John) dct:rightsHolder 0-1
source Original URL if the document was extracted from the web dct:source 0-1
mappings
hasEli Official identifier (ELI, ECLI or equivalent) lkg:hasEli 0-1
hasPDF Link to the PDF version. Single URI. lkg:hasPDF 0-1
hasDbpedia Link to the equivalent dbpedia version. Single URI. lkg:hasDbpedia 0-1
hasWikipedia Link to the equivalent wikipedia version. Single URI. lkg:hasWikipedia 0-1
sameAs Equivalent document. Array of URIs owl:sameAs 0-*
seeAlso Related documents. Array of URIs rdfs:seeAlso 0-*
has super-classes
legal expression
is in domain of
access group dp, has DBpedia op, has Eli op, has PDF dp, has Wikipedia dp, has authority dp, summary dp, was extracted from dp
is in range of
metadata op

Standard c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/Standard

Type of LynxDocument for Standards
has super-classes
Lynx Document c

Technical Specification c back to ToC or Class ToC

IRI: http://lkg.lynx-project.eu/def/TechnicalSpecification

Type of LynxDocument for Technical Specifications.
has super-classes
Lynx Document c

Object Properties

has DBpedia op back to ToC or Object Property ToC

IRI: http://lkg.lynx-project.eu/def/hasDbpedia

Link to the equivalent dbpedia version. Single URI.
has domain
Metadata c
has range
thing c

has Eli op back to ToC or Object Property ToC

IRI: http://lkg.lynx-project.eu/def/hasEli

Official identifier (ELI, ECLI or equivalent). See https://eur-lex.europa.eu/eli-register/about.html
has domain
Metadata c
has range
legal expression or legal resource

metadata op back to ToC or Object Property ToC

IRI: http://lkg.lynx-project.eu/def/metadata

Document metadata. See the properties under this elements in http://lynx-project.eu/doc/lkg/#idtablemetadataelements

has characteristics: functional

has domain
Lynx Document c
has range
Metadata c

parent op back to ToC or Object Property ToC

IRI: http://lkg.lynx-project.eu/def/parent

Parent of the part. Nested parts are allowed.
has domain
Lynx Document Part c
has range
Lynx Document c or Lynx Document Part c

Data Properties

access group dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/accessGroup

declares a group of documents for which access can be granted or not
has domain
Metadata c
has range
string

has authority dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/hasAuthority

Authority issuing the document. Single string with no language tag.
has domain
Metadata c
has range
string

has PDF dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/hasPDF

Link to the PDF version. Single URI.
has domain
Metadata c
has range
any u r i

has Wikipedia dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/hasWikipedia

Link to the equivalent wikipedia version. Single URI.
has domain
Metadata c
has range
any u r i

summary dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/summary

Summary of the text of the document. Language-tagged strings (one per language).
has domain
Metadata c
has range
plain literal

was extracted from dp back to ToC or Data Property ToC

IRI: http://lkg.lynx-project.eu/def/wasExtractedFrom

Original URL if the document was extracted from the web
has domain
Metadata c
has range
any URI

5. Annex 1. Types of documents

The general type of a document can be specified by making the LynxDocument to have an additional type, such as eli:Legislation or lkg:Agreement. The next figure shows the different types.

The more specific type of document can be given using the eli:type_document property, and whose recommended values are given in the tables below. An example follows.

<http://lynx-project.eu/doc/samples/doc008>
  a lkg:LynxDocument, nif:Context, eli:Legislation ;
  nif:isString "A very important law in Spain." .
  lkg:metadata [
    eli:type_document "Ley".
  ]  

List of values for eli:type_document (nature of the act) in the legislation of the EU, Ireland, Spain and Austria.

Table: eli:type_document values in the EU
Value Description
dir directive
dir_del delegated directive
dir_impl implementing directive
reg regulation
reg_del delegated regulation
reg_impl implementing regulation
dec decision
dec_del delegated decision
dec_impl implementing decision
agree_internation international agreement
agree_amend amedment to an agrreement
arrang arrangement
convention convention
declar declaration
exc_let echange of letters
memorandum_underst memorandum of understandment
minutes minutes
agree_prot protocol to the agreement
pro protocol
Table: eli:type_document values in Spain
Value Description
c constitución
ref reforma (constitucional)
ai acuerdos internacionales
lo ley orgánica
l ley
lf ley foral
rdl real decreto-ley
rdlg real decreto legislativo
dl real decreto-ley
dlf decreto-ley foral
dlg decreto legislativo
dflg decreto foral legislativo
reg reglamento
rd real decreto
d decreto
df decreto foral
o orden
of orden foral
a acuerdo
res resolución
ins instrucción
cir circular
alia otros
Table: eli:type_document values in Austria
Value Description
bgbl Bundesgesetzblatt
lgbl Landesgesetzblatt
Table eli:type_document values in Ireland
Value Description
act public act
prv private act
cat constitutional amendment
si statutory instrument
sro statutory rules, orders and regulations
cons constitution

6. References and Acknowledgements

The Lynx project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 780602.

The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment and recommend the more complete Ontoology.