Legal Knowledge Graph Ontology

This version:
http://lynx-project.eu/doc/lkg
Revision:
1.0.1
Authors:
Víctor Rodríguez-Doncel
Contributors:
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 Lynx project.

Table of contents

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.

In order to manipulate the data structures described in this work, we recommend using the library described here.

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.

Simplest possible Lynx Document

The simplest possible Lynx Document as a JSON-LD file is shown in the listing below. This is not a valid LynxDocument because it lacks certain metadata elements.

{
  "@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. It references an external (and very important) file, the context file. This file makes possible the neat transformation from 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.

@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 be 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:

@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/doc002>
  a lkg:LynxDocument,nif:Context ;
  nif:isString "This Lynx document is a NIF document, with or without the explicit declaration of nif:Context" .
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 Table 2, 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.

The following example is a perfectly valid Lynx Document.

{
 "@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.",
 "metadata" : {
   "language" : "de",
   "id_local": "doc003"
 }
}
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).

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

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.

{
 "@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",
 "metadata" : {
   "subject" : {"en" : ["keyword1"], "es":["materia1", "materia2"] },
   "language": "de",
   "id_local": "1234",
   "title" : {"de":"Titel"},
   "jurisdiction" : "at"
 }
}

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 shows an example of nested fragments, as Art. 2.1.

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.

In the main document, offset_ini and offset_end may also be provided, in the LynxDocumentPart they must.

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc006",
  "@type": "lkg:LynxDocument",
  "text": "Art.1 This is the fourth Lynx document. Art.2 This is the fourth Lynx document. Art 2.1. Empty.",
  "parts": [
    {
      "@id": "http://lynx-project.eu/doc/samples/doc006#offset_0_40",
      "@type": ["lkg:LynxDocumentPart", "nif:OffsetBasedString"],      
      "offset_ini": "0",
      "offset_end": "39",
      "title": "Art. 1"
    },
    {
       "@id": "http://lynx-project.eu/doc/samples/doc006#offset_41_94",
       "@type": ["lkg:LynxDocumentPart", "nif:OffsetBasedString"],
       "offset_ini": "40",
       "offset_end": "94",
       "title": "Art. 2"
     }
   ]
}
The equivalent piece of RDF in Turtle is:
@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>
        a             lkg:LynxDocument ;
        eli:has_part  <http://sample.com/doc008#offset_41_94> , <http://sample.com/doc008#offset_0_39> ;
        nif:isString  "Art.1 This is the fourth Lynx document. Art.2 This is the fourth Lynx document. Art 2.1. Empty." .

<http://lynx-project.eu/doc/samples/doc006>
        a               lkg:LynxDocumentPart ;
        nif:beginIndex  "41"^^xsd:nonNegativeInteger ;
        nif:endIndex    "94"^^xsd:nonNegativeInteger ;
        dct:title       "Art. 2" .

<http://lynx-project.eu/doc/samples/doc006>
        a               lkg:LynxDocumentPart ;
        nif:beginIndex  "0"^^xsd:nonNegativeInteger ;
        nif:endIndex    "39"^^xsd:nonNegativeInteger ;
        dct:title       "Art. 1" .

The parts have no link to the full document because they are already referenced by the full document. However, it is also possible to specify the back link:

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc006",
  "@type": "lkg:LynxDocument",
  referenceContext": "http://sample.com/doc018",        
  "offset_ini": "0",
  "offset_end": "39",
  "title": "Art. 1"
}
which turns into this RDF:
   <http://lynx-project.eu/doc/samples/doc006#offset_41_94>
        a               nif:OffsetBasedString , lkg:LynxDocument ;
        nif:referenceContext <http://sample.com/doc008> ;
        nif:beginIndex  "41"^^xsd:nonNegativeInteger ;
        nif:endIndex    "94"^^xsd:nonNegativeInteger ;
        dct:title       "Art. 2" .  

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. This is the JSON-LD representation:

{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc007",
  "@type": "lkg:LynxDocument",
  "text": "Welcome to Madrid in 2019, specifically Cercedilla.",
  "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"

      }
     ] 
   }
}

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

Representation as Turtle

@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: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" 
  ] .

Types of Lynx Documents

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

A complete listing

