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:

Lynx Documents are the basic information units in Lynx: identified pieces of text. Documents are described with Metadata and they structured in Lynx Document Parts.
Collections are groups of Lynx Documents with any logical relation. There may be one collection per use case, per jurisdiction, etc. Collections are not specified in this document.
Annotations are enrichments of Lynx Documents, such as temporal entities, identified terms in thesauri, etc. Other types of enrichments, not included in LynxAnnotations are summaries and translations.

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 might have been: 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.

However, the recommended form is:

https://apis.lynx-project.eu/document-platforms/{implementationId}/collections/{collectionId}/documents/{docId}

Where implementationId is one of these strings: “ldp” or “upm-elastic”, collectionIdis the name of the collection and docIdis the document identifier.

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). The value for the jurisdiction property is recommended to be a ISO 3166-1 or ISO 3166-2 alpha 2 (codes with two letters), in capitalized form. EU represents European Union. ATU lists not supported as of this version.

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

Lynx Document Validator Sandbox

Sample LynxDocuments

The first validation takes ~20 sec.

No output

Validation rules

#	Description
R001	The document MUST be a valid RDF document in any serialization (TTL, JSON-LD, etc.)
R002	The document must contain exactly an instance of the LynxDocument class (or its subclasses).
R003	There MUST be exactly one text value (nif:isString) in the instances of LynxDocument.
R004	There can be at most one ELI value.
R005	Instances of LynxDocument MUST have exactly one metadata element.
R006	There can be at most one jurisdiction.
R007	Begin index has to be smaller than end index. PENDING
R008	Instances of nif:OffsetBasedString should have a URI pattern conforming to the pattern '#offset_{beginIndex}_{endIndex*}'
R009	Instances of LynxDocument MUST have exactly one id_local.
R010	Instances of nif:String should have a valid URI.
R011	A nif:OffsetBasedString must have exactly one nif:beginIndex and one nif:endIndex
R012	If the document is a lkg:Legislation document, there should be eli:jurisdiction and eli:date
R013	The language tag of the `text` element (`nif:isString`) must NOT have language tag.
R014	There can be at most one ELI value.
R015	nif: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

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

Table 5b: Types of annotations generated by different services

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	ISO 3166-1 or ISO 3166-2 alpha 2 codes (with two letters), in capitalized form, such as AT (for Austria), or ES (Spain). Regions are therefore also possible: ES-MA (Madrid). Some LynxDocument processors may drop the region specific letters. Entries in the ATU list may be accepted in the future for compatibility with ELI but not accepted in this version.	`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
identifiers.	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
has Eli
metadata
parent

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
has authority
has PDF
has Wikipedia
summary
was extracted from

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. Benchmarking

A number of documents has been selected for systematic benchmarking of the Lynx services. These documents can be downloaded as a bulk download.

7. 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.

Legal Knowledge Graph Ontology

Abstract

Table of contents

1. Introduction

2. Description through example

2.1 Preliminary examples

Towards a Lynx Document

Lynx Document as a NIF document

Lynx Documents with metadata

2.2 Simple samples

URI policy for Lynx Documents

Legislative documents must have jurisdiction.

Lynx Document with language information

Lynx Documents with parts

Lynx Documents with annotations

3. Validation

Lynx Document Validator Sandbox

Validation rules

4. Ontology description

Namespace declaration

Ontology description

Classes

Agreement c back to ToC or Class ToC

Case Law c back to ToC or Class ToC

Collective Agreement c back to ToC or Class ToC

Legislation c back to ToC or Class ToC

Lynx Annotation c back to ToC or Class ToC

Lynx Document c back to ToC or Class ToC

Lynx Document Part c back to ToC or Class ToC

Metadata c back to ToC or Class ToC

Standard c back to ToC or Class ToC

Technical Specification c back to ToC or Class ToC