ELI technical guide.
Date: 2018-05-23
Institutions: Publications Office of the European Union
Subjects: EU law - national law, Publications Office of the European Union, access to EU information, dissemination of EU information, documentation centre, information centre, legislation, on line data service, provision of services, user guide

      technical  
guide

Author, ELI Taskforce

SECOND EDITION

More information on the European Union is available on the internet (http://europa.eu). 

Luxembourg: Publications Office of the European Union, 2018

Print

PDF

ISBN 978-92-78-41761-1

doi:10.2830/81801

OA-04-18-232-EN-C

ISBN 978-92-78-41757-4 

doi:10.2830/51169

OA-04-18-232-EN-N

EPUB

ISBN 978-92-78-41760-4

doi:10.2830/54913

OA-04-18-232-EN-E

© European Union, 2018
Reproduction is authorised provided the source is acknowledged. 

Printed in Luxembourg

Printed on elemental chlorine-free bleached paper (ecf)

 technical  

guide

Author, ELI Taskforce

SECOND EDITION

This document is a technical guide written in the form of a FAQ (frequently asked 
questions) on the implementation of the European Legislation Identifier (ELI) by 
Member States. It covers the following aspects:

  ELI URI identifiers;

  ELI ontology;

  ELI metadata publishing.

Its target audiences are developers or project managers that need to implement 
ELI in their legal publishing system.

Contents

Foreword .................................................................................. 7

1.  Introduction and scope of the document .......................... 9
1.1. 
Intended audience ............................................................................................. 9
1.2.  ELI ontology version .......................................................................................... 9
1.3.  How to read this document ......................................................................... 9
1.4.  URI abbreviations used in this document ........................................... 9

2.  ELI URI identifiers ...........................................................11
2.1.  Understanding ELI URI identifiers ...........................................................11

2.1.1.   What is a URI? What is the difference between it 

 and a URL? ................................................................................................11
2.1.2.  How can I create ELI identifiers? .................................................12
2.1.3.  How can I use ‘alias URIs’? What is the benefit? .................12
2.1.4.   What are ‘incomplete ELIs’? What should be the 

 associated behaviour? .......................................................................13
2.1.5.  What are examples of ELI URI identifiers? .............................13
2.1.6.  Where are the ELI identifier schemes published? ............14
2.2.  Building URI identifiers ..................................................................................14
2.2.1.  What components can I use to create ELI identifiers? ..14
2.2.2.   Should I use two-letter codes or three-letter codes 

 for the {language} component in ELI identifiers? ............16

2.2.3.   How do I create ELIs for subdivisions (articles and 

 paragraphs)? ............................................................................................16

3. 

 ELI ontology  
(data model) ...................................................................17
3.1.  ELI ontology overview ...................................................................................17
3.1.1.  What is the ELI ontology? ................................................................17
3.1.2.  What is the ELI ontology namespace? ....................................17
3.1.3.  What is the rationale behind the ELI ontology? ................17
3.1.4.  What is the ELI ontology not? .......................................................17
3.1.5.   Why is the ELI ontology based on English terms? 

 Why is it not multilingual? ..............................................................18
3.1.6.  What’s new in version 1.1 of the ontology? .........................18
3.1.7.  How do I transition from ELI 1.0 to ELI 1.1? ..........................19

3

 
 
 
 
 
ELI technical guide

3.2.  Other ontologies reused by ELI ................................................................21
3.2.1.  What is FRBR and why is ELI based on it? ..............................21
3.2.2.  What is Dublin Core and why is ELI based on it? ..............22
3.2.3.  What is SKOS and why is ELI based on it? .............................22
3.3.  ELI ‘backbone’ classes ......................................................................................23
3.3.1.  What is an ‘eli:LegalResource’? ......................................................23
3.3.2.  What is an ‘eli:LegalExpression’? ...................................................23
3.3.3.  What is an ‘eli:Format’?.......................................................................24
3.3.4.   How can legal resources be grouped together 

 (physically or logically)? ....................................................................24
3.3.5.  What is an ‘abstract legal resource’? ..........................................24
3.4.  ELI properties .......................................................................................................25
3.4.1.  What are the mandatory properties in ELI? .........................25
3.4.2.  What are the important properties in the ELI ontology? ....25
3.4.3.   What kinds of link between LegalResource and 

 LegalExpression can be asserted using ELI? ........................26

3.4.4.   What are the properties common to the three levels

 eli:LegalResource, eli:LegalExpression and eli:Format? ....27

3.4.5.   Why is the domain/range of some properties defined 

 as (eli:LegalResource or eli:LegalExpression)? .....................27

3.4.6.   Why are some properties duplicated as object 

 and datatype properties (e.g. eli:publisher vs 
 eli:publisher_agent?) ..........................................................................28
3.4.7.  What are the possible values for eli:in_force? .....................29
3.4.8.  What are the possible values for eli:legal_value? .............29
3.4.9.   What are the possible values for eli:language? ..................30
3.4.10.   What are the possible values for eli:relevant_for 

    and eli:jurisdiction? ..........................................................................30

3.4.11. Why does ELI use a custom annotation property to

   map to Dublin Core rather than rdfs:subPropertyOf? ....30
3.5.  Combining and extending the ELI ontology ...................................31
3.5.1.   I cannot find the property/class I need in ELI, but 

 I know it exists in some other ontology. Can I use it 
 in combination with ELI? .................................................................31

3.5.2.   I cannot find the property/class I need in ELI, or 

 anywhere else. Can I extend ELI with my own 
 property/class? ......................................................................................31

3.5.3.   What is likely to change in/be added to ELI in 

 the future? ................................................................................................32

4

 
 
 
 
 
 
 
 
 
 
 
 
 
 ELI metadata publication ..............................................33
4. 
4.1.   Implementing the ELI ontology in my context ..............................33
4.1.1.   What should I identify in the context of ELI? ......................33
4.1.2.   What should I consider a LegalResource and what 

 should I consider a LegalExpression? ......................................34

4.1.3.   My legal resources are all monolingual. Should I still 
 use the FRBR distinction between a LegalResource 
 and a LegalExpression? .....................................................................34

4.1.4.   I want to link to an EU directive with eli:transposes 
 or eli:applies. Should I refer to the LegalResource of 
 the EU directive or to one of its language-specific 
 LegalExpressions? ................................................................................34

4.1.5.   ELI ontology defines inverse properties (eli:changes/

 eli:changed_by, eli:realizes/eli:is_realized_by, etc.). 
 Should I express the information both ways, or 
 can I express it in only one way? ................................................35

4.1.6.   What is the recommended way to describe a subdivision

  of a legal act in ELI, like a section or article? ...........................35
4.2.   Defining my own controlled values for ELI properties ..............36
4.2.1.  What are the lists of values I need to define? .....................36
4.2.2.  How can I define my own lists of values? .............................36
4.2.3.   How can I publish and advertise the lists of values 

 I define? Which tool can I use? .....................................................36
4.3.  Using RDFa to disseminate my metadata ..........................................37
4.3.1.   What is the recommended way of disseminating 

 ELI metadata? .........................................................................................37
4.3.2.  Where can I learn more about RDFa? ......................................37
4.3.3.  Do I need RDFa Lite or RDFa Core?............................................38
4.3.4.  How can I test if my RDFa markup is correct? ....................38
4.3.5.   Which tool can I use to check if my ELI metadata is 

 correct? .......................................................................................................39

4.3.6.   The structure of my HTML pages is complex and 

 does not allow easy RDFa tagging. What are possible 
 workarounds? .........................................................................................39

4.3.7.   Should the content of the text itself be tagged 

  in RDFa? .....................................................................................................39

4.3.8.   Which RDFa programming library can I use to 

  parse RDFa metadata? .....................................................................39

4.3.9.   Which tools can I use to visualise the graph of 

 RDF triples encoded in a page? ..................................................40

5

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4.4.  Beyond RDFa: the dissemination process ..........................................40

4.4.1.   My publication process relies on XML. Can I 

 embed ELI metadata inside XML documents? ..................40

4.4.2.   We do not have structured metadata associated 
 to our legislation files. Can we create ELI notices 
 by hand? ....................................................................................................41

4.4.3.   ELI is RDF. Do I need an RDF database (triplestore) to 

 publish ELI metadata in RDF? .......................................................41

4.4.4.   Should I use a redirect or a forward to implement 

 ELI URI access? ........................................................................................41

4.4.5.   Besides RDFa are there other means of disseminating 

 ELI metadata? .........................................................................................41
4.4.6.  What is content negotiation? .......................................................42
4.4.7.   Where can I search for tools and technologies on 

 semantic web in general? ...............................................................43

4.4.8.   What is schema.org and what is the legal.schema.org

 extension? How can I use them? What are the benefits?...43
4.5.  ELI tools ...................................................................................................................44
4.5.1.  What is the ELI validator? .................................................................44
4.5.2. What is the ELI annotation tool? .................................................45
4.5.3.  What is ELI/XML? ...................................................................................46

6

ELI technical guide 
 
 
 
 
 
 
 
Foreword 

The present guide was created by the ELI Taskforce and is aimed 
at developers or project managers who want to implement ELI in 
their legal publishing systems. 

The ELI Taskforce was set up in December 2012, under the auspices 
of the Council of the European Union Working Party on E-law, to 
study the future development of the ELI standard. 

The task force aims to help Member States wishing to adopt ELI by 
sharing knowledge and expertise.

More information is available on the website:  
http://eurlex.europa.eu/eli.

7

1.  Introduction and scope 

of the document

Intended audience

1.1. 
ELI (European Legislation Identifier) is an initiative to improve ac-
cess to European Union legislation and to the legislation of the EU 
Member States.

This document is written with a technical audience in mind and 
is made to help developers and project managers implement ELI 
in their country.

1.2.  ELI ontology version
This guide refers to version 1.1 of the ELI ontology.

1.3.  How to read this document
This document is written as a FAQ (frequently asked questions). It 
tries to be as close as possible to the real questions that the imple-
mentation of ELI can raise from a technical point of view. It builds 
on the questions and the feedback gathered from the first imple-
mentations of ELI in a few Member States.

This document is divided into three main parts, corresponding to 
the three pillars of ELI.

  ELI URI identifiers.

  ELI ontology (data model).

  ELI metadata publication.

Each section title in this document corresponds to a question, with 
the answer given in the text of the section. After each answer, refer-
ences to other questions in the document about related topics are 
also included.

1.4.  URI abbreviations used in this document
Full URIs are cited in the text of this document in monospace font, 
enclosed by angle brackets, for example <http://example.org/ns/
example>.

URIs are also cited in the text of this document in an abbreviated 
form. Abbreviated URIs are cited in monospace font without angle 

9

brackets, and should be expanded using the table of abbreviations 
below.

URI

Abbreviation

http://data.europa.eu/eli/ontology#

http://www.w3.org/1999/02/22-rdf-syntax-ns# 

http://www.w3.org/2000/01/rdf-schema#

http://www.w3.org/2004/02/skos/core#

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

eli:

rdf:

rdfs:

skos:

dct:

So, for example, eli:LegalResource is an abbreviation of  
<http://data.europa.eu/eli/ontology#LegalResource>.

10

ELI technical guide2. ELI URI identifiers

2.1.  Understanding ELI URI identifiers

2.1.1.   What is a URI? What is the difference between it and 

a URL?

URI  stands  for  Uniform  Resource  Identifier.  As  such,  a  URI  serves  to 
identify things on the web: documents, people, concepts, areas, etc. 
Anything (from the real world) can be identified by a URI.

URL stands for Uniform Resource Locator. As such, a URL serves to 
locate a document on the web: a page, an image, a video, etc. Every 
document has (at least) one URL on the web.

As URIs are unique identifiers for real-world things, they do not neces-
sarily  correspond  to  the  URL  of  a  document.  In  other  words,  if  you 
copy-paste a URI in the address bar of your browser, you may get an 
HTTP 404 ‘Document not found’ error. This is OK though, and does not 
mean that this URI is wrong or that the system is broken. That being 
said, a lot of URIs are also URLs, and will indeed return to a page when 
dereferenced.

In  the  context  of  ELI,  URIs  are  used  to  identify  legal  resources,  their 
expressions in specific languages and formats, agents that passed or 
made the law, geographic areas, languages and other concepts. Any-
thing needed to express ELI metadata is identified by a URI.

In  the  context  of  ELI,  URIs  are  said  to  be  constructed  using ‘compo-
nents’. A URI component is a piece of information used as part the URI, 
like {year}, {type_document}, {language}, etc. Components are usually 
separated by ‘/’, for example http://example.eu/eli/{type_document}/
{year}/{language}. 

See also:

  What should I identify in the context of ELI?

  Should I use a redirect or a forward to implement ELI URI 

access?

11

2.1.2.  How can I create ELI identifiers?
There are some guidelines to follow when creating URIs in the con-
text of ELI.

  Create identifiers that are close to how your users cite legislation. 
Do not use opaque or obscure identifiers that no one would un-
derstand. The identifier should be ‘readable’ by end users.

  Create identifiers with components that are stable over time. A 
typical counterexample is the names of ministries: they change 
quite often, and identifiers should not be based on them.

  Create  identifiers  using  a  sensible  and  ‘hackable’  hierarchical 
structure of components: your users should be able to ‘hack’ the 
URI by removing components from it (typically by removing the 
last components).

See also:

  What are examples of ELI URI identifiers?

  What components can I use to create ELI identifiers?

2.1.3.  How can I use ‘alias URIs’? What is the benefit?
We can distinguish two types of ELI identifier.

1.  Canonical URIs. The official URI to identify a resource. Typically 
this URI would be used as the subject of the RDF triples used to 
encode the data, and would be the one stored as the primary 
key in a metadata database, if such a database existed.

2.  Alias URIs. Other URIs referring to resources that are identified 
by a canonical URI. These alias URIs can serve as alternative ways 
for users to identify or access the corresponding resource, but 
are typically not used when expressing metadata internally.

France, for example, already uses an identifier for legislation called 
‘NOR’. This technical identifier, although unique, is unknown to most 
users. This is why two ELIs are defined, one using the NOR and one 
using the natural  number. This allows users that do not know the 
NOR to still create a link or process the metadata associated with the 
legislation. As an example, the ELI using the NOR http://legifrance.
gouv.fr/eli/loi/2014/10/13/AGRX1324417L/jo/texte  has  the  alias 
http://legifrance.gouv.fr/eli/loi/2014/10/13/2014-1170/jo/texte

See also:

  What are examples of ELI URI identifiers?

12

ELI technical guide2.1.4.   What are ‘incomplete ELIs’? What should be the 

associated behaviour?

Full ELI URIs (canonical or alias) serve as identifiers for legislation. 
Furthermore, it is desirable that these URIs have a sensible behav-
iour when a user is creating a link to the beginning of the URI only, 
with only the first URI components. This allows users to more easily 
find their way in legislation.

For example, the Publications Office of the European Union defines 
the  canonical  ELI  for  directives  and  regulations  as  /eli/{typedoc}/
{year}/{natural_number}/oj.  Consequently,  the  following  URI  pat-
terns are also defined with their associated behaviour:

  /eli/{typedoc}  should  return  a  (paginated)  list  of  all  the  docu-

ments of the given type;

  /eli/{typedoc}/{year}  should  return  a  (paginated)  list  of  all  the 

documents of the given type published in the given year;

  /eli/{typedoc}/{year}/{natural_number}  should  redirect  to  the 
latest  consolidated  version  or  base  act  of  the  document  with 
the given document type, year and number.

Although ‘incomplete  ELIs’  are  strictly  speaking  not ‘identifiers’,  in 
the sense that they do not identify a resource in the system, they 
ease resource discovery and make the system more consistent.

2.1.5.  What are examples of ELI URI identifiers?
The ELI patterns given below should not be regarded as full docu-
mentation of the ELI of each institution but are here to serve as an 
illustration of how ELIs can be defined. Special cases apply for each 
of the given patterns.

Publications Office:

  http://data.europa.eu/eli/{typedoc}/{year}/{natural_number}/oj: 

canonical ELI to identify a directive or regulation;

  http://data.europa.eu/eli/{typedoc}/{year}/{natural_number}/
corrigendum/{publication_date}/oj:  canonical  ELI  to  identify  a 
corrigendum;

  http://data.europa.eu/eli/{typedoc}/{year}/{natural_number}/

{point-in-time}: canonical ELI to identify a corrigendum;

  etc.

13

France:

  /eli/{type}/{year}/{month}/{day}/{natural identifier}/{version}/{level}/
{point-in-time}/fr/{format}:  canonical  identifier  for  texts  except 
codes;

  /eli/{type}/{year}/{month}/{day}/{natural identifier}/{version}/texte/

{point-in-time}: shortcut for the HTML version of the text;

  etc.

The  {natural  identifier}  component  can  be  the  NOR  (unique  text 
identifier) or an identifier based on the year and law number.

Ireland:

  http://www.irishstatutebook.ie/eli/{year}/{type}/{natural identifier}: 
identifies an act as enacted and published on the electronic Irish 
Statute Book (eISB);

  http://www.irishstatutebook.ie/eli/cons/{point in time}/{language}: 
the  version  of  the  constitution  in  the  given  language  as  pub-
lished on the eISB at a particular point in time (publication date);

  etc.

Luxembourg:

  http://eli.legilux.public.lu/eli/etat/leg/{type}/{year}/{month}/

{day}/{id}: identifies a law published in the Mémorial;

  etc.

Other URI patterns are described in the ELI registry on EUR-Lex.

2.1.6.  Where are the ELI identifier schemes published?
The Publications Office keeps a registry of the ELI identifier schemes 
used by the Member States that have implemented ELI (1).

2.2.  Building URI identifiers

2.2.1.  What components can I use to create ELI identifiers?
ELI proposes using the following components to create URIs. They 
are all optional, and can be used in any order, depending on how 
the law is cited. The recommended format provides a guideline for 
the value, but is not an absolute requirement.

(1)  ELI registry on EUR-Lex: http://eur-lex.europa.eu/eli-register/about.html

14

ELI technical guideELI Component

Recommended format

Additional remarks

{jurisdiction}

Two-letter country 
codes

{agent} and  
{sub-agent}

No recommended 
format

{year}: four digits

{year}, {month}  
and {day}

{month} and {day}: 
two digits

{type} and  
{subtype}

{natural identifier}

No recommended 
format

No recommended 
format

Codes for administrative 
hierarchical structures and 
substructures. Member States need 
to define their own values.

The components do not have to be 
used together (e.g. {year} can be 
used without {month} or {day})

Nature of the act (law, decree, draft 
bill, etc.). Member States need to 
define their own values.

{domain}

Thematic classification. Member 
States need to define their own 
values.

{level 1} {level 2} 
and {level N}

No recommended 
format but see also 
2.2.3

Reference to a subdivision or to a 
smaller legislation subdivision (e.g. 
articles and paragraphs).

{point in time}

YYYYMMDD or YYYY-
MM-DD

To retrieve the version of the 
legislation valid at a given date. 
Note that the Council conclusions 
inviting the introduction of the ELI 
only recommend YYYYMMDD, but 
implementations using YYYY-MM-
DD would still be valid.

No recommended 
format

To distinguish between a base act 
and a consolidated version.

Three-letter 
language codes (ISO-
639-1)

A file format, like 
‘PDF’ or ‘HTML’

To distinguish different linguistic 
variants of a piece of legislation.

Note that the Council conclusions 
inviting the introduction of the 
ELI does not list this component 
explicitly, but it is always part of the 
URIs to identify the eli:Format level.

{version}

{language}

{format}

See also:

  What should I identify in the context of ELI?

15

2.2.2.  Should I use two-letter codes or three-letter codes 

for the {language} component in ELI identifiers?
ELI explicitly recommends using three-letter codes for the {language} 
component  when  building  ELI  URIs  (ISO-639-2).  See  the  code-list 
page (2) for the list of language codes.

That being said, implementations using two-letter language codes 
would still be valid. It is expected in that case that an alias mecha-
nism would be implemented from one to the other.

2.2.3.   How do I create ELIs for subdivisions (articles and 

paragraphs)?

When  crafting  ELIs  for  subdivisions,  the  user  needs  to  combine  a 
code to identify the subdivision type (section, article, paragraph, etc.) 
and the number or identifier of the subdivision (1, A, 1.5.9, etc.). There 
are two ways to make this combination.

1.  Separate  the  subdivision  type  and  number  with  a  slash,  like 
other  components  in  the  URI,  for  example  /eli/law/2015/123/
article/3/paragraph/2.

2.  Concatenate the subdivision type and its number into a single 
component, using another separator, typically underscore ‘_’, for 
example /eli/law/2015/123/article_3/paragraph_2.

Solution 2 above is preferred, since solution 1 would imply incom-
plete ELIs that do not make sense, like /eli/law/2015/123/article/3/
paragraph and /eli/law/2015/123/article.

See also:

  What are ‘incomplete ELIs’? What should be the associ-

ated behaviour?

  What is the recommended way to describe a subdivision 

of a legal act in ELI, like a section or article?

(2) 

ISO-639-3 codes list: http://www-01.sil.org/iso639-3/codes.asp 

16

ELI technical guide3.  ELI ontology  
(data model)

3.1.  ELI ontology overview

3.1.1.  What is the ELI ontology?
The  ELI  ontology  defines  a  core  model  for  describing  legal  re-
sources, aimed at supporting linked data publishing of these legal 
resources’  metadata,  specifically  across  the  European  Union.  It  is 
based on the FRBR model and accommodates the differences in 
national  legal  systems  to  build  a  semantic  web  of  legal  gazettes 
and official journals.

See also:

  What is the ELI ontology not?

  What is FRBR and why is ELI based on it?

3.1.2.  What is the ELI ontology namespace?
http://data.europa.eu/eli/ontology#, usually abbreviated using the 
prefix eli:. This URI resolves to the OWL file of the ontology.

3.1.3.  What is the rationale behind the ELI ontology?
The ELI ontology is a model for sharing legal resources metadata 
across the web. As such, it tries to be:

  flexible, to accommodate the different point of view of the vari-

ous legal systems in the EU;

  generic, to foster interoperability between the legal metadata 

published;

  easy to use and well documented, to allow for simple deploy-

ment by Member States;

  open, by building on standard semantic web technologies (RDF, 

OWL) and vocabularies (FRBR, SKOS, Dublin Core).

3.1.4.  What is the ELI ontology not?
The ELI ontology is not the following.

  The definitive model to describe legal resources. It is the result 
of compromises for publishing metadata about legal resources 

17

on the web, and as such makes simplifications on the attributes 
and relations used. Other data models, used internally in editorial 
systems for example, are much more detailed.

  A document model to describe the structure of the legal docu-
ments themselves. ELI captures only the metadata of the docu-
ments.

3.1.5.   Why is the ELI ontology based on English terms? 

Why is it not multilingual?

ELI URIs are technical identifiers. As such, they should be unique to 
the notion they represent. They could have been based on totally 
opaque strings of characters (e.g. eli:ab09j5), but building identifi-
ers based on words makes the model and the data more readable. 
English was chosen because other vocabularies already use English 
words as the basis for their identifiers, and it was a language shared 
by all the members of the ELI Taskforce.

In  the  future,  multilingual  labels  could  be  associated  with  each 
technical identifier. Member States are encouraged to provide their 
translations of the ELI ontology.

3.1.6.  What’s new in version 1.1 of the ontology?
In mid 2016, the ELI Taskforce upgraded the ELI ontology from 1.0 to 
1.1, integrating the comments received during the first round of work-
shops and the experience gained during the first implementations.

ELI 1.1 contains the following enhancements over 1.0.

  The following properties were added:

•  eli:is_member_of/eli:has_member

•  eli:number

•  eli:jurisdiction

•  eli:date_applicability

•  eli:applies/eli:applied_by

•  eli:commences/eli:commenced_by

•  eli:repeals/eli:repealed_by

•  eli:corrects/eli:corrected_by

•  eli:amends/eli: amended_by

•  eli:is_another_publication_of/eli:has_another_publication.

18

ELI technical guide  Additional properties were also added to accommodate situations 

in which a property value can be either a literal or a URI:

•  eli:responsibility_of_agent vs eli:responsibility_of

•  eli:published_in_format vs eli:published_in

•  eli:publisher_agent vs eli:publisher

•  eli:rightsholder_agent vs eli:rightsholder.

  The  relationship  with  Dublin  Core  properties  is  now  declared 
using a custom annotation property eli:isSpecificPropertyOf in-
stead of rdfs:subPropertyOf to be able to relate both eli:publisher/
eli:publisher_agent  to  dcterms:publisher  and  eli:rightsholder/
eli:rightsholder_agent to dcterms:rightsholder.

  The class eli:LegalResourceSubdivision was added.

  The  property  eli:implements/eli:implemented_by  was  depre-

cated in favour of eli:applies/eli:applied_by.

  Numerous definitions were improved and clarified.

  All ontology items are now documented with:

• 

• 

their version of creation;

their version of latest modification;

•  a history note documenting the changes on the item.

See also:

  Why does ELI use a custom annotation property to map 

to Dublin Core rather than rdfs:subPropertyOf?

  Why are some properties duplicated as object and data-
type properties (e.g. eli:publisher vs eli:publisher_agent?)

  What are the possible values for eli:relevant_for and 

eli:jurisdiction?

  How do I transition from ELI 1.0 to ELI 1.1?

3.1.7.  How do I transition from ELI 1.0 to ELI 1.1?
ELI 1.1 is backwards-compatible, with the exception indicated below 
in the ‘MUST’ clause. To transition from ELI 1.0 to ELI 1.1, data publishers:

  MUST  use  eli:is_member_of/eli:has_member  instead  of  eli:is_
inclusions.  eli:has_part/

part_of/eli:has_part  for  conceptual 
eli:is_part_of should be used only for physical inclusions;

19

  are STRONGLY ENCOURAGED to:

•  use eli:publisher_agent, eli:rightsholder_agent, eli:responsibility_
of_agent, eli:published_in_format whenever a URI is available to 
identify the property value, instead of the corresponding datatype 
property (kept only for situations in which a URI is not available),

•  use an identifier from the Administrative Territorial Unit table 
published by the Publications Office as value for the property 
eli:relevant_for, instead of a custom URI,

•  use  eli:applies/eli:applied_by 

instead  of  eli:implements/
eli:implemented_by  —  note  however  that  eli:implements/
eli:implemented_by  currently  remain  in  the  ontology  so 
publishers can take the time to transition smoothly;

  SHOULD use new items in ELI 1.1 in the following situations:

•  use eli:LegalResourceSubdivision instead of eli:LegalResource 
to  type  the  subcomponents  of  an  act  (articles,  paragraphs, 
sections, etc.),

•  use eli:number instead of eli:id_local to indicate the number 

of a resource or article,

•  use eli:jurisdiction instead of eli:relevant_area to indicate the 

jurisdiction of a legal resource,

•  whenever applicable, use specific types of links instead of the 

generic property eli:changes/eli:changed_by:

•  eli:commences/eli:commenced_by,

•  eli:repeals/eli:repealed_by,

•  eli:corrects/eli:corrected_by,

•  eli:amends/eli:amended_by.

See also:

  What’s new in version 1.1 of the ontology?

  What are the possible values for eli:relevant_for and 

eli:jurisdiction?

20

ELI technical guide3.2.  Other ontologies reused by ELI

3.2.1.  What is FRBR and why is ELI based on it?
FRBR stands for Functional Requirements for Bibliographic Records. 
It is a conceptual model created by library experts, and it separates 
the information attached to a record into four categories:

  properties describing the individual exemplar (e.g. author’s ded-

ication on the first page);

  properties  of  the  edition  to  which  the  exemplar  belongs  (e.g. 

the publisher);

  properties of its intellectual content (e.g. the language of the text);

  properties of the artistic creation (e.g. keywords);

These four categories are named as follows in FRBR:

  Item;

  Manifestation;

  Expression;

  Work.

FRBR is a conceptual model (i.e. on paper) and it is implemented in 
the RDA (Resource Description and Access) vocabularies. RDA defines 
URI identifiers for classes and properties of FRBR. ELI extends the RDA 
vocabulary to refine the notions of Work (eli:LegalResource), Expres-
sion (eli:LegalExpression) and Manifestation (eli:Format). The Item level 
is not part of ELI.

The separation into multiple conceptual levels allows users to:

  create links to or from a precise description level — to an electron-
ically-signed OJ, a given consolidated version of a text or the text 
in general;

  factor  some  information  and  not  repeat,  for  example,  the  type 
of the document (‘Directive’) for every single format (‘PDF’, ‘Print’, 
‘HTML’, ‘XHTML’, etc.): the type of document is a property expressed 
in the Work category, and is not repeated for each Manifestation.

See also:

  What is an ‘eli:LegalResource’?

  What is an ‘eli:LegalExpression’?

  What is an ‘eli:Format’?

  My legal resources are all monolingual. Should I still use 
the FRBR distinction between a LegalResource and a 
LegalExpression?

21

3.2.2.  What is Dublin Core and why is ELI based on it?
Dublin Core Metadata Terms is a set of 55 metadata attributes that 
can be used to describe web resources (video, images, web pages, 
etc.), along with physical resources such as books or CDs and objects 
like artworks. It covers generic notions like ‘creator’, ‘date’, ‘rights’, etc.

ELI properties are mapped to the corresponding Dublin Core meta-
data. For example, the ELI properties eli:title_alternative and eli:title_
short  are  mapped  to  the  Dublin  Core  metadata ‘alternative  (title)’, 
and  the  ELI  properties  eli:transposes/eli:transposed_by,  eli:cites/
eli:cited_by and all the other relations in ELI are mapped to the Dub-
lin Core metadata ‘relation’.

This mapping declaration makes the model easier to understand.

In ELI 1.1, the mapping is not declared using ‘rdfs:subPropertyOf’, but 
rather using a custom annotation property ‘eli:isSpecificPropertyOf’.

See also:

  What are the important properties in the ELI ontology?

  Why does ELI use a custom annotation property to map 

to Dublin Core rather than rdfs:subPropertyOf?

3.2.3.  What is SKOS and why is ELI based on it?
SKOS  stands  for  Simple  Knowledge  Organization  System.  It  is  a  data 
model to structure controlled vocabularies, thesauri, authority tables, etc. 
The notion of a ‘Concept’ is central to SKOS, and these Concepts can be:

  labelled with preferred or alternative labels;

  organised with semantic relations, hierarchical or transversal;

  documented by definitions, notes, examples, etc.;

  mapped to Concepts of other vocabularies.

ELI uses SKOS to declare the list of possible values for the properties 
eli:in_force and eli:legal_value.

ELI also uses SKOS to state that some other properties need to have a 
value in a controlled value set, but leaves open the list of possible val-
ues. This is the case for eli:type_document, eli:version, eli:passed_by 
and eli:relevant_for.

See also:

  What are the possible values for eli:in_force?

  What are the possible values for eli:legal_value?

  What are the lists of values I need to define?

22

ELI technical guide3.3.  ELI ‘backbone’ classes

3.3.1.  What is an ‘eli:LegalResource’?
A legal resource is a distinct intellectual creation (i.e. intellectual con-
tent). For example, the notion of ‘Act 3 of 2005’, without specifying in 
which language (if in a multilingual context) and without specifying 
in which format, would be considered a legal resource.

Legal resources can be described and linked together using proper-
ties defined in the model. A legal resource can represent a legal act 
or any component of a legal act, like an article. A specific subclass 
of LegalResource, LegalResourceSubdivision, has been introduced in 
ELI 1.1 and can be used to give the type of components of legal acts.

See also:

  What should I consider a LegalResource and what should 

I consider a LegalExpression?

  How can legal resources be grouped together (physically 

or logically)?

  What is the recommended way to describe a subdivision 

of a legal act in ELI, like a section or article?

3.3.2.  What is an ‘eli:LegalExpression’?
A legal expression is the intellectual realisation of a legal resource in 
the form of a ‘sequence of signs’ (typically alphanumeric characters).

For example, any version of the legal resource with content that is 
specified  and  different  from  others  for  any  reason:  language,  ver-
sions, etc.;

Legal expressions must be linked to the legal resource they express 
using the eli:realizes property. A legal expression cannot exist with-
out being linked to a single legal resource, and the eli:realizes prop-
erty is mandatory.

See also:

  What should I consider a LegalResource and what should 

I consider a LegalExpression?

  My legal resources are all monolingual. Should I still use 
the FRBR distinction between a LegalResource and a 
LegalExpression?

23

3.3.3.  What is an ‘eli:Format’?
A format is the physical embodiment of a legal expression, either 
on paper or in any electronic format.

For example, any electronic or physical format of the legal expres-
sion  (XML, TIFF,  PDF,  etc.),  for  example  a  PDF  version  of  Act  3  of 
2005, would be considered a format.

Formats must be linked to the legal expression they embody, using 
an eli:embodies property.

Formats refer to the actual file URL of the corresponding document 
with the eli:is_exemplified_by property.

See also:

  What are the possible values for eli:legal_value?

3.3.4.   How can legal resources be grouped together  

(physically or logically)?

Legal resources can be grouped together using either eli:has_part 
and eli:is_part_of, for physical/structural inclusion, or eli:has_mem-
ber and eli:is_member_of, for logical/temporal inclusion.

When you need to declare that a legal resource is included in an of-
ficial journal, this is a physical relationship, so you use eli:is_part_of. 
When you need to declare that the consolidated version of an act 
‘belongs to’ the same abstract act as the base act, this is a temporal 
relation, so you use eli:is_member_of.

There are no restrictions in ELI on the levels of partitions that can be 
asserted: eli:has_part/eli:is_part_of or eli:has_member/eli:is_mem-
ber_of can be used to construct a complete hierarchy of legal re-
sources.

See also:

  What should I consider a LegalResource and what should 

I consider a LegalExpression?

  What is an ‘abstract legal resource’?

3.3.5.  What is an ‘abstract legal resource’?
It is often desirable to group under the same ‘header’ different legal 
resources that represent the same act at different stages of its ‘life 
cycle’. For example, the base act and all of its consolidated versions 

24

ELI technical guidecan be grouped together; or, in common law, the enacted and re-
vised versions of an act can be grouped together.

This grouping is done using the eli:has_member and eli:is_mem-
ber_of properties. The ‘header’ under which the legal resources are 
grouped represent the legislation independently of one of its tem-
poral versions. It allows users to refer to it when they cannot know, 
or do not need to know, to which specific version of the legislation 
they refer.

In that case, this ‘header’ legal resource is often  referred to  as  an 
‘abstract legal resource’. It does not correspond to a specific class in 
the ELI ontology, and is declared using the eli:LegalResource class.

3.4.  ELI properties

3.4.1.  What are the mandatory properties in ELI?
Only a few ELI properties are actually mandatory. It is mandatory 
to assert at least:

  the eli:type_document on an eli:LegalResource;

  the eli:realizes property of an eli:LegalExpression (to link it to an 

eli:LegalResource);

  the eli:title of an eli:LegalExpression;

  the eli:language of an eli:LegalExpression;

  the eli:format of an eli:Format;

  the eli:embodies of an eli:Format (to link it to an eli:LegalExpression).

Each Member State can define a stricter ELI ontology for their use 
(as long as it remains a subset of the current ontology)

3.4.2.  What are the important properties in the ELI ontology?
Although  only  a  few  properties  are  strictly  speaking  mandatory 
in  the  ELI  ontology,  some  descriptive  metadata  are  important  to 
achieve a good level of interoperability.

  eli:transposes: link to the ELI of a directive transposed by an act 
or an article. This is key for achieving interoperability and linking 
EU laws.

  eli:is_about:  indicate  the  subjects  of  the  legislation,  preferably 

expressed using the Eurovoc Thesaurus (3).

(3)  Eurovoc Thesaurus: http://eurovoc.europa.eu

25

  eli:date_document and eli:date_publication: to indicate respec-
tively the date or adoption or signature and the date of publica-
tion of the official version of the legislation.

For  more  information,  see  the  full  documentation  of  the  ELI 
ontology.

See also:

  I want to link to an EU directive with eli:transposes or 

eli:applies. Should I refer to the LegalResource of the EU 
directive or to one of its language-specific LegalExpressions?

3.4.3.   What kinds of link between LegalResource and 
LegalExpression can be asserted using ELI?

ELI  defines  a  number  of  properties  to  relate  LegalResource  or 
LegalExpression  to  each  other. These  links  are  organised  in  the 
following property hierarchy (inverse properties are not listed for 
clarity).

  eli:applies

•  eli:transposes

  eli:based_on

  eli:changes

•  eli:amends

•  eli:commences

•  eli:repeals

  eli:corrects

  eli:cites

  eli:consolidates

  eli:is_another_publication_of

  eli:related_to

Note that the semantic of eli:changes covers the notions of legal 
change, hence eli:corrects, used to describe the corrections of ty-
pos in the text, is not a subproperty of eli:changes.

If an assertion cannot be precisely expressed with one of the properties 
above you should use the generic link eli:related_to or eli:changes if it is 
a legal change, and contact the ELI Taskforce to describe your use case.

For more details, see the full documentation of the ELI ontology.

26

ELI technical guide3.4.4.   What are the properties common to the three levels 

eli:LegalResource, eli:LegalExpression and eli:Format?
Two properties are global in the ELI ontology and can be asserted 
on eli:LegalResource, eli:LegalExpression and eli:Format.

  eli:id_local  indicates  a  corresponding  identifier  in  an  existing 
system (for example an existing identifier of a law, like NOR in 
France).

  eli:uri_schema  indicates  the  URI  template  used  to  build  the  URI 
of the legal resource, legal expression or format. This is expressed 
using the URI template syntax, with components between ‘{‘ and ‘}’, 
for example: http://example.eu/{typedoc}/{year}/{number}.

3.4.5.   Why is the domain/range of some properties defined 
as (eli:LegalResource or eli:LegalExpression)?

The following properties can describe either an eli:LegalResource 
or an eli:LegalExpression.

  eli:relevant_for

  eli:jurisdiction

  eli:in_force

  eli:first_date_entry_in_force,  eli:date_no_longer_in_force  and 

eli:in_force

  eli:date_applicability

  eli:description

  eli:version and eli:version_date

  The following links:

•  eli:related_to

•  eli:changes and eli:changed_by

•  eli:basis_for

•  eli:cites

•  eli:consolidates and eli:consolidated_by

•  eli:commences and eli:commenced_by

•  eli:repeals and eli:repealed_by

•  eli:corrects and eli:corrected_by

•  eli:amends and eli:amended_by

•  eli:transposes and eli:applies

27

This is on purpose, since it allows the ELI model to accommodate 
different points of view on what should be considered a legal re-
source or a legal expression.

For example, a consolidated version can be viewed as new legal 
expression  of  the  same  legal  resource  representing  the  act.  In 
that case, the consolidated version will be an instance of the class 
eli:LegalExpression, and an eli:consolidates property will be assert-
ed on it to link to the modifiers or corrigenda being consolidated. 
But, depending on modelling choices, a consolidated version can 
be considered as a separate legal resource, distinct from the one 
representing the act. In that case, the consolidated version will be 
an instance of the class eli:LegalResource, and the eli:consolidates 
property will be asserted at this level.

3.4.6.   Why are some properties duplicated as object 
and datatype properties (e.g. eli:publisher vs 
eli:publisher_agent?)

To allow data publishers to use a URI value when there is one avail-
able, or otherwise use a string value, while keeping the ELI ontol-
ogy an OWL-friendly ontology.

This is the case for the following pairs or properties.

Datatype property

Object property

eli:publisher

eli:rightsholder

eli:published_in

eli:publisher_agent

eli:rightsholder_agent

eli:published_in_format

eli:responsibility_of

eli:responsibility_of_agent

Note that eli:passed_by has no  datatype  equivalent  and thus re-
quires a URI value. This is on purpose.

See also:

  Why does ELI use a custom annotation property to map 

to Dublin Core rather than rdfs:subPropertyOf?

28

ELI technical guide3.4.7.  What are the possible values for eli:in_force?
The ELI ontology defines a set of values for the property eli:in_force. 
These values are ‘in force’, ‘partially in force’ and ‘not in force’. They are 
defined as SKOS concepts. They are summarised in the table below.

URI

eli:InForce-inForce

eli:InForce-notInForce

eli:InForce-partiallyInForce

Label

in force

not in force

authoritative

3.4.8.  What are the possible values for eli:legal_value?
The ELI ontology defines a set of values for the property eli:legal_value. 
This property is asserted on eli:Format since the legal value depends 
on the (electronic) format of the document (a signed PDF does not 
have  the  same  legal  value  as  the  HTML  version  of  the  same  legisla-
tion). Possible values are ‘unofficial’, ‘official’, ‘authoritative’ and ‘definitive’. 
They are defined as SKOS concepts, and organised hierarchically: 
the notion of being ‘definitive’ is more precise than the notion of being 
‘authoritative’, which is itself a special case of being ‘official’. They are 
summarised in the table below.

URI

Label

DEFINITION

SKOS:BROADER

eli:LegalValue-
unofficial

Unofficial

eli:LegalValue-
official

Official

eli:LegalValue-
authoritative

Authoritative

eli:LegalValue-
definitive

Definitive

Document has no 
particular or special 
standing.

Document is published 
by an organisation 
with the public task of 
making the information 
available (a consolidated 
version of an EU directive 
published by the 
Publications Office).

The publisher gives 
special status to the 
publication of the 
document. (‘The Queen’s 
Printer’ version of a 
UK act of Parliament). 
This status is specific to 
the United Kingdom, 
where no text can be 
considered ‘definitive’.

Document for which 
the text is conclusively 
what the law says. (The 
digitally signed version 
of an Official Journal.)

None

None

eli:LegalValue-
official

eli:LegalValue-
authoritative

29

3.4.9.   What are the possible values for eli:language?
The  eli:language  property  can  use  the  values  defined  in  the  lan-
guage authority table published by the Publications Office (4). ELI 
does not define a set of identifiers for languages. There is no need 
for Member States to declare their own identifiers for languages.

3.4.10. 

 What are the possible values for eli:relevant_for 
and eli:jurisdiction?

The eli:relevant_for and eli:jurisdiction properties can use the val-
ues defined in the Administrative Territorial Unit table published by 
the Publications Office (5). Member States do not have to recreate 
their own list of values.

3.4.11. 

 Why does ELI use a custom annotation property to 
map to Dublin Core rather than rdfs:subPropertyOf?
To allow object properties and datatype properties to be mapped 
to the same Dublin Core metadata.

ELI 1.0 used rdfs:subPropertyOf to map to Dublin Core. This has the 
following disadvantages.

  Since Dublin Core is not available as an OWL file it cannot be 
imported from the ELI ontology, thus the Dublin Core metadata 
needed to be redeclared within the ELI ontology.

  By doing so, ELI forces the Dublin Core metadata to be either 
datatype or object properties (because in OWL the two sets of 
properties are disjoint).

  A  lot  of  inferences  are  automatically  generated  by  reasoners, 

which are not necessarily useful in all situations.

In ELI 1.1 the rdfs:subPropertyOf links to Dublin Core have been re-
placed with a custom annotation property eli:isSpecificPropertyOf. 
Using this:

  ELI  property  pairs  eli:rightsholder/eli:rightsholder_agent  and 
eli:publisher/eli:publisher_agent  can  be  mapped  to  their 
respective  Dublin  Core  counterparts  dct:rightsholder  and 
dct:publisher;

  the Dublin Core metadata do not need to be redeclared within 
the ELI ontology, and ELI does not force a Dublin Core metadata 
to be interpreted as a datatype or an object property;

(4) 

(5) 

 Language authority table of the Publications Office: http://publications.europa.eu/
mdr/authority/language
 Administrative Territorial Unit authority table of the Publications Office:  
http://publications.europa.eu/mdr/authority/atu

30

ELI technical guide  reasoners cannot automatically infer the Dublin Core metadata 
from ELI, but it can be easily done with a single query by applica-
tions that need to do so.

3.5.  Combining and extending the ELI ontology

3.5.1.   I cannot find the property/class I need in ELI,  

but I know it exists in some other ontology.  
Can I use it in combination with ELI?

Yes.  If  the  data  you  publish  is  not  just  about  legal  resources,  but 
about other things that are outside of the scope of the ELI mod-
el,  you  can  publish  them  using  your  own  ontology(-ies)  or  well-
known existing ontologies.

A typical example is if you want to publish the descriptions of the 
agents (persons or organisations) that passed or made the laws. ELI 
does not provide classes and properties for this, but you can use 
the FOAF (6) or ORG (7) vocabularies to publish them, alongside the 
legal resources descriptions.

Another typical use case of combining ELI with another ontology 
is to use properties from other vocabularies (e.g. Dublin Core) to 
assert, on legal resources, legal expressions or formats, additional 
information that are not covered by ELI.

3.5.2.   I cannot find the property/class I need in ELI, or 

anywhere else. Can I extend ELI with my own property/
class?

ELI is not a one-size-fits-all model for describing legal resources. It 
is perfectly fine to refine it with your own, more precise, semantic 
(although this is an advanced use case).

A  typical  example  is  to  refine  the  eli:related_to  generic  property 
and create your own types of link between legal resources. You do 
that by first creating your own OWL ontology and importing the 
ELI  ontology  into  it. You  can  then  create  your  own  property  and 
declare it as a subproperty of eli:related_to. By doing so you will not 
lose the precise semantic of your data, and ELI-compatible systems 
will still be able to understand these links as eli:related_to.

(6)  FOAF: http://xmlns.com/foaf/spec/
(7)  ORG: http://www.w3.org/TR/vocab-org/

31

3.5.3.   What is likely to change in/be added to ELI in the 

future?

Although there is no official commitment on the ELI ontology evo-
lution, possible improvements on the ontology may include, with-
out being limited to:

  new relationships between pieces of legislation;

  better handling of the eli:format property with respect to printed/

paper versions of a piece of legislation;

  extension of ELI to draft legislation;

  extension of ELI to documents related to legislation (opinions, 

preparatory documents, etc.).

  in addition, some range constraints on datatype properties may 

change.

As any evolution proposal requires the collective agreement of all 
the members of the ELI Taskforce, there is no commitment as to 
their implementation.

32

ELI technical guide4.  ELI metadata 
publication

4.1. 

 Implementing the ELI ontology in my 
context

4.1.1.   What should I identify in the context of ELI?
In order to implement ELI, you should as a minimum give an identi-
fier to the pieces of legislation that fall within the scope of ELI (it is 
OK to implement ELI for only part of the legislation). These pieces 
of  legislation  will  actually  be  decomposed  into  three  identifiers 
corresponding to the three levels of the ELI ontology skeleton.

  An identifier for the LegalResource corresponding to the intel-

lectual content of the document.

  One or more identifiers for the LegalExpression(s) of the docu-

ment.

  One or more identifiers for the Format(s) of each expression of 

the document.

Additionally,  you  can  also  choose  to  identify  ‘abstract’  LegalRe-
sources. Such resources would represent a single piece of legisla-
tion, but independently from any of its temporal versions. As such 
this  is  an  abstract  notion  and  does  not  correspond  to  any  real-
world physical objects.

Additionally, in a more advanced ELI deployment, you can also iden-
tify the subparts of the documents, such as articles and paragraphs.

See also:

  How can legal resources be grouped together (physically 

or logically)?

  What is an ‘abstract legal resource’?

  What is the recommended way to describe a subdivision 

of a legal act in ELI, like a section or article?

33

4.1.2.   What should I consider a LegalResource and what 

should I consider a LegalExpression?

It depends. The question arises principally regarding the consolida-
tion of laws. A ‘LegalResource’ represents the intellectual content of 
a document, and a ‘LegalExpression’ represents the realisation of that 
intellectual content in the form of a sequence of signs. Given these 
definitions, you can choose to do either of the following things.

1.  Consider that the consolidated versions of a law represent the 
same intellectual content, with different sequences of signs. In 
this case consolidations would be LegalExpressions of the same 
LegalResource.

2.  Consider  that  the  consolidated  versions  of  a  law  each  have  a 
distinct intellectual content, and consider them as distinct Le-
galResource. In this case you can also link these LegalResources 
to  an ‘abstract’  LegalResource  representing  the  document  in-
dependent  of  its  temporal  version  using  eli:has_member  and 
eli:is_member_of.

When the legislative system is multilingual, scenario 1 above needs 
to  be  considered  with  care,  since  LegalExpressions  are  in  this  case 
used to identify the various translations of a document, and will at the 
same time be used to identify the temporal version of a document. 

See also:

  How can legal resources be grouped together (physically 

or logically)?

4.1.3.   My legal resources are all monolingual. Should I still 

use the FRBR distinction between a LegalResource 
and a LegalExpression?

Yes. Even if they are unofficial, you may have translations of some of 
your laws in other languages. Others may also provide translations of 
your laws, thus creating a new LegalExpression of your LegalResource. 
The  distinction  between  the  Legal  Resource  and  Legal  Expression 
levels is important to create future links to the correct notion.

4.1.4.   I want to link to an EU directive with eli:transposes 

or eli:applies. Should I refer to the LegalResource 
of the EU directive or to one of its language-specific 
LegalExpressions?

It is the directive itself that is transposed, not one of its language vari-
ants. So, when using eli:transposes or eli:applies to assert that a piece 
of legislation transposes or implements a directive, the link must re-

34

ELI technical guidefer to the ELI identifying the LegalResource of the directive, not to an 
ELI identifying one of its language-specific LegalExpressions.

4.1.5.   ELI ontology defines inverse properties (eli:changes/
eli:changed_by, eli:realizes/eli:is_realized_by, etc.). 
Should I express the information both ways, or can I 
express it in only one way?

If it is technically easy to do, try to add the information both ways: 
you will make the work of data consumers a little easier. But this 
should not be an absolute requirement, and if for any reason you 
can express the relationship in only one way this is still valid.

4.1.6.   What is the recommended way to describe a subdivi-
sion of a legal act in ELI, like a section or article?

  Give an ELI URI to each of the subdivision you need to identify.

  Use  the  class  eli:LegalResourceSubdivision  as  the  type  of  re-

source.

  Optionally, use eli:number to describe the number of the sec-

tion or the article.

  Use  eli:is_part_of  to  link  the  subdivision  to  the  whole  act  URI 

and/or to its parent subdivision in the text.

  Since 

eli:LegalResourceSubdivision 

of 
eli:LegalResource, you can use any other ELI metadata to further 
refine the description of the subdivision (indicate relevant area, 
date of entry into force for the article, etc.).

subclass 

is 

a 

See also:

  How do I create ELIs for subdivisions (articles and paragraphs)?

35

4.2.   Defining my own controlled values for ELI 

properties

4.2.1.  What are the lists of values I need to define?
According  to  the  ELI  ontology,  Member  States  need  to  provide 
their own identifiers for the values of the following properties.

  eli:type_document:  identifiers  for  possible  document  types  in 

the legislative system.

  eli:passed_by: identifiers for agents and organisations that pass 

or made the laws (typically ministries).

  eli:version: identifiers for specific states of the law in the legis-
lative  process,  such  as ‘proposed’, ‘consolidated’, ‘signed’, ‘pub-
lished’, etc.

4.2.2. How can I define my own lists of values?
You can define your list of values using SKOS. Each value should have 
at least a URI identifier and a label. Additionally, each value can also 
have translations in other languages, synonyms or can be organised 
hierarchically with other values.

The easiest way to start with these lists is to create an Excel spread-
sheet with two columns — URI and label — for each of the lists you 
need to define.

An ELI annotation tool has been developed to help you to create and 
publish these controlled lists. This annotation tool can be found on 
the ELI registry: http://eur-lex.europa.eu/eli-register/resources.html

See also:

  What is SKOS and why is ELI based on it?

  What is the ELI annotation tool?

4.2.3.   How can I publish and advertise the lists of values I 

define? Which tool can I use?

Typically you can:

  create one HTML page for each list;

  give the values of that list in an HTML table in that page, with 

associated definitions or code for each values, if present;

  propose a SKOS version of the list values for download.

36

ELI technical guideAs a source of inspiration, you can have a look at what the Publica-
tions Office is doing for its authority tables (8).

Page  and  SKOS  file  templates  may  be  provided  in  the  future  to 
make the publication of these lists easier.

The  ELI  annotation  tool  also  provides  a  feature  to  publish  HTML 
pages from controlled vocabularies in SKOS.

See also:

  What is the ELI annotation tool?

4.3.  Using RDFa to disseminate my metadata

4.3.1.   What is the recommended way of disseminating ELI 

metadata?

ELI  recommends  publishing  ELI-compatible  metadata  using  the 
RDFa syntax within the existing HTML pages of the law-publishing 
portal. With RDFa (RDF in [XML] Attributes) you can add semantic 
markup to the HTML formatting markup. This solution:

  avoids duplicating the information (in the page header or in a 

separated file) if it is already presented in the page;

  has  little  impact  on  existing  publishing  systems  since  it  can 
be implemented by updating the HTML generation templates 
without modifying the entire publishing workflow.

See also:

  Besides RDFa are there other means of disseminating ELI 

metadata?

4.3.2.  Where can I learn more about RDFa?
The recommended reading to start learning about RDFa in general 
is the RDFa primer published by the W3C (9).

The RDFa Core specification (10) can be worth referring to when in 
doubt about the result of an RDFa markup.

You  can  search  for  translations  of  these  documents  in  your  lan-
guage in the W3C translation database (11).

(8)  Publications Office authority tables: http://publications.europa.eu/mdr/authority/
(9)  RDFa Primer: http://www.w3.org/TR/xhtml-rdfa-primer/
(10)  RDFa Core specification: http://www.w3.org/TR/rdfa-core/
(11) 

 W3C translation database for RDFa: http://www.w3.org/2005/11/Translations/Query
?titleMatch=rdfa&lang=any&search1=Submit

37

The rdfa.info portal (12) is also a good entry point, listing tools and 
distillers that can take RDFa input and convert it to other RDF for-
mats and validators of RDFa markup.

See also:

   What is content negotiation?

   Where can I search for tools and technologies on semantic 

web in general?

4.3.3.  Do I need RDFa Lite or RDFa Core?
RDFa comes in two flavours: RDFa Lite and RDFa Core. RDFa Lite is 
a small and simple subset of RDFa Core, using only five attributes 
and covering simple data-structuring use cases. Yet, marking up ELI 
metadata will very probably go beyond what is possible with RDFa 
Lite and require some features from RDFa core.

4.3.4.  How can I test if my RDFa markup is correct?
The easiest option is to use the W3C RDFa validator (13), which will 
check whether the markup is correct and produce a validation report.

You can also use the ‘distiller’ service (14) to turn your RDFa markup 
into a set of RDF triples and see if the content is correct according to 
the ELI ontology.

These tools can validate the conformance of your RDF syntax in a ge-
neric way but cannot validate the actual content of the markup against 
the ELI ontology. To do so you should use the ELI validator service.

See also:

  Which tools can I use to visualise the graph of RDF triples 

encoded in a page?

  Which RDFa programming library can I use to parse RDFa 

metadata?

  Where can I search for tools and technologies on semantic 

web in general?

  Which tool can I use to check if my ELI metadata is correct?

(12)  RDFa info portal: http://rdfa.info/
(13)  W3C RDFa validator: http://www.w3.org/2012/pyRdfa/Validator.html
(14)  W3C RDFa distiller service: http://www.w3.org/2012/pyRdfa/

38

ELI technical guide4.3.5.   Which tool can I use to check if my ELI metadata is 

correct?

Use the ELI validator accessible at: http://eur-lex.europa.eu/eli-register/
resources.html

See also:

  What is the ELI validator?

4.3.6.   The structure of my HTML pages is complex and 

does not allow easy RDFa tagging. What are possible 
workarounds?

You can do either of the following things.

1.  Add  all  the  RDFa  markup  right  after  the  <body>  tag,  without 
impacting the HTML page structure. This solution requires that, 
in the publishing process, you have access to all the metadata 
information allowing this RDFa part to be built (see Section 4.3.5 
and the page examples provided).

2.  Use an alternative technology to disseminate your ELI metadata 

(see Section 4.4.5).

See also:

  Besides RDFa are there other means of disseminating ELI 

metadata?

4.3.7.   Should the content of the text itself be tagged in RDFa?
Not usually. Only the metadata part of the page is interesting for 
conveying ELI metadata. The text of the legislation itself does not 
need to be tagged.

4.3.8.   Which RDFa programming library can I use to parse 

RDFa metadata?

The rdfa.info portal lists some possible libraries to use.

  In Java you can use Semargl (15).

  In PHP you can use EasyRDF (16).

  In C look at librdfa (17).

  In Python look at PyRDFa (18), which is the library used by the 

W3C RDFa validator.

(15)  Semargl: https://github.com/levkhomich/semargl
(16)  EasyRDF: http://www.easyrdf.org/
(17)  Librdfa: https://github.com/rdfa/librdfa/
(18)  PyRDFa: http://www.w3.org/2012/pyRdfa/Overview.html#distribution

39

4.3.9.   Which tools can I use to visualise the graph of RDF 

triples encoded in a page?

Viewing a raw RDF graph ‘as is’, with each triple represented as an 
arrow, usually does not produce a satisfying result (in the same way 
as viewing a relational database content by showing directly the 
tables and columns is not the best way to display it).

That being said, producing a visual graph from RDF triples can be 
useful to help others understand the underlying information struc-
ture contained inside the web page.

  A  straightforward  way  to  show  a  simple,  non-customisable 
graph of the RDFA-encoded triples within a page is to use the 
‘Green Turtle’ plugin (19) for the Chrome browser.

  A tool with more features is Welkin (20). You can customise the 
graph a little. You should pass the RDF extracted from the RDFa 
markup using a parser like the W3C distiller service.

  Probably the most comprehensive tool to design graph images 
is Gephi (21), enhanced with its ‘SemanticWebImport’ plugin to 
read RDF files, but it has a steep learning curve.

  Note that the ELI validator is able to parse the RDFa markup of web 
pages, and offers the ability to download the parsed RDF triples so 
they can be integrated and displayed in another application.

See also:

  What is the ELI validator?

4.4.  Beyond RDFa: the dissemination process

4.4.1.   My publication process relies on XML. Can I embed 

ELI metadata inside XML documents?

Yes. The ELI/XML schema is provided for that purpose. Basically you 
can import the ELI XSD schema into your own XML structure and 
add the corresponding ELI metadata into your XML. XSLT stylesheets 
are  then  provided  to  generate  ELI  RDFa  markup  or  RDF/XML  files 
from the ELI XML metadata.

See also:

  What is ELI/XML?

(19) 

 Green Turtle Chrome browser plugin: https://chrome.google.com/webstore/detail/
green-turtle-rdfa/loggcajcfkpdeoaeihclldihfefijjam

(20)  Welkin: http://simile.mit.edu/welkin/
(21)  Gephi: http://gephi.github.io/

40

ELI technical guide4.4.2.   We do not have structured metadata associated to our 

legislation files. Can we create ELI notices by hand?

Yes. The ELI annotation tool is provided to create ELI metadata no-
tices by hand. The tool generates basic HTML notices pages with 
the  proper  ELI  RDFa  metadata  embedded  inside.  See  the  corre-
sponding section below.

See also:

   What is the ELI annotation tool?

4.4.3.   ELI is RDF. Do I need an RDF database (triplestore) to 

publish ELI metadata in RDF?

No. Adding RDFa markup to encode structured metadata in web 
pages does not require an RDF database to be used in the publish-
ing process. It is merely a question of modifying the page-genera-
tion templates to add the new markup.

There  are  other  ways  of  disseminating  RDF  data,  such  as  provid-
ing RDF files for download or giving access to the data using the 
SPARQL query language, that may require use of an RDF database. 
A detailed analysis of content publication and data dissemination 
scenarios is required to determine whether an RDF database can 
bring value to your publishing system.

4.4.4.   Should I use a redirect or a forward to implement ELI 

URI access?

If possible, it is better to use URL forwarding so that the ELI remains 
visible in the address bar of the user. Using a redirect from the ELI 
URI to the original URL does not keep the ELI visible.

However, using URL forwarding may be more complicated with re-
spect to relative links. Since ELI URIs have a hierarchical structure of 
components that will certainly be different from the original portal 
URLs, relative links included in the HTML page code can be broken.

4.4.5.   Besides RDFa are there other means of disseminating 

ELI metadata?

Yes.  JSON-LD  (22)  is  a  different  syntax  to  encode  structured  data 
within  web  pages,  in  the  form  of  JSON  data  structures  inside 
‘<script>’ tags. This is the newest way of mixing structured (RDF) 
data and content. As such it may be more ‘developer friendly’, but 
might lack support in the various tools for the moment.

(22)  JSON-LD: http://www.w3.org/TR/json-ld/

41

Beyond including structured data directly in the web page content 
in RDFa or JSON-LD, it is also possible to:

  bundle the ELI metadata for the entire legislation in one or a few 

RDF files, and provide these files for download;

  store  the  ELI  metadata  for  the  entire  legislation  in  an  RDF  da-
tabase,  and  provide  public  access  to  this  database  using  the
SPARQL query language (23) so developers can query the meta-
data directly;

  use  the  content  negotiation  mechanism  to  return  either  an
HTML  page  or  an  RDF  document  for  the  same  URI,  based  on
client preferences expressed in HTTP headers.

Note that these ways of disseminating ELI metadata are not offi-
cially recommended by the ELI Taskforce. RDFa remains the recom-
mended way of disseminating ELI metadata.

See also:

  What is content negotiation?

  What is schema.org and what is the legal.schema.org

extension? How can I use them? What are the benefits?

4.4.6.  What is content negotiation?
The content negotiation mechanism (24) is a way for a single URI to 
return different ‘representations’ of that URI (i.e. different result pages) 
depending on client preferences. These preferences could typically 
be the client’s preferred language (e.g. ‘I prefer English, but I can just 
about  get  by  in  French’),  or  the  client’s  preferred  file  format  (e.g. ‘I 
would like HTML, but if you don’t have then it is OK if you have RDF/
XML’).

The client expresses its preferences using HTTP headers in the request 
it sends to the server. The request typically looks like the following:

GET  /eli/dir/2015/1234 HTTP/1.1
Accept: application/xml; q=0.8, text/html;q=0.9,*/*
Accept-Language: en,fr;q=0.8,fr-FR;q=0.5,en-US;q=0.3 
In practice, for ELI, this means a single ELI URI could return either an 
HTML page marked up with RDFa if the client accepts HTML (which 
is the case for all web browsers) or a technical RDF file containing 

(23)  SPARQL query language: http://www.w3.org/TR/sparql11-query/
(24) 

 Content Negociation mechanism: http://www.w3.org/TR/ld-glossary/#content-
negotiation

42

ELI technical guideonly the ELI metadata expressed in RDF if the client has expressed 
a preference for RDF files.

Implementing  content  negotiation  is  not  required  in  ELI;  it  is  an 
alternative way of disseminating ELI metadata.

4.4.7.   Where can I search for tools and technologies on 

semantic web in general?

A collection of general semantic web development tools is main-
tained by the World Wide Web Consortium as part of its semantic 
web activity (25).

Professional developers from Cambridge have set up Linked Data 
Tools (26) to provide developers with tools and know-how to use 
the semantic web, with a set of tutorials for various aspects of se-
mantic web development.

Validation of RDF data can be done using the RDF validator hosted 
by the World Wide Web Consortium (27). The data can be submitted 
either by providing a URI that points to RDF data or by pasting RDF 
data into a text box.

Originally  initiated  by  Google  under  the  name  of  Google  Refine, 
OpenRefine (28) is an open-source tool used to clean, transform and 
link  data.  An  extension  to  create  RDF,  RDF  Refine  is  available  for 
download.

4.4.8.   What is schema.org and what is the legal.schema.
org extension? How can I use them? What are the 
benefits?

Schema.org (29) is a vocabulary (a ‘lightweight ontology’) used to 
publish structured metadata in web pages that will be understood 
by search engines. It is the vocabulary to use if you want to ensure 
that major web search engines will ‘understand’ the data inside a 
web  page.  Structured  data  expressed  using  the  schema.org  vo-
cabulary  is  typically  what  enables  search  engines  to  display ‘rich 
snippets’ in a search result page, for example to give the rating of a 
blog post or the cooking time of a recipe.

Schema.org is a collaborative effort: anyone can propose enhance-
ments to the vocabulary.

(25)  Semantic web development tools: http://www.w3.org/2001/sw/wiki/Tools
(26)  Linked Data Tools: http://www.linkeddatatools.com/
(27)  RDF validator: http://www.w3.org/RDF/Validator/
(28)  OpenRefine: http://openrefine.org/ 
(29)  Schema.org: http://schema.org

43

Previously,  nothing  existed  in  the  schema.org  vocabulary  to  de-
scribe a legal act. In accordance with its objective of making leg-
islation more visible on the web as a whole, the ELI Taskforce de-
cided to propose an extension to the schema.org vocabulary (30) to 
describe a legislation document. The ELI ontology was compared 
to the schema.org vocabulary, and properties that did not exist in 
schema.org were proposed in the extension. The extension is now 
publicly available (31).

If  you  want  to  make  your  legislation  metadata  understandable  by 
both ELI partners and major web engines you need to embed struc-
tured metadata expressed both in the ELI ontology in RDFa and in 
schema.org (using the extension), in either RDFa, JSON-LD or Micro-
data. See the markup examples included in the extension.

Note that you will not see any immediate benefit in search-engine 
rankings, or in the display of the search engine results on your web 
pages. How the web search engines use the schema.org metadata 
remains opaque, and they are free to read/interpret/use only a small 
percentage of what is described using the schema.org vocabulary.

See also:

  What is the ELI annotation tool?

4.5.  ELI tools

4.5.1.  What is the ELI validator?
The Eli validator (32) is an online service that can be used to parse 
the RDFa markup of an HTML web page (either available online or 
by entering its HTML code) and validate its conformance against 
the ELI ontology.

The validator produces a report that allows the validity of an RDFa 
markup to be assessed against the ELI ontology. Validation rules are 
broken down into the following three levels.

  ‘Info’: informative messages give hints to improve the quality of 
the ELI metadata, while not being hard constraints from the ELI 
ontology, strictly speaking. Typically, eli:is_about can use Euro-
voc URIs as values, but this is indicative only.

  ‘Warning’:  warning  messages  are  constraints  derived  from  the 
ELI ontology that would not prevent a data consumer from ‘un-

(30) 

 Proposed Legislation extension to schema.org: https://github.com/schemaorg/
schemaorg/issues/1156

(31)  Public Legislation extension: http://pending.schema.org/Legislation 
(32)  ELI validator: http://eur-lex.europa.eu/eli-register/resources.html

44

ELI technical guidederstanding’ the data. Typically, constraints on the datatypes of 
some values are encoded as warnings.

  ‘Violations’: violations are constraints derived from the ELI ontol-
ogy that would prevent a data consumer from correctly ‘under-
standing’ the data. Typically, domain and ranges constraints are 
violations.

See the ELI validator online documentation for more details.

4.5.2.  What is the ELI annotation tool?
The ELI annotation tool (33) is an application allowing organisations 
in  charge  of  the  official  publication  of  legal  resources  to  identify 
and describe those legal resources conforming to the ELI standard 
and to make this description available on the web using structured 
data embedded in HTML pages.

The  application  answers  the  needs  of  official  journals  and  other 
organisations  publishing  legal  resources  that  have  no,  or  scarce, 
metadata management for their contents.

ELI annotation tool has the following two main functional components.

  Administration of the data model and controlled vocabularies.

  Editing and publishing of legal resources metadata.

The administration of the data model and controlled vocabularies 
is mainly used to customise the application for local needs, both by 
customising the ELI URI naming convention — the ELI model — 
and by managing some local controlled vocabularies.

The editing and publishing component helps the user to describe 
a legal resource with ELI metadata and to publish an HTML page 
with metadata for human users, RDFa metadata for harvesting by 
third parties and JSON-LD metadata that conform to schema.org 
to help referencing of the legal resources by web search engines 
and local search engines.

See the application documentation for more details.

See also:

  What is schema.org and what is the legal.schema.org 

extension? How can I use them? What are the benefits?

(33)  ELI annotation tool: http://eur-lex.europa.eu/eli-register/resources.html

45

4.5.3.  What is ELI/XML?
ELI/XML (34) is an XSD schema for expressing ELI metadata in XML 
documents. It is not part of the ‘official’ ELI specification, like the ELI 
ontology, and is provided only as a ‘helper’ for generating and pub-
lishing ELI metadata that conform to the ontology. It helps integrate 
ELI metadata into XML-based production systems, and is not intend-
ed for publishing ELI metadata on the web.

The ELI/XML format hides the (relative) complexity of the RDF funda-
mentals. The following points should be noted.

  In ELI/XML the order of the ELI metadata in the XML is mandatory: 
they must be listed in alphabetical order (e.g. from eli:amended_
by to eli:version_date);

  XML elements corresponding to LegalResource, LegalExpression 
and Format are embedded in an XML hierarchy, thus making it 
unnecessary to state FRBR structure metadata (e.g. eli:realized_by, 
eli:embodied_in, etc.).

  Controlled values are provided for eli:in_force and eli:legal_value.

(34)  ELI/XML schema: http://eur-lex.europa.eu/eli-register/resources.html 

46

ELI technical guideBelow is a short example of an ELI/XML document.

<eli:LegalResource eli:URI=‘http://data.europa.eu/eli/dir/1980/181/oj’

     eli:in_force=‘InForce-inForce’

     xsi:schemaLocation=‘http://data.europa.eu/eli/ontology# elixml-v1.xsd’

     xmlns:xsi=‘http://www.w3.org/2001/XMLSchema-instance’

     xmlns:eli=‘http://data.europa.eu/eli/ontology#’>

 <eli:based_on eli:URI=‘http://publications.europa.eu/resource/authority/
treaty/TEEC_1957’/>

 <eli:date_document>1979-12-20</eli:date_document>

 <eli:date_publication>1980-02-15</eli:date_publication>

 <eli:first_date_entry_in_force>1979-12-21</eli:first_date_entry_in_force>

 <eli:id_local>31980L0181</eli:id_local>

 <eli:is_about eli:URI=‘http://eurovoc.europa.eu/1896’/>

 <eli:is_about eli:URI=‘http://eurovoc.europa.eu/2159’/>

 <eli:is_about eli:URI=‘http://eurovoc.europa.eu/2897’/>

 <eli:passed_by eli:URI=‘http://publications.europa.eu/resource/authority/
corporate-body/CONSIL’/>

 <eli:type_document eli:URI=‘http://publications.europa.eu/ 
resource/authority/resource-type/DIR’/>

 <eli:LegalExpression eli:URI=‘http://data.europa.eu/eli/dir/1980/181/
oj/ell’

      eli:in_force=‘InForce-inForce’

      eli:language=‘ELL’>

 <eli:title>Οδηγία 80/181/ΕΟΚ του Συμβουλίου της 20ής Δεκεμβρίου 1979 
περί προσεγγίσεως των νομοθεσιών των κρατών μελών των αναφερομένων στις 
μονάδες μετρήσεως και καταργήσεως της οδηγίας 71/354/ΕΟΚ</eli:title>

 <eli:Format eli:URI=‘http://data.europa.eu/eli/dir/1980/181/oj/ell/html’

    eli:format=‘text/html’>

  <eli:is_exemplified_by eli:URI=‘http://publications.europa.eu/resource/
celex/31980L0181.ELL.html.31980L0181el.html’/>

  <eli:publisher>http://publications.europa.eu/resource/authority/corporate-
body/PUBL</eli:publisher>

 </eli:Format>

 </eli:LegalExpression>

</eli:LegalResource>

See the ELI/XML XSD schema for more details.

47

O
A
-
0
4
-
1
8
-
2
3
2
-
E
N
N

-

ISBN 978-92-78-41757-4