Source: http://lynx-project.eu/doc/lkg/
Timestamp: 2020-07-15 03:56:32
Document Index: 423120572

Matched Legal Cases: ['Art.1', 'Art.2', 'Art 2', 'Art.1', 'Art.2', 'Art.2', 'Art.1', 'Art.2', 'Art.1', 'Art.2', 'Art 2', 'Art.2', 'art 0']

Legal Knowledge Graph Ontology
http://lkg.lynx-project.eu/def/
Víctor Rodríguez-Doncel
Sotiris Karampakis
Filippo Maganza
Socorro Bernardos
Julián Moreno-Schneider
Download serialization:
JSON-LD context file for Lynx Documents
LKG Specification
This is an ontology of documents related to compliance. This specification serves as a data model for documents in the H2020 Lynx project.
2. Description through examples
2.1 Preliminary examples
2.2 Simple examples
4. Ontology description
5. References and acknowledgements
Annex I. Types of documents
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 summaries, translation, recognized entities, etc.
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.
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
"@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
<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
"@id": "http://lynx-project.eu/doc/samples/doc003",
"@type": "lkg:LynxDocument",
"text" : "Das ist ein Dokument.",
"offset_end": "20",
"language" : "de",
"id_local": "doc003"
doc003 - Simple valid LynxDocument TTL
@prefix lkg: <http://lkg.lynx-project.eu/def/>
@prefix eli:   <http://data.europa.eu/eli/ontology#> .
<http://lynx-project.eu/doc/samples/doc003>
lkg:metadata [
dct:language "de"
eli:id_local "doc003";
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
"@id": "http://lynx-project.eu/doc/samples/doc004",
"text" : "Das ist ein Dokument",
"subject" : {"en" : ["keyword1"], "es":["materia1", "materia2"] },
"id_local": "1234",
"title" : {"de":"Titel"},
"jurisdiction" : "at"
doc004 - Simple valid LynxDocument with title and keywords TTL
@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 ;
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
"@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.",
"id_local": "doc006",
"language" : "en"
"@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_end": "47",
"title": {"en" : "Art.1"}
"@id": "http://lynx-project.eu/doc/samples/doc006#offset_47_96",
"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",
"parent" : "http://lynx-project.eu/doc/samples/doc006#offset_47_96",
"offset_ini": "64",
"title": {"en:" : "Art.2.1"}
The equivalent piece of RDF in Turtle is:
doc006 - Structured valid LynxDocument TTL
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix lkg:   <http://lkg.lynx-project.eu/def/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
<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>
lkg:parent            <http://lynx-project.eu/doc/samples/doc006#offset_47_96> ;
nif:beginIndex        "64"^^xsd:nonNegativeInteger ;
nif:endIndex          "96"^^xsd:nonNegativeInteger ;
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: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>
false ;
nif:beginIndex        "47"^^xsd:nonNegativeInteger ;
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
"@id": "http://lynx-project.eu/doc/samples/doc007",
"text": "Welcome to Madrid in 2019, specifically Cercedilla.",
"offset_end": "51",
"id_local": "doc007",
"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 itsrdf: <http://www.w3.org/2005/11/its/rdf#> .
<http://lynx-project.eu/doc/samples/doc007>
a lkg:LynxDocument, nif:Context ;
lkg:metadata    [ eli:id_local  "doc007" ;
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.
This Section is under review and the contents do not currently hold.
Lynx Document Validator Sandbox
Sample LynxDocuments doc001.json doc002.json doc003.json doc004.ttl doc005.json doc006.json doc007.json doc008.json
The first validation takes ~20 sec.
These rules are under revision.
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.
This ontology is identified by this URI:
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#>
Lynx Annotation
Lynx Document
Lynx Document Part
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
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)
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.)
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
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
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
@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 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
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
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
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
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-*
legal expression
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
Standard c back to ToC or Class ToC
IRI: http://lkg.lynx-project.eu/def/Standard
Type of LynxDocument for Standards
Technical Specification c back to ToC or Class ToC
IRI: http://lkg.lynx-project.eu/def/TechnicalSpecification
Type of LynxDocument for Technical Specifications.
has DBpedia
has Eli
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.
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
legal expression or legal resource
metadata op back to ToC or Object Property ToC
Document metadata. See the properties under this elements in http://lynx-project.eu/doc/lkg/#idtablemetadataelements
has characteristics: functional
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.
Lynx Document Part c
Lynx Document c or Lynx Document Part c
has authority
has Wikipedia
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 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 PDF dp back to ToC or Data Property ToC
IRI: http://lkg.lynx-project.eu/def/hasPDF
Link to the PDF version. Single URI.
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.
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).
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
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." .
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
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
declar declaration
exc_let echange of letters
memorandum_underst memorandum of understandment
agree_prot protocol to the agreement
pro protocol
Table: eli:type_document values in Spain
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
bgbl Bundesgesetzblatt
lgbl Landesgesetzblatt
Table eli:type_document values in Ireland
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.