Putting together all the pieces we get a complete listing (you can download the JSONLD o el RDF Turtle).
{
  "@context": "http://lynx-project.eu/doc/jsonld/lynxdocument.json",
  "@id": "http://lynx-project.eu/doc/samples/doc009#offset_0_",
  "@type": [
    "nif:Context",
    "nif:OffsetBasedString",
    "lkg:LynxDocument"
  ],
  "parts": [
    {
      "@id": "http://lynx-project.eu/doc/samples/doc009#offset_13_28",
      "@type": [
        "nif:OffsetBasedString",
        "lkg:LynxDocumentPart"
      ],
      "parent": "http://lynx-project.eu/doc/samples/doc009#offset_0_",
      "offset_ini": 13,
      "offset_end": 28,
      "title": "Article 1."
    }
  ],
  "metadata": {
    "language": "en",
    "eli:id_local": "doc001"
  },
  "text": "I like Madrid. Article 1. Madrid is good.",
  "offset_ini": 0,
  "offset_end": 41,
  "annotations": [
    {
      "@id": "http://lynx-project.eu/doc/samples/doc009#offset_7_13",
      "@type": [
        "lkg:LynxAnnotation",
        "nif:OffsetBasedString"
      ],
      "referenceContext": "http://lynx-project.eu/doc/samples/doc009#offset_0_",
      "offset_ini": 7,
      "offset_end": 13,
      "anchorOf": "Madrid",
      "annotationUnit": [
        {
          "@type": ["nif:AnnotationUnit"],
          "taConfidence": "0.9",
          "taAnnotatorsRef": "who_annotated",
          "taIdentRef": "http://dbpedia.org/ontology/Location",
          "taIClassRef": "http://dbpedia.org/resource/Madrid"
        }
      ]
    }
  ]
}
Whose equivalent in RDF Turtle is:
@prefix dbo:   <http://dbpedia.org/ontology/> .
@prefix eli:   <http://data.europa.eu/eli/ontology#> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix dbr:   <http://dbpedia.org/resource/> .
@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 skos:  <http://www.w3.org/2004/02/skos/core#> .
@prefix itsrdf: <http://www.w3.org/2005/11/its/rdf#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix nif:   <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://lkg.lynx-project.eu/res/doc009#offset_13_28>
        a                     lkg:LynxDocumentPart , nif:OffsetBasedString .
        nif:beginIndex        "13"^^xsd:nonNegativeInteger ;
        nif:endIndex          "28"^^xsd:nonNegativeInteger ;
        nif:referenceContext  <http://lkg.lynx-project.eu/res/doc009> ;
        dct:title             "Article 1." .

<http://lkg.lynx-project.eu/res/doc009>
        a               lkg:LynxDocument , nif:OffsetBasedString , nif:Context ;
        eli:has_part    <http://lkg.lynx-project.eu/res/doc009#offset_13_28> ;
        lkg:metadata    [ eli:id_local  "doc001" ;
                          dct:language  "en"
                        ] ;
        nif:beginIndex  "0"^^xsd:nonNegativeInteger ;
        nif:endIndex    "41"^^xsd:nonNegativeInteger ;
        nif:isString    "I like Madrid. Article 1. Madrid is good." .

<http://lkg.lynx-project.eu/res/doc009#offset_7_13>
        a                     nif:OffsetBasedString , lkg:LynxAnnotation ;
        nif:anchorOf          "Madrid" ;
        nif:annotationUnit    [ a                    nif:AnnotationUnit ;
                                nif:taAnnotatorsRef  "who_annotated" ;
                                itsrdf:taConfidence  0.9 ;
                                itsrdf:taIdentRef    dbo:Location
                              ] ;
        nif:beginIndex        "7"^^xsd:nonNegativeInteger ;
        nif:endIndex          "13"^^xsd:nonNegativeInteger ;
        nif:referenceContext  <http://lkg.lynx-project.eu/res/doc009> .  

2. Validation

Lynx Document Validator Sandbox

Sample LynxDocuments
The first validation takes ~20 sec.

No output

Validation rules

#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 1: 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-core<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#>

List of recommended metadata fields and their representation

Table 2: Recommended metadata elements
Group JSON Property Usage RDF property Cardinality
basic elements @id Lynx identifier of the document [in RDF this is the URI of the document] 1
text Text of the document. nif:isString (formerly rdf:value) 1
parts Parts of the document. This property may not be used even if parts exist (but they are stored somewhere else). 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). 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-*
general
language Language of the document.
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.
eli:type_document 0-1
jurisdiction Jurisdiction using ISO eli:jurisdiction 0-1
wasDerivedFrom Original URL if the document was extracted from the web prov-o:wasDerivedFrom 0-1
title Title of the document dct:title 0-1 per language
hasAuthority Authority issuing the document lkg:hasAuthority
nick Alternative names of the document foaf:nick 0-*
version Consolidated, draft or bulletin. The value is string from a controlled vocabulary (e.g. for Spain). eli:version 0-1
subject Subjects or keywords of the document dtc:subject 0-*
summary Summary of the text of the document lkg:summary 0-1 per language
identifiers id_local Local identifier (e.g. BOE-A-2019-1234).
This metadata element is mandatory
eli:id_local
identifier Other identifiers dct:identifier
dates first_date_entry_in_force Date when enters into force eli:first_date_entry_in_force
date_no_longer_in_force Date when repealed / expired eli:date_no_longer_in_force
version_date Date of publication of the document eli:version_date
mappings hasEli Official identifier (ELI, ECLI or equivalent) lkg:hasEli
hasPDF Link to the PDF version lkg:hasPDF
hasDbpedia Link to the equivalent dbpedia version lkg:hasDbpedia
hasWikipedia Link to the equivalent wikipedia version lkg:hasWikipedia
sameAs Equivalent document owl:sameAs
seeAlso Related documents rdfs:seeAlso
Internal creator Creators of the documents in Lynx (person or software) dct:creator
created Date when created in Lynx (internal) dct:created
rightsHolder Who is the rightsholder (e.g. http://example.com/John) dct:rightsHolder

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

Table 3: Recommended entities
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

Examples of annotations provided by each service

Table 4: Annotations by service

Service

Example

Data properties used

Possible entity types

Machine Translation

itsrdf:target "Programmvereinbarung Seite"@de

itsrdf:target

-

Summarization

lkg:metadata [
lkg:summary "Welcome to Berlin in 2018. Welcome to Berlin in 2018. Welcome to Berlin " @en;
] ;

lkg:summary

Named Entity Recognition

nif:annotationUnit [
a nif:AnnotationUnit ;
itsrdf:taAnnotatorsRef <NER-service> ;
itsrdf:taClassRef dbo:Location ;
itsrdf:taConfidence 0.5
] ;

itsrdf:taAnnotatorsRef
itsrdf:taClassRef
itsrdf:taConfidence [?]
itsrdf:taIdentRef [?]

dbo:Location

Geo Entities Recognition

nif:annotationUnit [
a nif:AnnotationUnit ;
itsrdf:taAnnotatorsRef <GEO Service> ;
itsrdf:taClassRef dbo:Location ;
itsrdf:taConfidence 0.5
] ;

itsrdf:taAnnotatorsRef
itsrdf:taClassRef
itsrdf:taIdentRef
itsrdf:taConfidence [?]

dbo:Location
dbo:Organization
dbo:Person

Temporal Recognition

nif:annotationUnit [
a nif:AnnotationUnit ;
itsrdf:taAnnotatorsRef <http://annotador.oeg-upm.net/> ;
itsrdf:taClassRef <http://www.w3.org/2006/time#TemporalEntity>, lkg:Date ;
itsrdf:taConfidence 0.9 ;
rdf:value "2019";
X:FREQ "X"
] ;

itsrdf:taAnnotatorsRef
itsrdf:taClassRef
itsrdf:taConfidence
itsrdf:taIdentRef
rdf:value

lkg:Date

Relation Extraction

nif:annotationUnit [
a nif:AnnotationUnit ;
rdf:object <http://dkt.dfki.de/documents#offset_39_55> ;
rdf:predicate <http://persistence.lynx-project.eu/ontologies/nif-core#Entity-Destination(e1,e2)> ;
rdf:subject <http://dkt.dfki.de/documents#offset_18_27>;
itsrdf:taAnnotatorsRef <RelEx Service>
]

itsrdf:taAnnotatorsRef
rdf:object
rdf:predicate
rdf:subject

lkg:RelEx

Entity Linking(PP)

nif:annotationUnit [
a nif:AnnotationUnit ;
itsrdf:taIdentRef <https://lynx.poolparty.biz/Cocktails/1>;
itsrdf:taAnnotatorsRef <EL Service>
] ;

itsrdf:taIdentRef

* entity types will prepared by Terminology gathering process
lkg:EL

Most important elements

Classes

Lynx Document Partc back to ToC or Class ToC

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

Logical, nesteable block of information within a Lynx Document
is in domain of
begin indexdp, end indexdp, parentop

Object Properties

has authorityop back to ToC or Object Property ToC

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

has super-properties
top object property

has wikipediaop back to ToC or Object Property ToC

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

has super-properties
top object property

parentop back to ToC or Object Property ToC

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

has characteristics: transitive

has domain
Lynx Document Partc
has range

Data Properties

begin indexdp back to ToC or Data Property ToC

IRI: http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#beginIndex

has domain
Lynx Document Partc
has range
decimal

end indexdp back to ToC or Data Property ToC

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

has domain
Lynx Document Partc
has range
decimal

typedp back to ToC or Data Property ToC

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

Type of document

Annotation Properties

creatorap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/creator

Definition of LynxDocument, collection and annotation

Lynx 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:

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.

Original documents are transformed as represented in the following figure: first, they are acquired by harvesters from their heterogeneous sources and formats, being structured and represented in a uniform manner. Then, they are enriched with annotations (such as named entities like persons, organisations, etc.).

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, Building the Legal Knowledge Graph for Smart Compliance Services in Multilingual Europe 36 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’).

In terms of UML, a couple of classes may be enough to represent them as objects.

A possible Java class diagram in UML would be as follows:

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