ELI, the European legislation identifier : good practices and guidelines.
Date: 2018-11-27
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, exchange of information, information centre, legal data processing, legislation, on line data service, provision of services, standard, user guide

      — The European 
Legislation Identifier
Good practices and guidelines
Author: ELI Taskforce

SECOND EDITION

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

These methodology guidelines have been drafted with the support of ISA². ISA² is a EUR 131 million 
programme of the European Commission that develops digital solutions that enable interoperable cross-
border and cross-sector public services for the benefit of public administrations, businesses and citizens 
across the EU. ISA² supports a large range of actions and solutions. The ISA² solutions can be used free of 
charge and are open source when related to IT.

ISA² — IT solutions for less bureaucracy 
You click, we link.
Follow us on Twitter.

Luxembourg: Publications Office of the European Union, 2018

Print

PDF

ISBN 978-92-78-41433-7

doi:10.2830/737565

OA-04-17-130-EN-C

ISBN 978-92-78-41429-0

doi:10.2830/44907

OA-04-17-130-EN-N

ePUB

ISBN 978-92-78-41432-0

doi:10.2830/535911

OA-04-17-130-EN-E

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

Printed in Luxembourg

Printed on elemental chlorine-free bleached paper (ecf)

 — The European 
Legislation Identifier
Good practices and guidelines
Author: ELI Taskforce

SECOND EDITION

Contents

Foreword...................................................................................................................................... 5
Introduction ............................................................................................................................... 6
Purpose  ........................................................................................................................... 6
Structure .......................................................................................................................... 6
Target audience ........................................................................................................... 6
Scope ................................................................................................................................. 7

PART 1: An introduction  
to the European Legislation Identifier ....................................... 9
Background ..............................................................................................................................10
Origins ......................................................................................................................................... 11
Objectives ................................................................................................................................. 11
Governance ..............................................................................................................................14
ELI benefits ...............................................................................................................................15

PART 2: ELI implementation methodology ............................. 19
Overview of the ELI implementation methodology ......................................20
Organisation and policy ...................................................................................................22
STEP 1: Identify the business case ..................................................................22
STEP 2: Estimate resources ..................................................................................25
STEP 3: Set up a governance structure .......................................................30
STEP 4: Set up an ELI implementation project .......................................33
STEP 5: Formulate statements about URI  
and metadata services provided ....................................................................36

Pillar 1: How to put in place legislation identifiers  

based on ELI HTTP URIs ........................................................................................38
STEP 1: Capture requirements for HTTP URIs ..........................................39
STEP 2: Design the URI template.....................................................................42
STEP 3: Configure web server for ELI URI resolution ...........................52
Pillar 2: How to design an ELI metadata schema ..............................................57
STEP 1: Capture requirements for metadata ............................................58
STEP 2: Design and publish controlled  
vocabularies and metadata schemas ..........................................................61
STEP 3: Annotate legal resources (automatically or manually) .....65
Pillar 3: How to render ELI metadata machine-reusable ..............................68
STEP 1: Add RDFa tags to web pages to facilitate parsing and 
extraction ......................................................................................................................69

3

PART 3: Beyond the ELI pillars ................................................... 73
Align metadata values with other vocabularies (Eurovoc) .........................74
Use other metadata dissemination channels .....................................................74
Use ELI as an opportunity to improve publishing workflows ...................75
Make your legislation more visible for web search engines ......................76

ANNEXES ..................................................................................... 77
ANNEX I: Glossary .................................................................................................................78
ANNEX II: ELI ontology .......................................................................................................84
ANNEX III: Self-assessment check list ........................................................................85

4

ELI — Good practices and guidelinesForeword

The present guide was created by the ELI Taskforce and is aimed at de-
velopers or project managers who want to implement ELI into 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 taskforce 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.

5

Introduction

Purpose 
The purpose of this document is to provide publishers of legal infor-
mation with a step-by-step methodology on how to implement the 
European Legislation Identifier (ELI). 

The current document is an updated edition of the ELI methodology 
guide that includes lessons learned from national ELI implementations 
and feedback received during hands-on workshops organised by the 
ELI Taskforce.

Structure
This document consists of three parts.

  Part 1 provides an overview of ELI together with the main benefits 

derived from the implementation of ELI.

  Part 2 provides a set of steps and good practices that publishers of 
legal information can apply in order to implement ELI. This part also 
provides an estimate of the resources needed to implement each 
of the three pillars of ELI.

  Part 3 provides information on how ELI implementers can further 
enhance  discoverability  of  legal  information  beyond  the  imple-
mentation of ELI.

Target audience
The target audience of this document is as follows.

  Decision-makers.  Individuals  who  make  decisions  concerning 
the  implementation  of  ELI  in  their  countries.  This  group  typically 
includes countries that have not yet implemented ELI but that are 
interested in learning more about the potential associated benefits 
and the experiences of those who have already implemented ELI.

  Technology experts. Individuals who want to learn how to imple-

ment ELI.

  ELI  implementers.  Those  that  who  already  implemented  ELI  in 
whole or in part and that are interested in the progress of other ELI 
implementers.

  Legal  professionals.  Individuals  with  a  legal  background  that 
could be interested in learning more about URI templates in order 
to know how to better search for legal information.

6

ELI — Good practices and guidelinesFigure 1 —  Countries that have implemented ELI

Scope
Originally,  the  guidelines  in  this  document  were  based  on  the  find-
ings gathered in a study carried out in the first quarter of 2015 with 11 
Member States/European Free Trade Association (EFTA) countries (i.e. 
France,  Germany,  Ireland,  Italy,  Luxembourg,  Malta,  the  Netherlands, 
Norway,  Slovakia,  Switzerland  and  the  United  Kingdom),  along  with 
the Publications Office of the European Union (OP).

In the course of 2015, 2016 and 2017, ELI workshops were delivered to Den-
mark, France, Ireland, Italy, Albania, Luxembourg, Malta, Finland, Austria, 
Serbia, Latvia, Spain, Portugal, Hungary and Croatia. The objective of the 
workshops was to provide technical consultancy to support the imple-
mentation of ELI in existing publishing systems.

Thanks to the feedback received in the context of these workshops, 
the methodology guidelines were enriched and refined. 

7

PART 1:

An introduction 
to the European Legislation 
Identifier

9

Background

The conclusions of the Council of the European Union inviting the intro-
duction of ELI explain that: ‘… a European area of freedom, security and 
justice  in  which  judicial  cooperation  can  take  place  requires  not  only 
knowledge of European law, but also mutual knowledge of the legal sys-
tems of other Member States, including national legislation’ (1).

The exchange of legal information is key in this regard, but despite the 
increased availability of documents in electronic format, the Council con-
clusions report that the exchange of legal information originating from 
regional and national authorities at the European level is far from opti-
mal, due to existing differences between national legal systems, includ-
ing the technical systems used to store and display legislation through 
their websites.

To overcome such obstacles and improve interoperability between legal 
systems,  the  ELI  Council  conclusions  invite  the  Member  States  to  use 
identification of legislation and metadata properties describing each legal 
resource, and render the ELI metadata machine-reusable to reference na-
tional legislation in official journals and legal gazettes, so as to enable ef-
fective, user-friendly and faster search and exchange of legal information.

This is in line with the European Union’s commitment to open up leg-
islation as part of the implementation of the G8 Open Data Charter (2), 
which aims to promote, among other things, transparency and govern-
ment accountability. It also meets the recommendations included in the 
European interoperability framework (3) on how to improve interoperabil-
ity within the EU and across Member State borders and sectors, and also 
the directive on better regulation (4) on access to, and interconnection of, 
electronic communications networks and associated facilities. 

By making legislation available on the web in a structured way, it will be 
easier to find, share and reuse legislation, as prescribed by the public sec-
tor information directive (5). Allowing the smart reuse of legal data and 
creating opportunities for the development of new services, ELI contrib-
utes to the development of the digital single market (6). Finally, ELI aims to 
promote the access and exchange of legal information within and across 

(1) OJ C 441, 22.12.2017, pp. 8-12 (http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=C
ELEX:52017XG1222(02)).
(2) EU implementation of the G8 Open Data Charter (https://ec.europa.eu/ 
digital-agenda/en/news/eu-implementation-g8-open-data-charter).
(3) COM (2010) 744 final, Annex 2, Brussels, 16.12.2010.
(4) Directive 2009/140/EC (http://eur-lex.europa.eu/legal-content/en/
ALL/?uri=CELEX:32009L0140).
(5) Directive 2003/98/EC (http://eur-lex.europa.eu/legal-content/en/
TXT/?uri=CELEX:32003L0098) and amending Directive 2013/37/EU (http://eur-lex.
europa.eu/legal-content/EN/TXT/?uri=celex:32013L0037).
(6) https://ec.europa.eu/priorities/digital-single-market_en 

10

ELI — Good practices and guidelinesborders, thereby contributing to the development of the common area 
of freedom, security and justice.

The ELI initiative has been supported since 2014 by the European Com-
mission’s ‘Interoperability solutions for European public administrations’ 
(ISA) programme. Since 1 January 2016 work on ELI has been pursued 
with the support of the ISA2 programme (1) as action 2016.08 (2).

Origins

First established in the context of the European Forum of Official Gaz- 
ettes (3), ELI has been further supported by the subgroup mandated by 
the Council of the European Union in the framework of the Working 
Party on E-law (4).

ELI stems from the acknowledgment that the World Wide Web defines 
a new paradigm for legal information access, sharing and enrichment.

In this context, consumers and publishers of legal information are faced 
with opportunities and challenges. On the one hand, there are new 
opportunities  to  access  legal  information  in  a  more  interconnected 
and interoperable way across legal information systems; on the other 
hand, there is a need to maintain the flexibility of each national legal 
system. Keeping this in mind, ELI is based on a progressive approach 
entailing the implementation of the following elements:

  identification of legislation via HTTP URIs;

  description of legal resources through metadata;

  rendering the ELI metadata machine-reusable through the serialisa-

tion of the metadata in compliance with the ELI ontology.

These three elements are commonly referred to as the three pillars of ELI.

Objectives

The purpose of ELI is to facilitate the access, sharing and interconnec-
tion  of  legal  information  published  through  national,  European  and 
global  legal  information  systems.  ELI  aims  primarily  to  facilitate  the 
search,  exchange  and  interconnection  of  legal  information  through 
national and European IT systems.

(1) http://ec.europa.eu/isa/isa2/index_en.htm 
(2) ISA2 work programme, 2018, p. 407 (https://ec.europa.eu/isa2/sites/isa/files/docs/
pages/isa2_wp_2018_detailed_descriptions_part_1.pdf). 
(3) https://publications.europa.eu/en/web/forum_official_gazettes
(4) http://www.consilium.europa.eu/en/council-eu/preparatory-bodies/working-party-e-law

11

PART 1: An introduction to the European Legislation IdentifierThe European Legislation Identifier is used to:

1.  identify  legislation  with  a  unique  identifier  that  is  recognisable, 
readable and understandable by both humans and computers, and 
is compatible with existing technological standards;

2.  describe legislation with a set of machine-readable metadata elem- 

ents in compliance with a recommended ontology.

According to the Council of the European Union conclusions:

‘ELI  shall  guarantee  cost-effective  public  access  to  reliable  and  up-to-
date legislation and is subject to voluntary and gradual introduction. To 
this end:

a)  ELI creates a unique identifier for the legislation, which is readable by 
both humans and computers, and which is compatible with existing 
technological standards (“ELI pillar 1”);

b)  ELI  proposes  a  set  of  metadata  elements  to  describe  legislation  in 

compliance with a reference ontology (“ELI pillar 2”);

c)  ELI permits a greater and faster exchange of data: when this metadata 
is embedded in the respective webpages of the Official Journals and 
Legal  Gazettes  or  legal  information  systems,  information  can  be  ex-
changed automatically and efficiently, thanks to the benefits from the 
emerging architecture of the semantic web, which enables information 
to be directly processed by computers and humans alike (“ELI pillar 3”).

ELI gives the Member States and the European Union a flexible, self-
documenting,  consistent  and  unique  way  to  reference  legislation 
across different legal systems. ELI URIs are a stable means of uniquely 
identifying any legislative act throughout the European Union, while 
taking into account the specificities of national legal systems (1).

ELI  takes  into  account  not  only  the  complexity  and  specificity  of 
regional, national and European legislative systems, but also changes 
in legal resources (e.g. consolidations, repealed acts etc.). It is designed 
to work seamlessly on top of existing systems using structured data 
and  can  be  taken  forward  by  any  national  legislation  publisher  at 
European level and beyond at their own pace.

Apart from Member States, candidate countries, Lugano States (2) and 
others are encouraged to use the ELI-system.’

(1) The European Case Law Identifier (ECLI), applicable on a voluntary basis, provides 
a European system for the identification of case-law. ELI identifies legislative texts 
which have different and more complex characteristics, and the two systems are 
complementary. The Council requested the introduction of the European Case Law 
Identifier and a minimum set of uniform metadata for case law by way of conclusions 
(OJ C 127, 29.4.2011, p. 1). 
(2) Iceland, Norway and Switzerland. 

12

ELI — Good practices and guidelinesWhile legal information has been available online via national legal in-
formation systems for a long time, ELI enables the putting in place of 
a  genuine  network  of  legal  information,  available  as  open  data  and 
reusable by all.

To achieve these objectives ELI relies on the infrastructure of the World 
Wide Web and the technologies of the semantic web. ELI is based on 
an approach that is characterised by the progressive adoption by the 
publishers of legal information of the following elements.

1.  Pillar 1 on the identification of legislation: URI templates at the 
European, national and regional levels based on a defined set of com-
ponents.

2.   Pillar 2 on metadata properties describing each legal resource: 
definition of a set of metadata and its expression in a formal ontology. 

3.   Pillar 3 to render the ELI metadata machine-reusable: integration 
of metadata into the legislative websites. In the annex to the Council 
conclusions it is suggested that the ELI metadata elements may be 
serialised in compliance with the World Wide Web Consortium (W3C) 
recommendation ‘RDFa in XHTML: syntax and processing’.

The ELI Council conclusions do not specify as a technical requirement 
that the order of the pillars should be followed in order to implement 
ELI. However, the most common approach is to progressively imple-
ment ELI in line with the numbering of pillars.

ELI is based on the well-established model of ‘Functional requirements 
for bibliographic records’ (FRBR). FRBR distinguishes between the con-
cepts of ‘work’ (intellectual or artistic creation), ‘expression’ (intellectual 
or  artistic  realisation  of  a  work)  and  ‘manifestation’  (materialisation  of 
one of the expressions of a work). Each time a ‘work’ is realised it takes 
the form of an ‘expression’. The physical embodiment of an expression is 
a ‘manifestation’. Figure 2 below illustrates how these concepts map to 
the ELI Council conclusions (1) as published in EUR-Lex. More specifically, 
the following can be stated.

  LegalResource is the conceptual entity that represents the intel-
lectual  content  of  the  ELI  Council  conclusions,  which  is  what  the 
various  language  versions  share.  The  intellectual  content  of  the 
Council  conclusions  is  realised  by  the  text,  which  is  expressed  in 
various language versions.

  LegalExpressions  are  the  language  versions  that  are  presented 
horizontally and express the intellectual content in actual text. The 
language versions are embodied by physical files.

(1) OJ C 325, 26.10.2012.

13

PART 1: An introduction to the European Legislation Identifier  Formats are the physical files presented vertically under each lan-

guage.

LegalResource

LegalExpressions

Formats

Figure 2 — Screenshot from the EUR-Lex website depicting the three conceptual  
entities of the ELI model

Governance

At the meeting of the Working Party on E-law on 20 December 2012, 
the chair of the working party proposed that an ELI Taskforce should 
be set up to further study and define the development of a unique 
identifier for national and EU legislation.

The ELI Taskforce was initially composed of France, Luxembourg (chair), 
the United Kingdom and the Publications Office of the European Union; 
Denmark,  Finland,  Ireland,  Italy,  Norway  and  Portugal  joined  the  task-
force  subsequently.  In  order  to  help  Member  States,  candidate  coun-
tries, EFTA countries and others to adopt ELI, the taskforce aims to share 
knowledge/expertise  without  imposing  a  strict  schema  on  how  ELI 
should be implemented and by taking into account national specifi-
cities. For this purpose a change-and-release management process is in 
place, and users can contact the Publications Office for any information 
they would like to receive and to provide feedback and comments on 
ELI  (1). 

In 2017 the Council of the European Union further expressed its sup-
port to the ELI initiative by creating an expert group exclusively dedi-
cated to driving forward the European Legislation Identifier. 

ELI is an action funded under the ‘Interoperability solutions for public 
administrations, businesses and citizens’ programme (ISA2). The Pub-
lications  Office  ensures  the  compliance  of  the  activities  conducted 

(1) Contact: OP-ELI-MAILBOX@publications.europa.eu 

14

ELI — Good practices and guidelineswith the objectives of the ISA2 work programme and regularly reports 
to the Commission’s ISA2 coordination structure on the main achieve-
ments (1).

ELI benefits

The implementation of ELI brings a number of benefits for public admin-
istrations and publishers of legal information, as well as citizens at large.

Benefit 1: access to legislation

The large amounts of legislation, along with its diversity, can make ac-
cess to it cumbersome. Thus, it is important that legislation be pub-
lished in a way that allows people to use it easily and readily.

First of all the assignment of persistent identifiers as specified by ELI 
provides  for  a  homogeneous  mechanism  to  identify  legal  informa-
tion on the web, making it easier for users to look for legal information 
within and across legal systems.

The  predictable  nature  of  the  ELI  identifiers,  which  are  designed  in 
such a way as to stay as close as possible to the way legislation is cited, 
allows users to easily compose URIs to refer to published legislation. 
What is more, the design patterns of the ELI-compliant HTTP URIs are 
conceived to assist users looking for legal information when they do 
not have all the necessary elements to identify the specific piece of 
legislation. In this case, the user will be directed towards the right in-
formation through a partial input, based on the available information.

ELI  also  facilitates  access  to  legal  information  by  citizens,  along  with 
potential reusers of legal information. It allows legislation to be refer-
enced at different levels of granularity, thus enabling different uses of 
legal  information,  such  as  social  media  discussions  about  particular 
elements of legislation, references to legislation in research papers or 
developments of applications by businesses.

Furthermore, a common structure for metadata to describe legislation 
across national and European legislation services, as proposed by ELI, 
makes searching across the distributed collections easier. It also creates 
opportunities for aggregation services to harvest metadata from vari-
ous sources to build indexes across collections.

Additionally,  ELI  promotes  the  access  and  reuse  of  legal  information 
across Europe through multilingualism that is facilitated by the use of 
its ontology, multilingual controlled vocabularies and the alignment of 
controlled vocabularies with EU vocabularies.

(1) https://ec.europa.eu/isa2/actions/facilitating-exchange-legislation-data-europe_en 

15

PART 1: An introduction to the European Legislation IdentifierBenefit 2: development of new services

The ever-evolving social, economic and technological environment in 
which publication services are operating enables smart reuse of data. 
The persistence of identifiers, the common specification of structured 
metadata and the publication format proposed by ELI give businesses 
the  opportunity  to  develop  innovative  and  sustainable  added-value 
services on the basis of the published legal information.

Furthermore, the increased semantic interoperability in the context of 
legal information achieved through the adoption of ELI contributes to 
the development of the digital single market, which will lead to the 
modernisation of traditional industry, and bring estimated significant 
gains  in  terms  of  additional  annual  growth,  along  with  a  substantial 
boost for job creation in Europe.

Benefit 3: cost savings

Failure to link or share legislation within and between different public 
administrations  results  in  inefficient  public  services  and  high  informa-
tion  collection  costs,  increasing  the  burden  on  public  administrations 
and citizens.

ELI promotes the publication of legislation in a structured and machine-
readable way to promote linking and reuse of legal data. This also leads 
to cost savings for publishers, in terms of improved effectiveness of in-
formation flows and shorter time required to publish legislation.

The ELI approach aims to construct common building blocks for nam-
ing and citing legal information in a flexible way so as to respect each 
country’s  unique  legislative  and  legal  tradition.  This  flexibility  —  to-
gether with the fact that ELI can be implemented in a progressive way 
on top of existing IT solutions and databases, and that it is designed to 
work seamlessly on top of existing systems — makes it a cost-effective 
solution for publishers that want to make legal information available for 
reuse purposes.

Benefit 4: quality and reliability of data

The increased reuse of legislation triggers a growing demand to im-
prove the quality of the published information. The structured pub-
lication  of  legal  information  based  on  the  ELI  specifications  enables 
review and feedback from users, which can help increase the quality 
and reliability of information.

Furthermore,  ELI  allows  better  structuring  of  legal  information  in 
terms of internal links within a text and external links to other docu-
ments that are mentioned within a text (for example laws, decrees or 
EU legislation).

16

ELI — Good practices and guidelinesQuality and reliability of data is key in order to establish more effective, 
simplified  and  user-friendly  services  that  are  crucial  for  fostering  the 
trust of businesses and citizens in digital services.

Benefit 5: transparency

There is an ever-growing demand for openness and transparency in 
modern  societies.  Increased  transparency  is  an  important  objective 
across public administrations, as demonstrated in the context of the 
European Union, where the principles of openness and transparency 
feature in primary EU law.

By  making  legislation  more  accessible,  ELI  contributes  to  making  it 
easier for citizens and watchdog organisations to be better informed 
and  to  monitor  the  work  done  by  governments.  Transparency  guar-
antees greater legitimacy and accountability of the administration in 
a democratic system because citizens have the opportunity to better 
understand the considerations underpinning the law in order to exer-
cise their democratic rights.

Benefit 6: interoperability

ELI is based on the architecture of the semantic web and linked open 
data, enabling greater and faster exchange of data through the auto-
matic and efficient exchange of information. This is achieved through 
semantic interoperability. Semantic interoperability is a means to achieve 
greater efficiencies where there is a clear need and where there is clear 
demand from relevant users.

The ELI approach is based on the idea that in order to generate greater 
efficiencies it is necessary to reach a minimum level of agreement on 
the way legislation is identified and described. The ELI approach thus 
allows legislation to be structured and identified in a sufficiently uniform 
way, and at the same time takes into account the specificities of each 
national legal system by providing a flexible and progressive approach 
to its implementation.

ELI also provides a standard way to publish legislation as machine-read-
able open data, creating opportunities to automatically discover and re-
use published legislation and to ensure legal reference certainty.

By allowing humans and machines to have improved access to legal in-
formation, ELI sets the basis for a web of legal information. Making legal 
information part of the web of data allows users to easily discover legal 
information  across  countries  and  to  reference  legal  information  more 
easily,  as  well  as  to  improve  their  understanding  of  legal  information 
thanks  to  the  interconnections  between  different  sources  of  informa-
tion across domains.

17

PART 1: An introduction to the European Legislation IdentifierPART 2:

ELI implementation 
methodology

19

PART 2: ELI implementation methodologyOverview of the 
ELI implementation 
methodology

This section introduces the ELI implementation methodology, provid-
ing a step-by-step approach that publishers of legal information can 
follow to implement one or more ELI pillars. This is accompanied by a 
set of good practices that have been identified based on the experi-
ence of stakeholders that have already implemented one or more of 
the ELI pillars. The ELI implementation methodology consists of two 
parts, as depicted in Figure 3 below.

1.  Organisation  and  policy:  this  part  mainly  addresses  decision-

makers and is composed of five main steps.

2.  Technical implementation: this part addresses a more technical 
audience that is involved with the actual ELI implementation. It is 
divided according to the three ELI pillars, and for each pillar a num-
ber of steps have been outlined.

The  ELI  implementation  methodology  is  generic  enough  to  cover  a 
large number of possible use cases. To be effective, the methodology 
should be tailored and adapted to match the use case of the imple-
menter. Despite the order of pillars and their steps forming a coherent 
flow — i.e. (1) design and implement ELI identifiers for legislation, (2) 
design and implement metadata management and (3) publish legis-
lation enriched with metadata — not all pillars and steps have to be 
implemented at once. Some may decide to limit their implementation 
only  to  using  ELI  identifiers  for  all  their  published  legislation.  Others 
may implement all three pillars at once for a limited part of their pub-
lished legislation, and then gradually for all of it.

20

ELI — Good practices and guidelinesOrganisation and policy

Step 1:
Identify
business
case

Step 2:
Estimate
resources

Step 3:
Establish
governance

Step 4:
Set up ELI
implementation
projects

Step 5:
Formulate 
statements about 
URI and metadata
services 
provided

Technical implementation

Pillar 1

Pillar 2

Pillar 3

Step 1: Capture
requirements
for HTTP URIs

Step 1: Capture
requirements
for metadata

Step 1: Add RDFa tags to 
web pages to facilitate
parsing and extraction

Step 2: Design
the URI template

Step 2: Design and publish 
controlled vocabularies and 
metadata schema

Step 3: Configure
web server for ELI URI
resolution

Step 3: Annotate legal 
resources (automatically 
or manually)

Figure 3 — Overview of the ELI implementation methodology

21

PART 2: ELI implementation methodologyOrganisation and policy

STEP 1: Identify the business case

Publishers of legal information should develop a business case to help 
decision-makers decide whether to implement ELI and the allocation 
of  resources  that  are  necessary  to  implement  it.  The  business  case 
should include the following elements.

  An executive summary that outlines the ELI project and contains 
the key considerations that will be discussed in the business case, 
including the timeline for business case implementation and com-
pletion, along with the projected benefits and costs.

  The scope defining the coverage of ELI implementation from both 
a chronological and a type(s) of collection perspective. With regard 
to the chronological aspect, publishers of legal information need to 
decide whether ELI will be implemented in relation to all legislation 
that has ever existed or to a subpart, such as only newly adopted 
legislation. This decision depends significantly on what legislation is 
available online or is planned to be made available online.

With  regard  to  the  type(s)  of  collection,  publishers  of  legal  infor-
mation  may  decide  that  ELI  will  be  applied  only  to  legislation  or 
to a broader range of legal information. For example, on the one 
hand, France decided to include summaries of legislation within the 
scope of ELI because this collection is regularly consulted by users 
to get a better understanding of legislation; on the other hand, the 
Publications Office decided to limit the scope of ELI implementa-
tion to the EU legislation published in the Official Journal L series.

  A  problem  statement  highlighting  the  issue  or  goal  that  the 
business case for the implementation of ELI aims to solve. The ‘ELI 
benefits’ presented in Part 1 of this guide can provide guidance on 
common issues and objectives that ELI aims to address. An example 
of a concrete problem statement entails the need to establish clear 
links between an EU directive and related national implementing 
measures. The issue relates to the fact that it is not always easy to 
establish  which  national  provision  transposes  which  EU  directive, 
and even if the relationship is identified there is a need to ensure 
that such information is kept up to date. In the past, public admin-
istrations used static tables of correspondence that were manually 
maintained. Such an exercise was not only extremely cumbersome, 
it also led to information that was not always accurate and up to 
date.

22

ELI — Good practices and guidelines  A proposed solution that describes the project and options avail-
able to solve the business problem, explaining how the implemen-
tation  of  ELI  addresses  and  resolves  the  problem  statement.  For 
example, ELI provides a useful means to improve the links between 
EU directives and national implementing measures as it promotes 
semantic interoperability between legal information systems across 
countries.

  An estimate of resources that indicates what is needed to imple-
ment  ELI,  including  the  allocation  of  resources,  a  timeline  for  im-
plementation and the resources needed. For guidance on how to 
define the resources necessary for ELI implementation the reader is 
invited to move to the next step, ‘Estimate resources’.

23

PART 2: ELI implementation methodologyGood practice 1:
Building on the knowledge, experience and 
tools of others (support by the ELI Taskforce)

Problem statement
When  approaching  ELI  implementation,  publishers  of  legal  informa-
tion  may  be  inclined  to  work  in  isolation,  without  looking  for  exist-
ing experience and know-how. This leads to inefficiencies as time and 
money  may  be  spent  investigating  aspects  that  are  already  known 
inside other organisations that have already implemented ELI.

Recommendation
Publishers of legal information can learn from the experience of those 
who have already implemented ELI and can ask for help and assistance 
from the ELI Taskforce. The references of ELI coordinators and ELI Task-
force members is made available on the EUR-Lex website (1). EUR-Lex 
also provides a list of tools that can help in the implementation of ELI (2). 
Additionally, the Publications Office’s Metadata Registry provides refer-
ences to the ELI URI template components and ELI ontology, as well as 
to the serialisation of ELI metadata elements (3).

Building on shared knowledge allows publishers of legal information to 
anticipate  risks  and  avoid  mistakes  made  by  others  in  the  past,  saving 
time and resources. Learning from the findings of legal analysis already 
carried out by other publishers, and from technical implementation, helps 
avoid reinventing the wheel and optimises the use of resources.

For instance, some countries greatly benefited from the support provided 
by the ELI Taskforce, in terms of both technical support and more general 
background  knowledge,  in  order  to  acquire  a  better  understanding  of 
how ELI works and the benefits derived from its implementation.

BENEFITS  

Quality and reliability
Avoids common pitfalls

Development of new services
Optimisation of resources and better focus on aspects 
to promote the development of added-value services

DOs

•  Learn from the 
experience of those 
who have already 
implemented any  
of the pillars of ELI

•  Share lessons learned 
while implementing ELI 
and provide feedback to 
the ELI Taskforce 

DON’Ts

•  Work in isolation

•  Reinvent the wheel

24

(1) http://eur-lex.europa.eu/eli-register/implementation.html 
(2) http://eur-lex.europa.eu/ 
(3) http://publications.europa.eu/mdr/eli/index.html 

ELI — Good practices and guidelinesSTEP 2: Estimate resources

When estimating the resources to implement ELI, publishers of legal 
information should take into account the fact that the effort required 
for ELI implementation varies depending on:

  each ELI pillar; and

  the degree of digitalisation of the existing publication process for 

legal information.

To help publishers carry out such an analysis, this document provides 
the following overview of the resources that should be allocated de-
pending on whether:

1.  a publisher of legal information needs to start implementation from 

the very beginning (Scenario 1); or

2.   a publisher of legal information is already well advanced  (Scenario 2). 

For each scenario, it is possible to identify:

  the resources estimate associated with each of the implementation 
steps,  which  are  further  explained  in  the  remainder  of  this  docu-
ment; and

  relevant professional profiles. 

The following two key professional profiles are considered relevant.

•  Knowledge  information  officer:  should  have  a  good  under-
standing of information technologies in general and the semantic 
web in particular, and expert knowledge of legal information. Ex-
perience in working with multiple metadata standards, frameworks 
and controlled vocabularies, familiarity with XML and XML schema 
languages together with knowledge of XPath, XSLT or XQuery are 
recommended.  Furthermore,  experience  in  creating  and  imple-
menting  metadata  schemas  and  taxonomies  and  controlled  vo-
cabularies, together with gathering user requirements, is a plus.

•  Semantic web programmer/developer: should be proficient 
in software development in general, and have basic experience 
with semantic web technologies. Skills necessary for a web pro-
grammer/developer are experience in transforming data format 
using XSLT and adding RDFa or JSON metadata into HTML pages.

25

PART 2: ELI implementation methodologyFigures 4, 5 and 6 below provide an overview of the estimated resources 
for the implementation of each ELI pillar. Implementation efforts are 
expressed in full-time equivalent (FTE), which is a unit to indicate the 
workload of an employed person.

Activity

e
g
n
a
R

Person days

Profile

Scenario (1) Legislation is published online without a consistent URL or numbering scheme

Step 1: Capture requirements
for HTTP URIs

Step 2: Design the URI template 

Step 3: Configure web server
for ELI URI resolution

–
5
n
m

i

0
1
x
a
m

–
3
n
m

i

0
2
x
a
m

–
2
n
m

i

0
1
x
a
m

person
days

0-10

11-20

21-30

31-40

Knowledge information officer

Knowledge information officer

Semantic web programmer/developer

Scenario (2) Legislation is published online with a consistent (non-ELI) URL scheme

Step 1: Capture requirements
for HTTP URIs

Step 2: Design the URI template 

Step 3: Configure web server
for ELI URI resolution

Legend:

Best-case scenario

Average scenario

Worst-case scenario

–
5
n
m

i

0
1
x
a
m

–
3
n
m

i

0
2
x
a
m

–
2
n
m

i

0
1
x
a
m

person
days

0-10

11-20

21-30

31-40

Knowledge information officer

Knowledge information officer

Semantic web programmer/developer

Figure 4 — Resources allocation Pillar 1

26

ELI — Good practices and guidelines 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Activity

e
g
n
a
R

Scenario (1) No metadata is available

Person days

Profile

Step 1: Capture requirements
for metadata 

Step 2: Design and publish
metadata schema

Step 3: Develop metadata
publishing routines

Step 4: Deploy legislation
metadata

–
5
n
m

i

5
1
x
a
m

–
5
1
n
m

i

0
3
x
a
m

–
0
1
n
m

i

0
2
x
a
m

–
0
2
n
m

i

0
4
x
a
m

person
days

0-10

11-20

21-30

31-40

Scenario (2) Required metadata is available, but not aligned to ELI

Step 2: Design metadata schema

Step 4: Deploy legislation metadata

Legend:

Best-case scenario

Average scenario

Worst-case scenario

–
2
n
m

i

5
x
a
m

–
3
n
m

i

0
1
x
a
m

person
days

Knowledge information officer

Semantic web programmer/developer

Knowledge information officer

Semantic web programmer/developer

Knowledge information officer

Semantic web programmer/developer

0-10

11-20

21-30

31-40

Figure 5 — Resources allocation Pillar 2

27

PART 2: ELI implementation methodology 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Activity

e
g
n
a
R

Person days

Profile

Scenario (1) Legislation is at least held electronically, but metadata is not available on the website

Step 1: Add microdata or RDFa
tags in web pages to facilitate
parsing and extraction

Step 2: Provide an application
programming interface (API)

–
3
n
m

i

5
1
x
a
m

–
5
n
m

i

0
2
x
a
m

person
days

0-10

11-20

21-30

31-40

Semantic web programmer/developer

Semantic web programmer/developer

Scenario (2) Legislation is at least held electronically; metadata is available, but not ELI aligned

Step 1: Add microdata or RDFa
tags in web pages to facilitate
parsing and extraction

Step 2: Provide an application
programming interface (API)

Legend:

Best-case scenario

Average scenario

Worst-case scenario

–
0
n
m

i

0
2
x
a
m

–
3
n
m

i

0
1
x
a
m

person
days

Semantic web programmer/developer

Semantic web programmer/developer

0-10

11-20

21-30

31-40

Figure 6 — Resources allocation Pillar 3

28

ELI — Good practices and guidelines 
 
 
 
 
 
 
 
 
 
 
 
Good practice 2:
Estimating implementation costs

Problem statement
In order to decide whether to implement ELI, it is fundamental to pro-
vide an accurate estimate of implementation costs. The development 
of semantic web solutions such as ELI necessitates publishers of legal 
information to take into account not only the technical developments 
required to implement ELI but also other associated costs.

Recommendation
To secure the appropriate allocation of funds, publishers of legal infor-
mation should take into account three main cost drivers:

  product, including hardware and software;

  process, including organisational aspects;

  personnel, taking into account the need for different profiles.

To  ensure  accurate  estimates,  publishers  of  legal  information  should 
identify constraints so as to ensure that the estimates are meaningful.

The cost estimate should take into account not only the costs encoun-
tered during the development of each ELI pillar, but also the maintenance 
of  the  service  provided.  Publishers  of  legal  information  can  rely  on  a 
variety of approaches to carry out their cost estimate including:

1.  consulting the estimate of resources provided in this document;

2.  comparing costs encountered by other publishers of legal informa-

tion when implementing ELI or similar projects;

3.  involving technical experts to estimate the necessary effort.

BENEFITS  

Quality and reliability
Support to the effective implementation of ELI with 
appropriate allocation of resources

DOs

•  Estimate effort, for 
example using full-
time equivalent (FTE), 
which is a unit that 
indicates the workload 
of an employed person 
in a way that makes 
workloads across 
various contexts 
comparable

•  Estimate cost for 

hardware and software

•  Estimate cost to 
manage risks 

DON’Ts

•  Estimate 

implementation effort 
without consulting 
technical experts

•  Underestimate 

coordination efforts

29

PART 2: ELI implementation methodology 
STEP 3: Set up a governance structure

Once the decision to implement ELI has been taken, publishers of legal 
information should ensure that all stakeholders involved in the imple-
mentation project have a clear understanding of the decision-making 
process. For this purpose it is recommended that a governance struc-
ture  be  set  up  that,  for  example,  could  be  composed  of:  a  steering 
committee, providing direction for implementation and review of the 
progress of ELI implementation; a governance committee, in charge of 
managing the operational team(s); and an operational team (or several 
such  teams),  mainly  composed  of  technical  staff,  responsible  for  the 
implementation and maintenance of ELI.

When setting up the governance structure, publishers of legal infor-
mation  should  take  into  account  the  ELI  Council  conclusions,  which 
establish, in Title VI, that Member States should appoint a central or-
ganisation as the national coordination point for ELI. More specifically, 
the annex states the following.

‘On national implementation

1.1.  The national ELI coordinator

1.  Each  country  using  ELI  must  appoint  a  single  national  ELI-

coordinator.

2. The national ELI-coordinator is responsible for:

a)  reporting on the ELI implementation status;

b)  sharing and reporting on the applicable URI template(s);

c)  sharing and reporting available metadata and its relation-

ship to the ELI metadata schema (if applicable);

d)  providing the above information to the ELI TF and the Ex-
pert Group for publishing on the ELI-Register website.’

30

ELI — Good practices and guidelinesSetting  up  a  national  coordination  point  facilitates  the  adoption  of 
common  policies  relevant  in  the  context  of  the  ELI  implementation, 
such as policies on persistent identifiers and metadata. Establishing a 
common policy, while not obligatory, can help in ensuring that rele-
vant technical and organisational aspects are identified and tackled in 
a coordinated manner before any project is started. The references of 
all national ELI coordinators are available on the ELI website (EUR-Lex).

Once the organisational structure is established, publishers of legal infor-
mation can then define change-and-release management procedures 
and quality control procedures. The ELI Taskforce can provide guidance 
in this regard, if their assistance is requested.

31

PART 2: ELI implementation methodologyGood practice 3:
Setting up a central organisation as 
a national coordination point for ELI 
implementation

Problem statement
ELI implementation requires carrying out a number of tasks which, de-
pending on the existing administrative structure, might be assigned 
to different entities. Such a decentralised organisation, however, might 
lead to a number of drawbacks, most notably:

  inconsistencies in formulating coherent URI and metadata policies;

  increased costs for ELI implementation and maintenance.

Recommendation
In line with Title VI and the annex to the ELI Council conclusions, pub-
lishers of legal information should appoint a national ELI coordinator 
responsible for:

‘ a) 

 reporting on the ELI implementation status;

  b) 

 sharing and reporting on the applicable URI template(s);

DOs

  c) 

  sharing  and  reporting  available  metadata  and  its  relationship  
to the ELI metadata schema (if applicable);

•  Follow the ELI Council 
conclusions and appoint 
a national coordinator 
for ELI implementation 

  d)   providing  the  above  information  to  the  ELI  TF  and  the  Expert 

Group for publishing on the ELI-Register website.’

The national coordination points for ELI implementation are available 
on the ELI website.

DON’Ts

•  Allow a decentralised  
ELI implementation  
at national level

32

BENEFITS  

Interoperability
Coherent URI and metadata policies implemented at 
national level

Quality and reliability
Increased opportunities to align ELI implementation 
efforts at national level

ELI — Good practices and guidelines 
STEP 4: Set up an ELI implementation project

ELI can be implemented progressively. This means that publishers do not 
have to go through the full implementation of the three pillars at once. 
Instead, it is possible to take a step-by-step approach. For example, Den-
mark, France, Italy, Luxembourg, Finland and the Publications Office im-
plemented the three ELI pillars all at once, but reduced the scope of the 
implementation to certain content types (i.e. statutory instruments, basic 
acts  excluding  consolidated  texts,  or  Official  Journal  issues).  Following 
such an implementation approach, the next steps should iteratively in-
crease the scope of work to include the remaining content types. Another 
example  of  structuring  an  ELI  implementation  project  comes  from  the 
United Kingdom, which, at the time of drafting this methodology, had im-
plemented the first of the three pillars. The United Kingdom provides ELI-
compliant URI patterns. There is work in progress to convert and publish 
current metadata to ELI equivalents. Similarly, Ireland first implemented 
Pillar 1, and waited for the implementation of its new legal portal before 
implementing Pillars 2 and 3.

ELI implementation can be split into multiple phases to increase control 
over the implementation. Each phase could start out small in scope by 
including only a certain type of content (e.g. statutory instruments), and 
could iteratively scale up by including the remaining types of content (e.g. 
consolidated texts, Official Journal issues) as the implementation advances 
and the expected results become tangible.

Some countries that already have well-structured legislation may imple-
ment all of the pillars of ELI in the first phase, as a prototype with little or 
no impact on the publication processes. In the next phase the result of the 
prototype  could  be  integrated  within  the  publication  processes.  Other 
countries with very little metadata could include Pillars 1 and 2 in the first 
phase to define a minimum set of metadata, design ELI URI patterns and 
enrich legislation with metadata. In the next phase the implementation 
would continue with Pillar 3, to annotate and publish legal information.

The fact that publishers of legal information decide at a certain point to 
limit ELI implementation to one or two pillars does not exclude the pos-
sibility of implementing the third one later on. Keeping this flexibility in 
mind, the key steps that publishers of legal information need to take into 
account when setting up the ELI implementation project are as follows.

1.  Define priorities based on user requirements (cf. ‘Organisation and 
policy’, Step 1) and policy agendas. Since ELI can be implemented 
following a step-by-step approach, publishers of legal information 
can prioritise deliverables between ‘must have’ and ‘nice to have’.

2.   Set  up  a  team  including  a  project  manager,  a  user  representative, 
experts in information management and the semantic web and add- 
itional stakeholders who are impacted by the implementation of ELI.

33

PART 2: ELI implementation methodology3.   Choose an implementation approach that emphasises the use 
of iterative developments whereby regular releases are envisaged 
(for example every 3 months) that allow ELI implementation to be 
built and refined based on user feedback and use cases.

4.   Build  the  project  timeline  taking  into  account  the  time  required 
to design, build and deploy the ELI pillars. By following the iterative 
implementation approach the timeline will consist of short iterations 
of the design, construction and deployment phases for each pillar.

5.  Implement the ELI pillars in line with the developed timeline and 
following the implementation steps provided in this document (cf. 
Pillar 1, ‘How to put in place legislation identifiers based on ELI HTTP 
URIs’, Pillar 2 ‘How to design an ELI metadata schema’ and Pillar 3 
‘How to render ELI metadata machine-reusable’).

6.   Encourage use and raise awareness by providing relevant docu-
mentation and presenting the service via workshops, webinars and 
conferences.

Setting up the ELI implementation project will help to:

  identify high-level implementation options: typically this would en-
tail an analysis of implementing Pillar 1 only, the first two pillars or 
all three pillars;

  understand  whether  to  go  ahead  with  the  implementation  and 

with which pillars;

  define the efforts required for ELI implementation and for the dead-

lines to be met;

  target the main functionalities to be implemented while adopting 

ELI.

34

ELI — Good practices and guidelinesGood practice 4:
Structuring your implementation project

Problem statement
Each ELI pillar can be implemented progressively. Therefore, publishers 
of legal information have flexibility in deciding how to go about the 
implementation of ELI. However, the great flexibility offered by ELI may 
be challenged by the absence of a well-structured project, as it can be 
difficult to identify the right scope and activities.

Recommendation
In order to ensure the successful implementation of ELI, publishers of 
legal information need to have a structured methodology for all the 
execution phases of the project. The methodology described in this 
document can be used to structure the work plan. Overall, key steps to 
be taken into account include:
  gathering requirements;

  analysing existing publication processes;

  designing the solution;

  testing against real data;

  implementation.

Publishers of legal information can decide upon the scope of implementa-
tion based on content types (i.e. statutory instruments, basic acts exclud-
ing  consolidated  texts,  or  Official  Journal  issues).  For  each  content  type, 
the implementation of the three ELI pillars can be broken down as follows.

  Pillar 1 (HTTP URIs): 1. capture requirements for ELI HTTP URIs; 2. de-
sign the URI template; 3. configure the web server for ELI URI resolution.

  Pillar 2 (metadata):  1.  capture  requirements  for  metadata;  2.  design 
and publish the metadata schema; 3. develop metadata extraction rou-
tines; 4. deploy legislation metadata.

  Pillar 3 (rendering ELI metadata machine-reusable): 1. add RDfa 

markup to web pages to facilitate parsing and extraction.

BENEFITS  

Quality and reliability
Project management in a control environment  
helps to deliver within agreed scope, budget,  
time and quality

DOs

•  Build a proof of concept 

to demonstrate ELI 
implementation  
feasibility 

•  Break down the large-
scale implementation 
into phases

•  Take into account risks 

DON’Ts

•  Initiate project before 

carrying out assessment 
and planning

•  Postpone scope 

definition

35

PART 2: ELI implementation methodology 
STEP 5: Formulate statements about URI and 
metadata services provided

Once  publishers  of  legal  information  decide  to  implement  one  or 
more ELI pillars it is advisable to formulate a statement indicating the 
key aspects offered by the service provided. Important elements that 
the statement should contain are as follows.

  Governance:  the  national  coordination  point  for  ELI  should  be 
described as being the authoritative source of information for the 
implementation of ELI. 

  ELI  URI  template(s):  the  statement  should  provide  information 
about the URI template(s) for each type of published document (i.e. 
statutory instrument, consolidated texts or Official Journal issues). 
The statement could be published on the ELI website.

  Metadata: the statement should also refer to the metadata for each 
type of published document if the ELI implementation also includes 
the second pillar. Such information should also provide information 
on existing relationships supported by the ELI metadata, along with 
mappings with other standards (cf. Pillar 2, Steps 2, 3 and 4). Further-
more, information about the quality of metadata could be included, 
as this is also important in terms of liability for the publishers of legal 
information.

In general, publishers of legal information are encouraged to say what 
level of commitment they want to set up, without having to necessarily 
quantify it.

Finally, the statement should also address technical and non-technical 
profiles and should be published on the ELI website to raise awareness 
and promote the reuse of legal information.

Examples of statements about ELI URI can be found by following the 
links below.

PARTICIPANT

REFERENCE TO DOCUMENTATION

France

Ireland

http://www.eli.fr/en/constructionURI.html

http://www.irishstatutebook.ie/pdf/ELI_URI_schema.pdf

Publications Office

http://publications.europa.eu/mdr/eli/documentation/uri_templates.html

United Kingdom

http://www.legislation.gov.uk/developer/uris

Denmark

https://www.retsinformation.dk/eli/

36

ELI — Good practices and guidelinesGood practice 5:
Writing a policy document providing 
guarantees for long-term persistence

Problem statement
The  absence  of  sufficient  guarantees  for  the  persistence  of  URIs  and 
metadata when implementing ELI can have a negative impact on the 
level of trust among potential consumers of legislation. Reduced trust 
may,  in  turn,  result  in  limited  use  of  the  legal  information  published, 
therefore limiting the potential for the creation of added-value services.

Recommendation
By  drafting  a  policy  document  that  provides  sufficient  guarantees 
with regard to the persistence and quality of the information provided, 
publishers increase confidence in relying on HTTP URIs and metadata 
to access and reuse legal information. Such a policy document should 
address the following.

1. Needs: for example, the need for stable URIs or the need to avoid 
duplication of identifiers for the same resource.

2. Governance structure: there should be a short description of how 
the management of URIs and metadata is performed and who is re-
sponsible for the proper maintenance of the publication service.

3. Technical aspects: the policy document should make reference to 
the technical aspects of the URI policy and metadata policy. The policy 
document should be published on the ELI website and promoted by 
the publishers of legal information.

BENEFITS  

Access to legislation
Clear understanding of access and reuse requirements

Interoperability
Promotion of greater interoperability thanks to clear 
documentation

Quality and reliability
Increased level of commitment to provide a quality  
data service

DOs

•  Take into account the 

persistence requirement 
when designing ELI URIs

•  Write and publish a 
policy document for 
persistent ELI URIs 
and metadata on a 
dedicated ELI website

•  Describe how 

persistence will be 
ensured if the national 
coordination point 
changes

•  Consult policy 

documents of those 
who have already 
implemented ELI

DON’Ts

•  Ignore the needs of 

consumers of legislation 
to have guarantees of 
persistence

•  Take for granted the 
trust of consumers of 
legislation in service 
levels

37

PART 2: ELI implementation methodologyPillar 1: 
How to put in place 
legislation identifiers 
based on ELI HTTP URIs

38

STEP 1: Capture requirements for HTTP URIs

The  first  step  that  publishers  of  legal  information  should  take  when 
approaching the implementation of the first ELI pillar (i.e. HTTP URIs) 
is to get a detailed understanding of user needs and, if necessary, up-
date the business case (cf. ‘Organisation and policy’, Step 1). Many tech-
niques are available for gathering user requirements. In order to gain 
a complete overview of the requirements that are relevant for the im-
plementation of ELI HTTP URIs, publishers of legal information might 
consider the following approaches.

  Interviews: publishers of legal information should gather detailed 
information on what type of tasks users carry out with legal infor-
mation, and understand how they cite legal information and what 
type of information they expect to find online. Interviews are very 
useful in this regard because they allow an in-depth analysis to be 
carried out and new requirements uncovered.

  Questionnaires: questionnaires are useful when publishers of legal 
information need to gather a large number of requirements from a 
wide audience, including users in remote locations that cannot be 
interviewed individually. It is advisable to complement the results 
gathered via questionnaires with more in-depth approaches.

  Prototyping: this  technique  allows  requirements  to  be  gathered 
that will help publishers of legal information to build the initial ver-
sion  of  the  HTTP  URI.  The  development  of  a  prototype  on  HTTP 
URIs will help users provide feedback that will be used to refine the 
HTTP URI implementation. This process should continue until the 
HTTP URI template meets the critical mass of user needs.

  Use cases: use cases are useful to describe how and for what purpose 
HTTP URIs for each type of content are used. Examples of use cases 
for HTTP URIs might include: consultation of legislation as it stood at 
a specific point in time; access to the consolidated version of specific 
piece of legislation; references to legal information in social media.

On top of gathering user requirements, publishers of legal information 
should take into account needs that are more related to the charac-
teristics of legal information and to the environment where the HTTP 
URIs will be developed, such as the following.

  Whether there is a single authority that attributes the identifiers 
or whether the attribution of identifiers is done in a decentralised 
manner. For example, in a federal system like Germany, since there 
are 16 Bundesländer that promulgate legislation, the attribution of 
identifiers is decentralised.

  The fact that legal information might not all have an identifier to 
be used to uniquely identify legal information, which means that 

39

PART 2: ELI implementation methodologyalternative options should be considered. This is the case for Lux-
embourg where, for example the following regulation:

Règlement  grand-ducal  du  2  février  2015  portant  organisation  de  la 
Conférence nationale des élèves

is identified uniquely with an ELI-compliant HTTP URI by adding a 
sequential number (cf. ‘n7’), as shown below

http://eli.legilux.public.lu/eli/etat/leg/rgd/2015/02/02/n7 (1).

Another example can be seen in Norway. Before Lovdata (2) existed 
not all regulations had numbers. As a result, when Lovdata came 
into existence it introduced numbers to legislation in a systematic 
way. Where numbers did not exist (i.e. for regulations and statutes 
published  before  1982)  Lovdata  retroactively  assigned  them,  and 
from  1982  all  regulations  got  an  official  number  published  in  the 
Legal Gazette.

  The  fact  that  legislation  may  be  published  in  different  websites, 
with  different  domain  names.  For  example,  in  Italy,  basic  acts  are 
published  on  the  Gazzetta  Ufficiale  website,  while  consolidations 
can be browsed on the Normattiva website. Domain-agnostic URIs  
(e.g. http: // data. country. eu/eli/, etc.) may help in this situation.

  The  need  to  identify  whether  legislation  is  published  as  an  indi-
vidual resource, or in the context of an official journal, or both. For 
example, Italy provides ELI for both of the following.

•  Official journal:  

http://www.gazzettaufficiale.it/eli/gu/2015/1/13/9/sg/html.

• 

Individual resource:  
http://www.gazzettaufficiale.it/eli/Decreto/2013/65/art4.

For information on the different URI template components, please 
see  the  Italy  page  of  the  ELI  website:  http://eur-lex.europa.eu/eli-
register/italy.html.

  Take into account when consolidation takes place (when applicable). 
For  example,  France  consolidates  legislation  immediately  after  the 
amending  act  has  been  adopted  and  has  put  in  place  a  specific 
database  for  it,  which  is  called  ‘LEGI’.  Ireland  instead  consolidates 
legislation on a case-by-case basis, and mostly for large acts.

(1) The elements of the ELI templates are explained here:  
etat = jurisdiction/agent, country-wide 
leg = type, legislation 
rgd = subtype, règlement grand ducal 
2.2.2015 = date of signature 
n7 = sequence number, distinguishing legislation signed on the same day
(2) Lovdata is a foundation which publishes judicial information on Norway 
(https://lovdata.no/info/information_in_english).

40

ELI — Good practices and guidelines  The existence of more than one calendar. This is the case for Ireland 
and the United Kingdom where, prior to 1922 and 1963 respectively, 
the regnal years were used to identify the year that legislation was 
published. To overcome such a challenge, these countries decided 
to redirect URIs with a calendar year before these dates to a URI based 
on the Gregorian calendar. Although such an approach worked for the 
majority of the cases, there were a small number of items of legislation 
held on the United Kingdom website where this redirection could not 
have been done unambiguously. For such cases a list of candidates is 
given in response to the user, who then has to choose the right legisla-
tion.

  The existence of legacy identifiers. It may be that when publish-
ers of legal information implement ELI they already assign identi-
fiers to legal information. When this is the case these identifiers can 
continue  to  be  supported.  For  example,  in  the  past  Ireland  went 
through two iterations of URI patterns. The first implemented pat-
tern was not user friendly and it had to be replaced around 2004. 
The second URI pattern was a user-friendly pattern that had some 
resemblance to the current ELI URI schema. As there are still a large 
number of websites that link to the eISB (the electronic Irish Statute 
Book) using the old pattern, redirection is planned from the old to 
the new HTTP ELI pattern.

41

PART 2: ELI implementation methodologySTEP 2: Design the URI template

The  ELI  Council  conclusions  provide  the  following  components  that 
publishers of legal information can use to design HTTP URIs for each 
type of content published.

/eli/{jurisdiction}/{agent}/{sub-agent}/{year}/{month}/{day}/{type}/ 
{natural identifier}/{level 1…}/{point in time}/{version}/{language}

When designing ELI URI schemas it is important to make a distinction 
between the (abstract) legal resources and their realisations. In this way 
it will be possible to identify a reference to legislation independently of 
the version, language, representation format, etc.

For example, URI http://legilux.public.lu/eli/etat/leg/loi/2011/04/08/n2 
identifies  the  abstract  basic  act  ‘Loi  1974  04  16’.  When  Legilux  (1)  re-
ceives a request for this kind of resource, it returns:

  the Legilux page of the latest consolidated version of an act;
  if  no  consolidated  version  exists,  the  Legilux  page  of  the  base  act 
(identified by http://legilux.public.lu/eli/etat/leg/loi/2011/04/08/n2/jo);
  and  always  includes  the  not-yet-integrated  ‘rectificatifs’  (amend-
ments), if any (e.g. http://legilux.public.lu/eli/etat/rgd/2011/04/08/n2/
republication/20140331/jo).

The picture below shows examples of ELI URI templates of an abstract 
legal resource, a basic act, modifying acts and their consolidations.

Figure 7 — Example of URIs for an abstract legal resource,  
basic and modifying acts and consolidations

42

(1) Journal Officiel du Grand-Duché de Luxembourg: www.legilux.public.lu.

ELI — Good practices and guidelines 
Examples of identifiers close to the way  
legislation is cited

LEGAL INSTRUMENT

EU: Directive 2003/98/EC of the 
European Parliament and of the 
Council of 17 November 2003 on the 
reuse of public sector information

Italy: Decreto 27 febbraio 2013, n. 65 
Regolamento, di cui all’articolo 16, 
comma 1 del decreto legislativo  
1° giugno 2011, n. 93, per la redazione 
del Piano decennale di sviluppo delle 
reti di trasporto di gas naturale

IDENTIFIER FAR FROM 
THE WAY LEGISLA-
TION IS CITED

IDENTIFIER CLOSE TO THE WAY  
LEGISLATION IS CITED 

(ELI HTTP URI)

32003L0098

http://eur-lex.europa.eu/eli/dir/2003/98/oj

13G00106

www.gazzettaufficiale.it/eli/
Decreto/2013/65

In addition to design, ELI URI schemas usually match the types of legal 
resources, but it is also important to take into account how people will 
use  URIs.  People  should  find  identifiers  of  legal  information  that  are 
easy  to  use,  thus  the  closer  identifiers  are  to  the  way  the  legislation 
is cited the easier it is to understand them, remember them and use 
them. For illustrative purposes, two examples are provided below. The 
first identifier is far from the way legislation is cited, the second one (ELI 
HTTP URI) is close to the way legislation is cited.

As the examples above demonstrate, it is easier to remember and re-
use an identifier that is close to the way legislation is cited compared to 
a number with a more complex structure that is less intuitive.

When designing the ELI URI template(s), publishers of legal informa-
tion should follow the following steps:

  identify how legal information is cited (Good practice 6);

  ensure that each legal resource is identified uniquely (Good practice 7);

  take into account the type of content to be published (e.g. statutory 
instruments vs acts, basic acts vs consolidated texts, official journals) 
and the concepts of the ELI ontology (legal resource, legal expression 
and format) (Good practice 8);

  identify subparts of legal information (Good practice 9);

  follow good practices for HTTP URIs (Good practice 10); and

  test URI templates (Good practice 11).

Publishers of legal information can find a number of examples of ELI 
HTTP URIs on the ELI website. An example is the HTTP URI template 
implemented in Luxembourg, shown together with a concrete example 
in the table below.

43

PART 2: ELI implementation methodologyCOUNTRY/LEGAL INSTRUMENT

ELI TEMPLATE/EXAMPLE

Luxembourg 

/eli/etat/leg/{type}/{année}/{mois}/{jour}/{id}

Règlement grand-ducal du 2 février 2015  
portant organisation de la Conférence  
nationale des élèves

France 

http://eli.legilux.public.lu/eli/etat/leg/rgd/2015/02/02/n7

/eli/{type}/{year}/{month}/{day}/{natural identifier}/{domain}/
{version}/{level}/{point in time}/{language}/{format}

A second example is the HTTP URI template used in Ireland.

COUNTRY/LEGAL INSTRUMENT

ELI TEMPLATE/EXAMPLE

Ireland

Motor Vehicle (Duties and Licences) Act 2012 
(10/2012)

/eli/{year}/{type}/{Natural identifier}/{Level 1…}/{Point in 
Time}/{Version}/{language}

http://www.irishstatutebook.ie/eli/2012/act/10/enacted/en 

In addition, examples of ELI HTTP URI templates used in France can be 
found here: http://www.eli.fr (1).

Finally, examples of ELI HTTP URI templates developed by the Publica-
tions Office can be found in the specific section on URI templates on 
the Metadata Registry (2) website.

44

(1) http://www.eli.fr/en/constructionURI.html
(2) http://publications.europa.eu/mdr/eli/documentation/uri_templates.html

ELI — Good practices and guidelinesGood practice 6:
Designing URI template(s) to stay as close as 
possible to existing citation practice

Problem statement
Legislation is cited in different ways depending on the country, type 
of legal instrument and user. For example, legislation may be cited ac-
cording to: the title (short or long); the number of the legislation; the 
date of adoption or publication. Citation practices are used to identify 
legal  information  and  therefore  the  design  of  URI  templates  should 
comply with existing citation practices. If publishers of legal informa-
tion do not follow this approach they greatly reduce the potential to 
share, reuse, cite and link legal information.

Recommendation
When designing URI patterns, publishers should stay as close as possible 
to existing citation practices. This can be achieved by using any of the 
available elements of the ELI URI template in any order. It is important 
that URIs be flexible and user friendly. Elements found in ELI URI templates 
that are commonly used in citation practices are: year, type of legislation, 
identifier and version (1). See the following French example.
Vue le décret n° 2014-1169 du 10 octobre 2014 modifiant diverses dispositions 
réglementaires du code de la défense
ELI  HTTP  URI:  http://www.legifrance.gouv.fr/eli/decret/2014/10/10/
DEFD1415169D/jo/texte
A  relevant  standard  for  ELI  implementation  is  the  specification  of  the 
URI described in the Internet Engineering Taskforce Request for Com-
ment 3986, ‘Uniform Resource Identifier (URI): generic syntax’ (2). Further 
guidance on how to effectively use URIs in the context of the semantic 
web is given by W3C in the document Cool URIs for the semantic web (3). 
Additional principles that should be applied in designing URI templates 
are described in the document 10 rules for persistent URIs (4).

BENEFITS  

Access to legislation
Improved discovery of legislation

Interoperability
Greater interoperability by means of common URI 
design patterns

Quality and reliability
Ensures availability of quality URIs

DOs

•  Design ELI URI 

template(s) close to 
citation practice

•  Ensure that URIs are 

human readable/reader 
friendly 

DON’Ts

•  Add elements in the URI 
template that are not 
necessary to identify a 
piece of legislation in a 
unique way

(1) Examples of URI patterns can be found on the ELI website.
(2) https://tools.ietf.org/rfc/rfc3986.txt
(3) http://www.w3.org/TR/cooluris
(4) https://joinup.ec.europa.eu/community/semic/document/10-rules-persistent-uris

45

PART 2: ELI implementation methodology 
Good practice 7:
Modelling HTTP URIs by treating each piece 
of legislation as a unique resource

Problem statement 
If one HTTP URI resolves to more than one piece of legislation, 
a request for that HTTP URI will receive in response all the pieces 
of legislation resolved by that URI. This is called the URI homonym
problem and can lead to confusion and interoperability conflicts 
as it might not be clear what resource is associated with a URI.

Recommendation
When identifying legislation by means of HTTP URIs it is important to 
first ensure that each HTTP URI identifies each piece of legislation in a 
unique way, i.e. publishers should ensure that a given HTTP URI will iden-
tify a single piece of legislation. Difficulties may typically occur when:

  the legislation does not have a number;

  the same number is attributed to more than one piece of legislation. 

If the legislation does not have a number, it is recommended that one 
be attributed in the URIs. This is the approach followed by Luxembourg, 
where legislation is cited without a number as the example shows:

Règlement grand-ducal du 2 février 2015 portant organisation de la Confé-
rence nationale des élèves.

DOs

The URI identifier for this act includes ‘n7’ in order to uniquely identify it. 

http://eli.legilux.public.lu/eli/etat/leg/rgd/2015/02/02/n7

If the same number is attributed to more than one piece of legislation, 
it is important that the URI is designed in such a way that it includes 
enough elements to distinguish the two pieces of legislation, for ex-
ample by including dates of adoption, the author, jurisdiction, etc. The 
choice of which elements to select is left up to the publishers of legal 
information, since each legal system has its own specificities. 

BENEFITS  

Access to legislation
Unambiguous assignment of URIs to legislation resources 
makes the legislation more discoverable

Interoperability
Reduced risk of interoperability conflicts

•  Design a mechanism 
to assign additional 
numbers or character 
strings to disambiguate 
URIs if they lead to the 
same texts

•  Use aliases in order 
to strike a balance 
between consistency of 
URI scheme and reality 

DON’Ts

•  Try to model an official 
journal; treat legislation 
as resources by 
themselves

46

ELI — Good practices and guidelines 
Good practice 8:
Taking into account the concepts of the ELI 
ontology: legal resource, legal expression 
and format
Problem statement
ELI  describes  legal  information  based  on  the  well-established  FRBR 
model and distinguishes between the concepts of:

  ‘legal resource’ or ‘work’ (intellectual or artistic creation);

  ‘legal  expression’  (the  intellectual  or  artistic  realisation  of  a  work, 

typically in a text, a sequence of signs); and

  ‘format’ or ‘manifestation’ (materialisation of one of the expressions 

in a file). 

Each time a ‘work’ is realised it takes the form of an ‘expression’. The 
physical embodiment of an expression is a ’format’, or ‘manifestation’.

In line with the commonly known best practices for linked data, such a 
structure enables the retrieval of various resource representations via 
content negotiation (cf. Good practice 12), but to do so it is necessary 
to ensure that the HTTP URIs that identify the legal information also 
follow this structure.

Recommendation
While the use of the FRBR structure should be transparent to the user 
when  navigating  through  the  URIs,  publishers  of  legal  information 
should follow the FRBR structure when designing the HTTP URIs.

Assigning URIs to abstract legal resources, independently of the tem-
poral version of an act, provides the opportunity to group basic acts 
and consolidations together.

For example:

  eli/etat/leg/loi/2011/04/08/n2  —  identifies  the  abstract  basic  act 

‘Loi 1979 04 16’;

  eli/etat/leg/loi/2011/04/08/n2/jo  —  identifies  the  act  as  it  was 

originally published;

  /eli/etat/leg/rgd/2011/04/08/n2/consolide/20120830 — identifies a 

DOs

consolidated version of this act. 

BENEFITS  

Access to legislation
Allows retrieval of various legal resources representations

Interoperability
Contributes to the creation of the ‘web of data’ since the 
FRBR hierarchy allows provision of the set of metadata at 
each level

•  Take into account the 
ELI ontology structure 
when designing the ELI 
URIs 

DON’Ts

•  Structure ELI HTTP 
URIs following a 
representation other 
than the FRBR model

47

PART 2: ELI implementation methodology 
Good practice 9:
Considering the right level of granularity 
when identifying legislation

Problem statement 
Citations to legal information can include references to subparts of a 
legal act. However, the production workflows are generally designed 
to handle identification of an act as a whole. The identification of an 
act without identifying its subparts, while a key step in ELI implemen-
tation,  can  be  a  limitation  for  the  reuse  of  legal  information.  For  ex-
ample, users might want to directly cite a specific provision of a piece 
of legislation when using social media or other online tools, without 
providing a reference to the legislation as a whole.

Recommendation
When  implementing  ELI  it  is  important  to  identify  the  right  level  of 
granularity of the HTTP URIs. The ELI ontology published on the Meta-
data  Registry  (1)  allows  publishers  of  legal  information  to  model  the 
components of a legal act, at any level of precision (e.g. chapter, article, 
paragraph, etc.) by using the class ‘eli:LegalResourceSubdivision’ and 
its property ‘is_part_of’.

For  example,  the  United  Kingdom  has  developed  a  URI  model  that 
considers  the  ‘section’  parameter.  This  parameter  refers  to  particular 
sections, articles and regulations within a piece of legislation. 

The template of the URI including this parameter is the following:

  http://www.legislation.gov.uk/id/{type}/{year}/{number}[/{section}]

The identifier URI for Act of the Scottish Parliament 2014, Number 2 is:
  http://www.legislation.gov.uk/id/asp/2014/2

The identifier URI for Section 3 of the same document is:
  www.legislation.gov.uk/id/asp/2014/2/section/3

In general, if the production workflow is based on XML structures it 
may be relatively easy to determine the more granular levels by pro-
cessing the XML records. This may require, however, that unique iden-
tifiers be assigned to each XML element corresponding to a section, 
with impacts on the publishing workflow.

While  the  implementation  of  ELI  for  subparts  can  typically  be  done 
in the second phase of the project, it is important to integrate it into 
the design of HTTP URIs from the beginning if such implementation 
is envisaged.

(1) http://publications.europa.eu/mdr/eli/documentation/ELI_Ontology-v1.0.htm 

48

ELI — Good practices and guidelinesBENEFITS  

Transparency
Improved understanding of the context in which legal 
information exists

Access to legislation
Increases the type of information that is searchable and 
indexable

Interoperability
Allows better interaction between information systems

Savings 
Increased interoperability between IT systems can lead to 
reuse of information, and thus creates opportunities for 
cost optimisations

DOs

•  Design ELI URIs that take 
into account subparts of 
legal acts

•  Keep in mind the way 
external users will 
want to use the URI, 
for example in social 
networks or in value-
added services 

DON’Ts

•  Assign ELIs only at the 
level of acts and ignore 
the benefits of more 
granular identification 
and description

•  Use anchors in the 
HTML code

49

PART 2: ELI implementation methodologyGood practice 10:
Following common good practices for  
HTTP URIs
Problem statement
Designing URI templates in isolation, without learning from the experi-
ences of those who have already done it, increases the risk of repeating 
the same mistakes, duplicating analysis and wasting resources by solv-
ing problems that have already been addressed by others.

Recommendation
While it is not possible to provide a fit-for-all URI template, there are a 
number of good practices that publishers can follow in order to fos-
ter  the  access  to  and  reuse  of  legal  information.  Key  good  practices 
include:

DOs

  avoiding using more elements than necessary to identify legal informa-

tion in a unique way;

  staying as close as possible to existing citation practice (cf. Good prac-

tice 6);

  implementing the FRBR hierarchy in the URI scheme (cf. Good practice 8);

  avoiding using elements that tend to change in HTTP URIs.

These elements are important to guarantee the persistence of the URIs. 
Furthermore, when URIs are deprecated, meaning that they should no 
longer be used, they should nevertheless be maintained both in terms 
of the actual URI and the resource they identify. Once minted, a URI 
should  not  be  deleted  and  a  redirection  mechanism  should  be  put 
in place (cf. Good practice 15). Where URIs identify resources that are 
versioned, new URIs should be minted for each new version of the re-
source, along with a URI for the latest version.

BENEFITS  

Quality and reliability
High-quality URIs which meet users’ needs

•  Use or create an 
integrated workflow 
for publication that 
includes the assignment 
of identifiers

•  Use elements in the URI 
template(s) to indicate 
subparts of legislation 
(e.g. an article of a piece 
of legislation you want 
to identify)

•  Create pleasing and 
recognisable identifiers 
so that people will 
understand what they 
can expect to find when 
they click on it 

DON’Ts

•  Use more elements than 
necessary in the URI 
template

•  Include elements in the 
ELI that might be prone 
to change

•  Use different URIs to 
identify the same piece 
of legislation

50

ELI — Good practices and guidelinesGood practice 11:
Testing URIs against real data
Problem statement
When  designing  URI  templates,  publishers  of  legal  information  may 
face a number of challenges, such as being able to correctly identify 
subparts of legislation, being able to uniquely identify legislation that 
does not have a unique identifier or being able to handle dates where 
more than one type of calendar year applies. These difficulties may not 
immediately  be  apparent  during  the  design  phase  of  ELI  HTTP  URIs 
and it may not be possible to foresee all possible scenarios.

Recommendation
To reduce the risk of developing URI design templates that do not take 
into account all possible scenarios, it is recommended that tests be per-
formed as early as possible. The tests should reveal issues related to the 
correspondence between URIs and the way legislation is cited; identifica-
tion of consolidated acts (when applicable); and resolution mechanisms. 
Tests should also include simulations of probable scenarios that can hap-
pen during the publication process, such as: 1. create a new legal act; 2. 
update the content of an act by altering its structure; 3. replace an act; 
4. amend an act; 5. consolidate an act. The tests should be designed to 
match the context of each implementer. For example, the Publications 
Office had to find a way to assign unique and persistent URIs to legisla-
tion that did not have an identifier, such as corrigenda, which led to the 
following URI template for corrigenda:

h t t p:// data.europa. eu/eli / {typedoc}  / {year} / {natural_number}/ 
corrigendum  /  {pub_date} / oj where ‘typedoc’ is the resource type of the 
corrected act and ‘pubdate’ is the date of publication of the corrigen-
dum in the Official Journal.

BENEFITS  

DOs

•  Choose diverse datasets 

for testing purposes

•  For each tested dataset, 
compare the obtained 
ELI URIs to the way 
people cite legislation

•  Test all the activities 
related to your URI 
management processes

•  Test as many scenarios 
as possible and check 
results with users from 
the business side 

Access to legislation
Ensures that all possible scenarios are taken into account

DON’Ts

Interoperability
Ensures quality of URI templates, which in turn increases 
trust and potential for others to rely on them

Quality and reliability
Reduced risks of wrongly identifying legal information

•  Start large-scale 

implementation without 
testing your ELI URI 
template(s)

•  Test only main scenarios 
related to management 
activities of your URIs

51

PART 2: ELI implementation methodology 
STEP 3: Configure web server for ELI URI 
resolution

Publishers of legal information should design HTTP URIs in such a way 
that they resolve to legislation. Resolution means that if an HTTP re-
quest is issued (either by a human using a web browser or by a ma-
chine/an application) to a web server, this returns a representation of 
the resource, either:

  the metadata of the legal resource (in either a human-readable or a 

machine-readable way);

  the legal resource document itself (in one of its available formats, 

e.g. HTML, PDF, XML).

The  resolution  mechanism  refers  to  the  service  provided  by  a  web 
server that handles URI requests of HTTP clients and attempts to ob-
tain a representation of the resource that the URIs identify.

Legislation resources must be associated with content information so 
that resolution of HTTP URIs leads to a response with data.

ELI does not impose a specific solution. Depending on different scenarios, 
publishers  of  legal  information  may  decide  to  return  metadata  and 
content or one of the two. For example, if a publisher of legal informa-
tion does not have metadata, but only the full text of the legislation in 
PDF format, ELI does not oblige the publisher to implement metadata. 
In this case the publisher of legal information may decide to only return 
the actual legal resource.

It is recommended that tests be carried out to uncover and correct any 
potential issues.

It  is  important  to  always  schedule  production  deployments  and  to 
publicly  announce  such  events  well  in  advance.  It  is  also  useful  for 
the publishers of legal information to offer a short description of the 
changes  that  will  occur  after  deployment.  By  making  such  informa-
tion publicly available, consumers of legislation are aware of upcoming 
changes and can be prepared.

52

ELI — Good practices and guidelinesGood practice 12:
Using content negotiation and/or identifiers 
for language and format variants
Problem statement 
If legislation — or the metadata describing legislation — is available in 
multiple languages and formats, publishers of legal information need 
to decide how to identify these different languages and formats.

Recommendation
To identify language and format variants, different persistent URIs can be 
used, possibly in combination with content negotiation. As described in 
Good practice 8, different language versions of legislation can be con-
sidered  to  be  different  ‘expressions’,  whereas  different  formats  can  be 
considered to be different ‘manifestations’ of the same ‘work’ following 
the ELI ontology. Minting different URIs for these language and format 
variants of the same ‘work’ is good practice, whereby only meaningful 
language and format indicators should be used. For example, the use 
of technology-specific extensions like .asp, .aspx and .jsp in URIs should 
be avoided as this is prone to change; meaningful format indicators like 
HTML, RDF and PDF should be allowed. For example, the following URI 
could be used to distinguish an English-language variant in HTML format:
http://data.europa.eu/eli/dir/2013/37/oj/eng.html.
Additionally, it may be useful to apply content negotiation, although this 
is not explicitly required by the ELI Council conclusions. Content nego-
tiation is the process that takes place between a web server and a web 
agent to select and provide the best representation for a given response 
when there are more representations available. Such a mechanism allows 
a request to be sent to a web server and the desired specific representa-
tion to be specified in the header of the request. For example, requesting 
the  resource  http://data.europa.eu/eli/dir/2013/37/oj,  and  providing  the 
‘Accept’ parameter in the request header with the value ‘text/html’, and 
the  ‘Accept-Language’  parameter  with  the  value  ‘en’,  would  allow  the 
server to choose the appropriate response, which in this example could 
be http://data.europa.eu/eli/dir/2013/37/oj/eng.html. 

BENEFITS  

Access to legislation
Better access to legislation by allowing consuming 
applications to request the format that is most 
appropriate in a particular situation

Interoperability
Increases the flexibility of adding or removing 
representation formats of resources while preserving 
persistence of URIs

DOs

•  Include meaningful 

format indicators in ELI 
URIs such as .html, .rdf, 
etc.

•  Consider using content 

negotiation 

DON’Ts

•  Use technology-specific 

extensions in the ELI URIs 
like .asp, .aspx, .jsp, etc.

•  Include website-specific 
elements in the URIs, 
such as session cookies, 
etc.

53

PART 2: ELI implementation methodology 
Good practice 13:
Providing service-level guarantees

Problem statement 
Potential consumers of legal information might be reluctant to rely on 
URIs if:

  they do not have enough guarantees that URIs are resolvable and 

persistent; and

  they do not have a reasonable request–response time and an ac-

DOs

ceptable level of data quality.

Recommendation
It is recommended that service-level guarantees be offered as part of the 
URI policy. The service-level guarantee should be a commitment to offer:

  resolvable URIs;

  long-term persistence of minted URIs;

  a reasonable request–response time;

  reasonable quality of legislation.

The  service-level  guarantee  should  also  provide  information  about 
how issues encountered by the legislation consumers will be reported, 
who will address reported issues and how the resolution will be com-
municated back to those who reported them. 

BENEFITS  

Access to legislation
Increased consumption of published legislation

Interoperability
Improved trust and thus reuse potential

Quality and reliability
Improved reliability of legal information published

•  Plan to provide service-
level guarantees

•  Plan to monitor 
performance of the 
resolution mechanism 
and the provision of 
service-level guarantees

•  Ensure consumers of 
legislation can access 
service-level guarantees

•  Review the service-
level guarantees on a 
regular basis and adapt 
whenever necessary

DON’Ts

•  Allow poor performance 
of the resolution 
mechanism, as 
this will reduce the 
interoperability 
potential of your 
solution

•  Ignore issues reported 
by consumers of 
legislation

54

ELI — Good practices and guidelines 
 
Good practice 14:
Monitoring website usage and links to 
legislation on the web through statistics

Problem statement
Monitoring the website traffic might not always be a common prac-
tice  among  publishers  of  legal  information.  As  a  consequence,  they 
have  a  very  limited  insight  about  uses  of  legal  information  and  any 
problems encountered by the users. Without having a good overview 
of  the  users’  experience,  publishers  of  legal  information  might  miss 
opportunities to correct errors and ultimately improve the service ac-
cording to the users’ needs.

Recommendation
It is recommended that tools be implemented to regularly analyse the 
website traffic to optimise and improve access to published legislation. 
Key indicators that should be monitored include: 1. visits: the number 
of  visits  to  the  website  during  a  given  time  period;  2.  unique  visitors: 
the number of different people who visited the website during a given 
time period; 3. visitor demographics: the profile of the website’s audi-
ence  such  as  the  geographic  location,  language,  gender,  age,  etc.;  4. 
bounce rate and time on site: whether visitors find what they are look-
ing for in the website or if they leave it immediately; 5. type of sources: 
it segments the traffic by specific sources and mediums, such as search 
engines, referring sites, email or custom campaigns; 6. access by redirec-
tions  of  URLs  vs  access  by  redirections  by  a  search  engine:  users  that 
look for legislation according to the URI templates; 7. social media inter-
actions: amount of visitors that interact with social media profiles. 

BENEFITS  

Quality and reliability
A careful watch of key traffic metrics will allow the 
provision of the stated service-level guarantees, and 
will constantly optimise and improve the quality of 
service

DOs

•  Implement website 
traffic analytics tools

•  Watch key performance 
indicators to constantly 
look for improvements 

DON’Ts

•  Ignore surveying the 
website traffic, as this 
can lead to a lack of 
persistence of services

55

PART 2: ELI implementation methodology 
 
Good practice 15:
Monitoring service levels and persistence of 
URIs

Problem statement
The added value that ELI brings in terms of increased persistence and 
common  use  of  metadata  to  describe  legal  information  could  be 
greatly hampered by the absence of a reliable online service. In fact, if 
users are not able to access legal information in a consistent and timely 
fashion due to poor service performance, their level of trust in the ser-
vice will decrease and they will tend not to rely on it in the future.

Recommendation
It is recommended that tools be deployed that allow the monitoring of 
website traffic. Such monitoring will allow the discovery of issues such 
as broken links or long request–response times. By finding such issues 
in  time,  the  appropriate  actions  can  be  taken  in  a  timely  manner  to 
remedy the situation, thus providing the guarantee of a quality service.

The analysis of weblog files can provide valuable insights into the web 
server’s performance. GoAccess (1) is a popular choice for this task. It 
can run in a terminal window, and is useful for quickly analysing and 
viewing web server statistics in real time. It can be used to generate 
HTML, JSON and CSV reports from the weblogs.

Besides monitoring performance of the web traffic generated by visitors, 
it is recommended that load and stress tests be performed. Such tests 
allow understanding of the behaviour of a system under a specific ex-
pected load and its limits. Some of the most popular tools for load and 
stress testing are curl-loader (2), ApacheBench (3) and Httperf (4).

It is recommended that the response time to issues reported by the 
legislation be monitored and statistics gathered about the resolution 
of issues. This will allow the optimisation of the issue reporting–resolv-
ing mechanism.

BENEFITS  

Quality and reliability
Better quality of the service thanks to prompt replies to 
any occurring issues

(1) http://goaccess.io
(2) http://curl-loader.sourceforge.net 
(3) http://httpd.apache.org/docs/2.2/programs/ab.html
(4) https://github.com/httperf/httperf

DOs

•  Monitor website service 
levels. Fix any observed 
or reported issue in a 
timely manner

•  Review and optimise 
your issue-resolution 
mechanism 

DON’Ts

•  Ignore low request–
response times and 
broken links

•  Ignore issues reported 
by consumers of 
legislation

56

ELI — Good practices and guidelines 
Pillar 2: 
How to design an ELI 
metadata schema

57

STEP 1: Capture requirements for metadata

The second ELI pillar is described in the annex to the Council of the Euro-
pean Union’s conclusions (1) which explains that:

‘While  a  structured  URI  can  already  identify  acts  using  a  set  of  defined 
components,  the  attribution  of  additional  metadata  established  in  the 
framework of a shared syntax will set the basis to promote interchange 
and enhance interoperability between legal information systems. By iden-
tifying the metadata describing the essential characteristics of a resource, 
Member States will be able to reuse relevant information processed by 
others for their own needs, without having to put into place additional 
information systems. Therefore, while Member States are free to use their 
own metadata schema, they are encouraged to follow and use the ELI 
metadata  standards  with  shared  but  extensible  authority  tables,  which 
permit  to  meet  specific  requirements.  The  ELI  metadata  schema  is  in-
tended to be used in combination with customised metadata schemas.’

Metadata provides the means for describing, classifying, linking, finding 
legal information as well as connecting it to other pieces of information 
and enabling users to access and reuse it. It includes, for example: title, 
date of adoption, date of signature, and author of a given piece of legisla-
tion.  Having  the  ability  to  search  and  access  legal  information  through 
metadata makes it much easier for someone to locate and use a specific 
piece of legal information. Moreover, connecting legal information with 
external sources (e.g. providing references to a controlled vocabulary (2) 
to  describe  the  subject,  or  a  geographical  location  related  to  the  legal 
information,  or  the  publishing  body)  provides  a  wider  context  for  the 
published legislation and makes it more usable and, in time, more used. 
In order to ensure that the metadata provided meets the users’ needs, 
publishers of legal information should gather user requirements using the 
techniques highlighted in Pillar 1, Step 1 and, if necessary, update the busi-
ness case (cf. ‘Organisation and policy’, Step 1).

Relevant aspects that publishers of legal information should investigate 
are:

  the reasons users access legal information, such as personal or pro-

fessional reasons;

  the  way(s)  users  access  legal  information,  for  example  whether 
they type keywords into general search engines or reference num-
bers directly on legal information websites;

  what information users are looking for and what obstacles they 
encounter, for example with regard to the identification of relation-
ships between various pieces of legislation or consultation of spe-
cific articles;

(1) OJ C 325, 26.10.2012.
(2) http://publications.europa.eu/mdr/eurovoc/index.html 

58

ELI — Good practices and guidelines  profiles of users, whether they belong to the private or public sec-
tor, whether they are mainly national, international or internal users 
(user studies, website statistics on usage and links to your legislation 
on the web);

  uses of legal information, for example whether users cite a piece 
of legislation, establish cross-references between different types of 
data, reference legal information via social media or develop mobile 
applications;

  expectations users have in terms of the availability and quality of 

legal information;

  types of legal resources that are of interest for end users, includ-

ing legacy contents;

  external information resources to which the published content 

can be connected.

Thanks to the requirements collected, publishers of legal information 
will be able to identify what legal information should be described ac-
cording to ELI-compliant metadata. For example, if users are mainly in-
terested in consulting in-force legislation, an option could be to focus 
on  applying  ELI-compliant  metadata  to  this  collection  first.  Another 
option could be to apply ELI-compliant metadata not only to legisla-
tion, but also to relevant information that helps users to understand 
what the legislation is about, such as summaries of legislation.

59

PART 2: ELI implementation methodologyGood practice 16:
Following a user-centered design taking into 
account type of users

Problem statement 
Publishers  of  legal  information  could  implement  the  ELI  second  pil-
lar without knowing who will use the service and for what purposes. 
Discarding such information increases the risk of implementing a solu-
tion that does not answer the needs of those who will consume legal 
information, therefore reducing its potential for use.

Recommendation
It is recommended that the metadata be defined, taking into account 
both user profiles (such as legal professionals, journalists, academics) 
and  their  requirements,  by  looking  at:  1.  what  metadata  helps  users 
find what they are looking for; 2. for what purposes users want to con-
sult legal information; 3. what formats can help consumers of legal in-
formation to use it further; 4. how often legal information is consulted; 
5. what information users need to understand legal information.

Luxembourg, for example, gathered a list of queries that users would 
like to make, such as: all acts that implement a directive (or an article 
thereof) on a specific date, after deadline or partially; all acts adopted 
by a ministry in a given year, with a specific subject (such as ‘water’); 
acts  based  on  parliamentary  number  or  date  of  signature;  all  acts 
adopted that are based on a particular article of the constitution.

Collecting user requirements greatly helps publishers of legal informa-
tion to better understand what ELI metadata should be implemented. 
For example, if users look for legal information by the legislation num-
ber,  it  is  a  good  idea  to  include  the  metadata  ‘eli:number’.  Similarly, 
if  users  are  interested  in  the  date  of  entry  into  force,  the  metadata 
‘eli:date_entry_into_force’ can help. To then ensure that the metadata 
actually  meets the  identified requirements,  publishers  of legal  infor-
mation should monitor website usage based on predefined metrics   
(cf. Good practices 14 and 15). 

DOs

•  Carry out an in-depth 
investigation of user 
requirements

•  Document user 
requirements in the 
business case

•  Identify key metrics to 
measure whether the 
needs are met 

DON’Ts

BENEFITS  

Quality and reliability
Provides services that meet user requirements

•  Engage in development 
without performing an 
appropriate analysis of 
user requirements

60

ELI — Good practices and guidelines 
STEP 2: Design and publish controlled 
vocabularies and metadata schemas

Designing a metadata schema in line with ELI specifications is a funda-
mental step to enable publishers of legal information to ‘... identify and ex-
change legal information originating from regional and national author- 
ities at the European level’, as explained by the ELI Council conclusions (1).

The design of the metadata schema should begin with the end in mind: 
prepare the publication of ELI metadata in the HTML pages of the pub-
lisher’s website. To do so, the following steps are necessary.

1.  Select from the ELI ontology (2) the properties that will be published in 
the HTML page. The choice depends mainly on the availability of the 
metadata in the publisher’s information system. The set of metadata 
properties may vary depending on the document type. For metadata 
that uses a controlled vocabulary, decide on the controlled vocabulary 
to use. The selection of metadata, the choice of controlled vocabular-
ies, and the naming convention for ELI URIs decided for Pillar 1 form the 
‘ELI application profile’ of the publisher for the purpose of ELI metadata 
publication in HTML pages.

2.   Create the controlled vocabularies that do not already exist, typically 
the list of document types. The ELI annotation tool (3) contains a con-
verter to create the correct file format from Excel spreadsheets.

3.   Make the ELI application profile and controlled vocabularies available. 
A  change-and-release  management  procedure  should  be  set  up  to 
ensure the quality of the publication. Definitions of the ELI application 
profile classes and properties should be translated to ensure they are 
understood by the citizens in the publisher’s own language. Controlled 
vocabularies should be made available in HTML, CSV and RDF/SKOS 
format to ensure their reusability.

4.   Map  the  data  model  already  managed  by  the  publisher  to  the  ELI 
application profile. This prepares the data conversion of the existing 
metadata to the ELI application profile and the publication of ELI meta-
data.  Metadata  that  is  already  managed  by  legal  publishers  may  be 
stored in a content management system, in a specific application or in 
the XML of documents. The publishers should map:

a)  existing  metadata  fields  with  the  corresponding  fields  in  the 
ELI application profile to describe the equivalence between the 
two data models;

(1) OJ C 441, 22.12.2017, pp. 8-12.
(2) http://publications.europa.eu/mdr/eli/documentation/ELI_Ontology-v1.1.htm
(3) http://eur-lex.europa.eu/eli-register/resources.html 

61

PART 2: ELI implementation methodologyb)  values  of  the  metadata  in  the  existing  information  system 
with  their  value  in  the  controlled  vocabularies  selected  or 
created for the ELI publication.

Publishers who already have a metadata schema can implement ELI to 
enrich their internal metadata schema and to publish more ELI meta-
data. These publishers will first modify their annotation process for the 
new legal resources and eventually decide on a process to enrich the 
metadata of their legacy of legal resources.

For publishers who do not have a metadata schema, or have only a 
very  limited  one,  the  implementation  of  ELI  can  be  an  opportunity, 
as the ELI ontology is a state-of-the-art ontology for legal resources. It 
builds on the know-how of European official journals, and is also com-
pliant  with  the  most  recent  bibliographical  metadata  schemas  used 
by libraries for open data catalogue publications (FRBR). Publishers can 
select  the  properties  of  the  ELI  ontology  they  want  to  use,  but  can 
also enrich the ELI metadata model to fulfil their specific needs. The 
resulting metadata schema will be used for the internal management 
of legal metadata.

Further  information  on  the  metadata  specifications  can  be  found  in 
the Documentation (1) section on the Metadata Registry (2) website.

(1) http://publications.europa.eu/mdr/eli/documentation/index.html
(2) http://publications.europa.eu/mdr/eli/index.html

62

ELI — Good practices and guidelinesGood practice 17:
Considering the right level of granularity 
when creating metadata

Problem statement
ELI  metadata  can  describe  legal  acts  at  different  levels  of  granular-
ity, and publishers of legal information can choose to implement the 
metadata they want. For example, it is possible to identify legal infor-
mation at document level using ‘eli:type_document’ or define a more 
granular description. The first approach is easier to follow, because it 
requires  less  metadata  to  be  generated.  However,  generating  more 
granular metadata usually meets user requirements better.

Recommendation
It is recommended that the appropriate level of granularity, in line with 
user requirements and needs, be chosen when creating metadata that 
describes legal information. More granular metadata offers a greater 
variety  of  information  that  can  be  reused,  enabling  greater  levels  of 
technical manipulation. Legal considerations can also come into play: 
legal publishers should refrain from disseminating metadata for which 
they  are  not  totally  sure  they  have  an  accurate  value.  For  example, 
knowing whether or not an act is ‘in force’ is not trivial. It is important 
to strike the right balance between a level of granularity that allows 
publishers of legal information to organise and maintain content in the 
most appropriate way and one that helps consumers of legal informa-
tion to find and reuse what they are looking for.

BENEFITS  

Access to legislation
More functionalities available to access legislation

Interoperability
Further exchange of information allowed

Quality and reliability
More detailed information available

Development of new services

More information is provided and more functionalities 
can be built on top of it

DOs

•  Create sufficient 

metadata at various 
levels of granularity

•  Create sustainable 

metadata for future 
purposes balancing 
the cost of creation and 
maintenance 

DON’Ts

•  Create metadata with 

insufficient details

•  Disseminate inaccurate 

metadata 

63

PART 2: ELI implementation methodology 
Good practice 18:
Structuring information by linking it to other 
documents
Problem statement
Legislation  does  not  exist  in  isolation.  For  example,  there  is  national 
legislation  that  transposes  EU  directives  or  national  legislation  that 
amends  or  repeals  other  national  legislation.  The  ability  to  establish 
the relationship between different pieces of information, such as estab-
lishing the link between basic acts and related amendments, is key for 
supporting a good understanding of the evolution of a given law. If 
publishers of legal information do not take the necessary steps to en-
sure that legal information is linked to relevant data, it is more difficult 
for users to understand, share and reuse legal information.

Recommendation
Publishers of legal information should design the ELI metadata schema 
making  explicit  relationships  between  acts.  Examples  of  relationships 
that can be expressed using the ELI metadata schema include citations, 
amendments,  consolidations,  commencement  and  transposition  of  EU 
law into national laws. ELI metadata helps publishers of legal information 
to make explicit a variety of relationships between legal resources, boost-
ing the analysis that can be carried out on legal information. Examples of 
available ELI metadata include:

  ‘related to’, a generic property defined as a link to ‘a somehow related 

other document, not necessarily a legal resource’;

  ‘consolidates’, defined as a link between a consolidated resource and 

the amendments it incorporates;

  ‘transposes’, defined as a link between a piece of national legislation 

and a transposed EU directive;

  ‘changes’, to indicate legal modifications between two acts, along 
with  more  precise  properties  such  as  ‘repeals’,  ‘amends’  or  ‘com-
mences’.

DOs

Linking information to other documents can also help in developing 
innovative  applications,  for  example  to  create  visualisations  that  en-
able a quick overview of relationships between documents.

•  Reuse vocabularies 
whenever possible, 
as identified in the ELI 
metadata specifications 

BENEFITS  

DON’Ts

•  Miss the opportunity to 
make the links between 
legal resources explicit

64

Access to legislation
Easier identification of the wider context to which legal 
information relates

Interoperability
Improved links and exchange of information

ELI — Good practices and guidelines 
STEP 3: Annotate legal resources 
(automatically or manually)

In this step, publishers of legal information should consider one of the 
following two use cases.

1.  Metadata is available in the information systems of the publisher.

2.  No  metadata,  or  poor  metadata,  is  available  and  the  publisher 
needs to enrich the description of legal resources to implement ELI.

In the first case, the publisher will have to carry out data conversion 
from the existing metadata to the ELI metadata. To do so the publisher 
should make sure the following elements are available.

  Mappings between existing metadata schemas and the ELI ontol-

ogy elements used as part of the ELI application profile.

  Mappings  between  existing  metadata  values  and  values  of  the 
controlled vocabularies used as part of the ELI application profile.

  Data conversion rules that might be needed.
If all the above is available, the work of the publisher will be to prepare 
the scripts which will execute the data conversion. The output of the 
scripts will be used to add RDFa tags in web pages. The XML serialisa-
tion of ELI (1) and the associated conversion stylesheet can help at this 
stage.

In the second case, the publisher will have to create metadata. Meta-
data can be created manually (the choice of the large majority of ELI 
implementers in this situation) or (semi-)automatically. The ELI annota-
tion tool (2) allows ELI notices of legal resources to be manually created.

The publisher can add metadata during the editorial process of legisla-
tion. At the end of the editorial process a last step should allow veri-
fication and enrichment of this metadata. Legal resources will be an-
notated with this metadata. The ELI validator (3) can help in validating 
the final ELI metadata inserted in the HTML pages.

The automatic process of creating metadata can be used for some of 
the metadata, and most often to enrich the metadata of the legacy 
contents. In such cases, manual work is necessary to detect and correct 
any errors generated during the metadata extraction process.

(1) http://publications.europa.eu/mdr/resource/eli/eli_xml/ 
(2) http://eur-lex.europa.eu/eli-register/resources.html
(3) http://publications.europa.eu/eli-validator/ 

65

PART 2: ELI implementation methodologyGood practice 19:
Creating metadata as part of the workflow, 
including validation services
Problem statement 
When metadata that describes legal information is created manually 
after legislation is published online, publishers of legal information run 
the risk of causing errors and incoherencies because manually created 
metadata tends to be less accurate, especially in the absence of valida-
tion services.

Recommendation
Now that legal information is increasingly available in digital form, pub-
lishers of legal information have the opportunity to apply metadata at 
the time of creation as part of the workflow and in a semi-automated 
way.  This  approach  ensures  that  metadata  can  be  used  throughout 
the  publishing  process,  enabling  publishers  of  legal  information  to 
concentrate human intervention where it matters. The machine-gen-
erated metadata will typically include information that can be gleaned 
from  the  document  structure  or  process  stage  (e.g.  title,  identifiers, 
dates, author). The human involvement can then focus on adding in-
formation that it is not possible to extract automatically from the docu-
ment (e.g. subject classifications, links to other legal information) and 
on carrying out quality controls. Validation can also be incorporated 
into the automated tools, including spell checks, numbering, consist-
ency of numbering and link checking.

To support the quality control of the publishing process, an ELI meta-
data validation tool is available (1) to validate the compliance of RDFa 
annotations with the ELI ontology.

BENEFITS  

Quality and reliability
Increased reliability of the workflow by minimising 
human intervention to a few selected tasks

Development of new services
Ability to reuse the process for different information 
workflows

Savings
Balanced approach between automatic and manual 
intervention when attributing metadata, which leads to: 
effectiveness; decreased error rate; increased reliability of 
the process as a whole

DOs

•  Deploy workflow tools 
that capture metadata 
along the way

•  Automate validation as 
much as possible

•  Ensure that content 
specialists focus on 
carrying out intellectual 
analysis and quality 
assurance

•  Rely on ELI tools: ELI/
XML, ELI validator, ELI 
annotation tool 

DON’Ts

•  Keep metadata for 
internal use only

•  Generate metadata 
at the end of the 
publishing process

•  Attribute all metadata in 
a manual way

66

(1) http://publications.europa.eu/eli-validator/ 

ELI — Good practices and guidelines 
Good practice 20:
Generating standard metadata formats
Problem statement
Metadata is key to ensuring that legal information can be accessed and 
reused across information systems. Describing legal information with 
metadata allows it to be understood by both humans and machines in 
ways that promote interoperability. However, such potential for inter- 
operability  may  be  hampered  in  the  absence  of  standard  metadata, 
because only a few will know the meaning of the customised meta-
data and others will find it difficult to understand and process it.

Recommendation
It is recommended that ELI-compliant metadata schemas be used to 
ensure greater accessibility and interoperability  across  legal  informa-
tion systems as well as greater effectiveness of the publication process.

The creation of formal metadata through adherence to ELI metadata 
is essential for managing and sharing legal information. ELI metadata 
enables interoperability among legal information systems that use the 
same metadata standards, greatly enhancing the exchange of legal in-
formation.  To  ensure  interoperability,  publishers  of  legal  information 
should  use  consistent  ontologies  throughout  the  legal  information 
and metadata should use the same terms for describing legal informa-
tion.

The ELI metadata can be accessed via the Publications Office’s Meta-
data Registry website: http://publications.europa.eu/mdr/eli.

BENEFITS  

Access to legislation
Facilitates search criteria for search engines

Interoperability
Allows the exchange of information in a standard way

Development of new services
Facilitates the development of added-value services

Savings 
Increased degree of automation for querying, accessing 
and exchanging information

DOs

•  Use ELI-compliant 
metadata scheme 
to describe legal 
information

•  Make available 

metadata for reuse 

DON’Ts

•  Use custom-made 
metadata while the 
same is available in ELI

67

PART 2: ELI implementation methodology 
Pillar 3: 
How to render ELI 
metadata machine-
reusable

PART 2: ELI implementation methodology

STEP 1: Add RDFa tags to web pages to 
facilitate parsing and extraction

If  publishers  of  legal  information  already  publish  legal  information  on 
web pages using HTML or create new web pages, there is a preliminary 
step  that  they  are  recommended  to  take  before  adding  machine-
readable markups.

This step entails ensuring that the web pages are compliant with stand-
ard syntax conventions so as to facilitate metadata parsing and extrac-
tion.  In  fact,  if  publishers  of  legal  information  add  microdata  or  RDFa 
without ensuring  that web  pages are compliant with standard  syntax 
convention, they make it more difficult for consumers of legal informa-
tion to extract and parse the metadata.

The  standard  syntax  conventions  that  publishers  of  legal  information 
are invited to use for their web pages are XHTML (eXtensible HyperText 
Markup Language) (1) or HTML5 (2).

Once the web pages are compliant with these standard syntaxes, the 
next step entails serialising the metadata so as to make it machine read-
able, annotating the HTML pages with RDFa (3) markup.

An ELI annotation tool is available (4) to manually create RDFa-enriched 
HTML pages after filling in a form with fields corresponding to the ELI 
ontology.

An ELI RDFa validation tool is available (5) to help publishers of legal infor-
mation ensure the validity and correctness of the published legislation.

(1) http://www.w3.org/TR/xhtml1
(2) http://www.w3.org/TR/html5
(3) http://www.w3.org/TR/ 
(4) http://eur-lex.europa.eu/eli-register/resources.html 
(5) http://publications.europa.eu/eli-validator/ 

69

 
Good practice 21:
Annotating legal information with RDFa markup
Problem statement 
When selecting metadata formats to describe legal information, publish-
ers of legal information have many options to choose from. How publish-
ers choose to represent metadata is a primary factor in someone else’s abil-
ity to use it in the future. Thus it is important to think carefully about what 
format will be best for managing, sharing and preserving the metadata.

Recommendation
In order to promote the reuse of metadata, publishers of legal information 
should make it available in a non-proprietary format. To enable further use, 
legal information should be annotated with RDFa markups.

Here are some examples of how metadata published in RDFa format can 
make legal information more discoverable and usable.

  Metadata (e.g. title, author, publication date, description, type of docu-
ment)  can  be  read  as  structured  data  and  transferred,  categorised, 
sorted, etc.

  Metadata can be read and harvested by tools.
  The meaning of the harvested metadata is preserved.

In order to make legal information reusable, metadata should be accurate 
and  up  to  date.  Publishers  of  legal  information  should  ensure  that  legal 
information is annotated with quality metadata. 

Example: In the context of transposition of EU legislation, ELI metadata 
of legal resources published in RDFa by national public administrations 
can  be  automatically  harvested  by  the  Commission,  which  makes  the 
transposition notification mechanism more efficient. This is a concrete 
example of the smart use of technology in line with the objectives of 
the better regulation guidelines, since it helps the Commission monitor 
the efforts of the Member States to ensure their legislation is in line with 
EU law.

DOs

•  Use RDFa as the open 
machine-readable 
standard format  

BENEFITS  

Transparency

More legal information available in a standard way

Interoperability

Improved access and exchange of information through 
standard formats

Savings 

DON’Ts

Increased degree of automation for querying, accessing 
and exchanging information

•  Use proprietary formats 
70

ELI — Good practices and guidelines 
Good practice 22:
Dealing with legacy content
Problem statement
Legacy content is often only available in the form of static files such 
as Microsoft Word documents or PDFs, which makes it a challenge to 
process and publish metadata that conforms to ELI. Publishers of legal 
information have to identify a minimum set of ELI ontology elements 
to describe the legacy content and find ways to process it, transform it 
into structured content, annotate it and publish it.

Recommendation
It is recommended that a set of elements be identified in the ELI ontol-
ogy that can be extracted from the legacy content. For example, the 
elements relating to the type of document, date of signature, date of 
publication and language can be used to design ELI URI patterns. Fur-
ther elements of the ELI ontology that could enrich legacy content are 
the title, the subject of the document, description, etc.

The processing of legacy content depends on several factors, such as 
what metadata can be extracted and processed, language constraints, 
and  the  cost  and  availability  of  manual  work.  The  publishers  of  legal 
information can choose to process legacy content manually or to auto-
mate the work to extract metadata values from legacy content. Manual 
data cleansing should be provided to increase the quality of the meta-
data extracted automatically. The ELI annotation tool (1) can help in the 
manual metadata-creation process.

BENEFITS  

Improved data quality, by ensuring that legislation is 
made available in a structured way

Increased accessibility, by making legacy content 
available in a structured way

Increased interoperability, by making the legacy content 
available in a machine-readable format that respects the 
ELI ontology

(1) http://eur-lex.europa.eu/eli-register/resources.html

DOs

•  Enrich legacy content 
with a set of metadata 
that can be used by 
local information 
systems as well as to 
publish ELI metadata

•  Make legacy content 

available in a machine-
readable format 

DON’Ts

•  Publish legacy content 
without descriptive 
metadata

71

PART 2: ELI implementation methodology 
PART 3:

Beyond the ELI pillars

73

PART 3: Beyond the ELI pillarsELI is one approach to enhancing the discoverability and reuse of legal 
information. It is an easy first step into publishing legislative metadata 
on the web of data. Other actions can, however, be taken beyond ELI to 
make data more easily reusable, or to consider ELI as a starting point to 
improve the internal publishing workflow.

Align metadata values with other  
vocabularies (Eurovoc)

Alignment of local controlled vocabularies (e.g. local thematic controlled 
vocabulary, types of documents, etc.) as part of an ELI application profile 
to EU controlled vocabularies (e.g. Eurovoc (1)) will increase the potential 
for interoperability between publishers of legislation.

In particular, alignment of legal subjects on a common controlled vo-
cabulary will allow a subject-based cross-national search of legislation.

Tools such as the ones listed below provide the necessary functionalities 
to create and publish mappings between controlled vocabularies.

  SILK: a tutorial on the use of SILK to align controlled vocabularies is avail-

able on Joinup (2).

  Semantic Interoperability Community (3) and mapping.semic.eu.

  OnaGUI — Ontology Alignment Graphical User Interface (4). 

Use other metadata dissemination channels

ELI mandates the use of RDFa as dissemination syntax. RDFa is a good 
choice from a publisher’s point of view because it relies on the existing 
web portal infrastructure and is relatively easy to implement. However, 
this publishing technique requires data consumers to crawl and parse 
all HTML pages to get the full set of ELI metadata from a given portal. 
Other dissemination techniques can be used to facilitate the reuse of 
metadata.

  Content negotiation through the ELI URI, returning RDF files, while 
not allowing the data to be retrieved as a complete set, relieves the 
data consumers from parsing RDFa markup.

  Releasing RDF bulk files containing the full set — or large subsets 
— of ELI metadata allows data consumers to instantly get the full 
metadata content. However, this does not provide the most recent 
updates to the metadata.

(1) http://eurovoc.europa.eu/drupal/ 
(2) https://joinup.ec.europa.eu/document/tutorial-use-silk-aligning-controlled-
vocabularies 
(3) http://semic.eu 
(4) https://github.com/ 

74

ELI — Good practices and guidelines  Publishing the data using an API with proper documentation allows 
data consumers to retrieve the subset of the data they are interest-
ed in. This is usually a very large project, requiring a lot of resources 
and with other impacts on the information system. Publishers need 
to do the following.

•  Create a web application capable of rendering machine-readable 
metadata for legislation that should conform to the ELI-compli-
ant metadata schema. In particular, they should make sure that 
the data is not locked into a proprietary API data model, but fol-
lows  the  principles  of  linked  data  and  the  ELI  data  model.  The 
JSON-LD syntax (1) provides a good way to create API based on 
JSON and still linked-data compatible.

•  Publish  API  documentation.  An  example  of  such  documenta-
tion is the one provided by the Publications Office, which can be 
found at http://data.europa.eu/eli.

  Opening the data in a SPARQL endpoint (2) is an alternative to creat-
ing an API. This is closer to the original ELI metadata work since it 
does not require that a new data model or the inputs and outputs 
of the API be specified.

Use ELI as an opportunity to improve  
publishing workflows

ELI  focuses  on  the  metadata  description  and  the  dissemination  of 
legislation.  Experience  has  shown  that,  while  an  ELI  implementation 
project is progressing, it raises fundamental questions on the way the 
legislation is published.

   Why is metadata unavailable? How could they be made available?

  Why is it hard to have representations of the documents (PDF, HTML, 
XML)? Can the internal format of legislative document be enhanced?

  What are the impacts of ELI in terms of user navigation on the website?

  Could additional search facets or search criteria be proposed to search 

legislation on the website?

The use of Akoma Ntoso as an XML representation format for the docu-
ments  can  help  streamline  the  workflow.  Such  an  XML  schema  can 
store metadata in the document header, and the ELI/XML schema (3) 
can be integrated in an Akoma Ntoso proprietary metadata field.

The improvement of metadata quality, or the addition of new meta-
data fields, can be ‘side projects’ next to ELI implementation in order to 

(1) https://www.w3.org/TR/json-ld/ 
(2) https://www.w3.org/TR/sparql11-protocol/ 
(3) http://publications.europa.eu/mdr/resource/eli/eli_xml/ 

75

PART 3: Beyond the ELI pillarsimprove the overall quality of disseminated metadata. In particular, the 
legal subject (‘eli:is_about’) is an important item of metadata to enable 
a future subject-based cross-national legislation search. The creation of 
metadata can also be pushed early in the creation workflow, with the 
legislation subjects typically being set as soon as the draft legislation 
is written.

Working on metadata can also be an opportunity to consider metadata 
as first-class citizens in the publishing workflow, typically by storing and 
managing  them  in  a  central,  dedicated  database.  This  is  the  dissem-
ination architecture used by the Cellar at the Publications Office, or by 
Casemates in Luxembourg. The central database stores metadata and 
document representations and is regarded as the master storage point 
on which other business applications can rely to search legislation, to 
search values in controlled lists or to display a document.

Make your legislation more visible for web 
search engines

Major search engines consume structured data from the web. How-
ever, they cannot read any structured metadata. They understand only 
information  structured  according  to  the  schema.org  (1)  vocabulary. 
The schema.org vocabulary, until recently, did not contain any specific 
classes or properties to describe legislation.

ELI’s goal is to improve legislation discovery and interoperability, not 
only at European scale for technology-aware data consumers, but also 
at web scale for the average internet user. This is why the ELI Taskforce 
has proposed an extension to the schema.org (2) vocabulary for web 
search engines to be able to read structured metadata about legisla-
tion. This extension is derived from the ELI ontology and includes in 
schema.org the ELI properties that are not already included in the core 
vocabulary.

The long-term typical use case of this extension is that a search engine 
would be capable of showing on a search-result page whether or not 
a piece of legislation is in force, and/or give the choice to a user to read 
the latest consolidated version or the original version.

To improve the discoverability of your legislation HTML pages you might 
want to include in them structured data markup using the schema.org 
vocabulary. Note that this means that the HTML pages would contain 
both ELI structured metadata and schema.org metadata. However, this 
gives no guarantee that the search engines will actually read the meta-
data, or do anything useful with it.

(1) http://schema.org 
(2) http://schema.org/Legislation 

76

ELI — Good practices and guidelinesANNEXES

77

ANNEXESTERM

Act

Akoma Ntoso

Amendment

Availability

ANNEX I: Glossary

EXPLANATION

A law enacted by a parliament or similar legislative body.

Akoma Ntoso is an initiative managed by the United Nations Department of 
Economic and Social Affairs (Undesa), Division for Public Administration and 
Development Management (DPADM) and the University of Bologna.

Akoma Ntoso defines a ‘machine-readable’ set of simple technology-neutral 
electronic representations (in XML format) of parliamentary, legislative 
and judiciary documents. The objective is to provide a framework for the 
exchange of ‘machine-readable’ parliamentary, legislative and judiciary 
documents.

Akoma Ntoso XML schemas make ‘visible’ the structure and semantic 
components of relevant digital documents so as to support the creation 
of high-value information services to deliver the power of ICTs to increase 
efficiency and accountability in the parliamentary, legislative and judiciary 
contexts.

(Source: http://www.akomantoso.org)

An effect that changes the text of legislation.

Availability is the extent to which the data can be accessed. This also includes 
the long-term persistence of data.

(Source: https://joinup.ec.europa.eu/community/ods/description)

Chapter

A numbered level of division within an act or other legislation.

‘Coming into force’ date

The date on which a legislative provision or an effect comes into force.

Consistency

Consistency is the extent to which the data does not contain contradictions 
that would make its use difficult or impossible.

(Source: Open Data Support)

Consolidation

Consolidation consists of the integration in a legal act of its successive 
amendments and corrigenda.

(Source: http://eur-lex.europa.eu/content/help/faq/intro.html#top)

Content negotiation is a mechanism of the HTTP protocol by which different 
documents (or ‘representations’) can be returned for the same URI. This is 
typically used to return a page in the language of the client for the same URL, 
or, in the context of the web of data, to return either a human-readable page 
or a machine-readable data file about the same URI.

Almost any interesting use of data will combine data from different sources. 
To do this it is necessary to ensure that the different datasets are compatible: 
they must use the same names for the same objects, the same units or co-
ordinates, etc. If the data quality is good this process of data integration may 
be straightforward but if not it is likely to be arduous. A key aim of linked data 
is to make data integration fully or nearly fully automatic. Non-open data 
is a barrier to data integration, as obtaining the data and establishing the 
necessary permission to use it is time-consuming and must be done afresh for 
each dataset.

(Source: http://opendatahandbook.org/glossary/en/terms/data-integration)

Content negotiation

Data integration

78

ELI — Good practices and guidelinesDatabase

Dataset

(i) Any organised collection of data may be considered a database. In this 
sense the word is synonymous with dataset.

(ii) A software system for processing and managing data, including features 
to extend or update, transform and query the data. Examples are the open 
source PostgreSQL, and the proprietary Microsoft Access.

(Source: http://opendatahandbook.org/glossary/en/terms/database)

Any organised collection of data. ‘Dataset’ is a flexible term and may refer to 
an entire database, a spreadsheet or other data file, or a related collection of 
data resources.

(Source: http://opendatahandbook.org/glossary/en/terms/dataset)

Dereferencing

The act of retrieving a representation of a resource identified by a URI.

Discoverability

Division

Dublin Core

Effect

Extent

Five stars of open data

(Source: http://www.w3.org/)

It is not enough for open data to be published if potential users cannot find it, or 
even do not know that it exists. Rather than simply publishing data haphazardly 
on websites, governments and other large data publishers can help make their 
datasets discoverable by indexing them in catalogues or data portals.

(Source: http://opendatahandbook.org/glossary/en/terms/discoverable)

A term we use to denote any one of the hierarchical levels into which a piece 
of legislation may be divided.

The Dublin Core Metadata Initiative, or ‘DCMI’, is an open organisation 
supporting innovation in metadata design and best practices across the 
metadata ecology. DCMI’s activities include work on architecture and 
modelling, discussions and collaborative work in DCMI communities and DCMI 
task groups, global conferences, meetings and workshops, and educational 
efforts to promote widespread acceptance of metadata standards and best 
practices.

DCMI maintains a number of formal and informal liaisons and relationships 
with standards bodies and other metadata organisations.

Dublin Core is the common name for a generic set of metadata elements 
that were originally conceived as a simple mechanism to describe physical or 
digital resources, but developed into one of the main metadata standards for 
the semantic web.

(Source: http://dublincore.org)

Any impact that one legislative provision may have on another. The most 
familiar type of effect is an amendment that changes the text of the affected 
legislation, but there are also types of effect that do not change the text, such 
as where a provision is said to be ‘modified’ or ‘applied’.

The term ‘extent’ when used in legislation refers to the jurisdiction(s) for 
which it is law.

A rating system for open data proposed by Tim Berners-Lee, founder of the 
World Wide Web. To score the maximum five stars, data must (1) be available 
on the web under an open licence, (2) be in the form of structured data, (3) be 
in a non-proprietary file format, (4) use URIs as its identifiers (see also RDF), 
(5) include links to other data sources (see linked data). To score three stars, it 
must satisfy all of (1)-(3), etc. The open definition requires data to score three 
stars in order to qualify as open, not requiring RDF or linking. This permits 
data of a wider variety of types and sources to be open, without the work of 
creating linking information.

(Source: http://opendatahandbook.org/glossary/en/terms/five-stars-of-
open-data)

79

ANNEXES‘Hierarchy’ and ‘hierarchical structure’ are terms we use to denote the levels of 
division within a piece of legislation and the relationship between them. For 
example, the level of a cross-heading in an act comes below the part level in 
the hierarchy, but above the section level.

Data in a format that can be conveniently read by a human. Some human-
readable formats, such as PDF, are not machine-readable as they are not 
structured data, i.e. the representation of the data on disk does not represent 
the actual relationships present in the data.

(Source: http://opendatahandbook.org/glossary/en/terms/human-readable)

The name of an object or concept in a database. An identifier may be the 
object’s actual name (e.g. ‘London’ or ‘W1 1AA’, a London postcode) or a word 
describing the concept (‘population’) or an arbitrary identifier such as ‘XY123’ 
that makes sense only in the context of the particular dataset. Careful choice 
of identifiers using relevant standards can facilitate data integration.

(Source: http://opendatahandbook.org/glossary/en/terms/identifier)

Interoperability, within the context of European public service delivery, is the 
ability of disparate and diverse organisations to interact towards mutually 
beneficial and agreed common goals, involving the sharing of information 
and knowledge between the organisations, through the business processes 
they support, by means of the exchange of data between their respective ICT 
systems. 

(Source: http://ec.europa.eu/isa/documents/eif_brochure_2011.pdf)

The generic term for laws of any type. The terms ‘piece of legislation’ and 
‘item of legislation’ are used within this guide to mean a whole legislative 
document of any type, for example an act or statutory instrument.

Linked data is a set of design principles for sharing machine-readable data on 
the web for use by public administrations, businesses and citizens.

(Source: Open Data Support)

Acts and measures have two titles, the ‘short title’ and the ‘long title’. The 
‘long title’ sets out the purposes of the act, sometimes at great length, 
whereas the ‘short title’ is a more convenient short form by which the act will 
usually be known. For example, the Petroleum Act 1998 (short title) has a long 
title that reads:

‘An Act to consolidate certain enactments about petroleum, offshore 
installations and submarine pipelines.’

Metadata is structured information that describes, explains, locates or 
otherwise makes it easier to retrieve, use or manage an information resource. 
Metadata is often called ‘data about data’.

(Sources: National information, standards organisation)

Data in a data format that can be automatically read and processed by a 
computer, such as CSV, JSON, XML, etc. Machine-readable data must be 
structured data. Compare human-readable.

(Source: http://opendatahandbook.org/glossary/en/terms/machine-readable)

Hierarchy

Human-readable

Identifier

Interoperability

Legislation

Linked data

Long title

Metadata

Machine-readable

80

ELI — Good practices and guidelinesOCR

Open data

Open format

Optical character recognition (OCR) is the mechanical or electronic conversion 
of images of typewritten or printed text into machine-encoded text. It is 
widely used as a form of data entry from printed paper data records, whether 
passport documents, invoices, bank statements, computerised receipts, 
business cards, mail, printouts of static data or any suitable documentation.  
It is a common method of digitising printed texts so that it can be 
electronically edited, searched, stored more compactly, displayed online  
and used in machine processes such as machine translation, text-to-speech, 
key data and text mining.

Open data is data that can be freely used, reused and redistributed  
by anyone — subject only, at most, to the requirement to attribute and  
share alike.

(Source: Opendefinition.org)

A file format whose structure is set out in agreed standards, overseen and 
published by a non-commercial expert body. A file in an open format enjoys 
the guarantee that it can be correctly read by a range of different software 
programs or used to pass information between them. Compare proprietary.

(Source: http://opendatahandbook.org/glossary/en/terms/open-format)

Original ‘Basic act’ or  
‘As enacted’ or ‘As made’

The original version of the legislation as it stood when it was initially adopted. 
No changes have been applied to the text.

Paragraph

Part

Preamble

Primary legislation

Processability

Proprietary

A provision, usually numbered, constituting the lowest level of division in a 
schedule. (But note that the term ‘paragraph’ may also be used in legislation 
to denote certain levels of subdivision within a provision.)

A division of the main body or a schedule in an item of legislation, usually 
forming part of a numbered sequence of parts.

A part may be further subdivided hierarchically into chapters, cross-headings 
and numbered sections (or paragraphs, if in a schedule).

Words appearing near the beginning of an act after the long title, stating the 
reasons for passing the act. The use of preambles is optional and they are now 
rare. Any preamble would appear in the introductory text.

General term used to describe the main laws passed by the legislative bodies. 
It is to be distinguished from secondary legislation.

The processability of data is the extent to which it can be understood and 
handled by automated processes.

(Source: Open Data Support)

(i) Proprietary software is owned by a company which restricts the ways in 
which it can be used. Users normally need to pay to use the software, cannot 
read or modify the source code, and cannot copy the software or resell it as 
part of their own product. Common examples include Microsoft Excel and 
Adobe Acrobat. Non-proprietary software is usually open source.

(ii) A proprietary file format is one that a company owns and controls.  
Data in this format may need proprietary software to be read reliably. 
Unlike an open format, the description of the format may be confidential or 
unpublished, and can be changed by the company at any time. Proprietary 
software usually reads and saves data in its own proprietary format. For 
example, different versions of Microsoft Excel use the proprietary XLS and 
XLSX formats.

(Source: http://opendatahandbook.org/glossary/en/terms/proprietary)

81

ANNEXESProvision

The term ‘provision’ is used to describe a definable element in a piece 
of legislation that has legislative effect. Most commonly in the help 
documentation and messages on this site it will be used to refer to a section 
(or corresponding element such as a paragraph in a schedule or an article in an 
order) but it can also refer to higher-level divisions such as parts or chapters.

Public sector information

Information collected or controlled by the public sector. 

(Source: http://opendatahandbook.org/glossary/en/terms/public-sector-
information)

Resource description framework (RDF) is a model and a set of syntaxes for 
sharing data in the web.

The basic concepts of RDF are described in the W3C recommendation ‘RDF 1.1 
Concepts and Abstract Syntax’.

(Source: http://www.w3.org/TR/rdf11-concepts)

A primer, aimed to convey basic knowledge required to effectively use RDF, is 
published by W3C under the title ‘RDF 1.1 Primer’.

(Source: http://www.w3.org/TR/rdf11-primer)

Specific syntaxes for the expression of RDF are given in the documents ‘RDF 
1.1 XML Syntax’ and ‘RDF 1.1 Turtle’, both published by W3C.

While RDF is increasingly being used for the description of resources on the 
web, there are no easy ways to check validity of RDF data against specified 
patterns, the way that XML can be validated not just for valid syntax but 
also for conformity to application-specific rules. The W3C Working Group 
‘RDF Data Shapes’ has been established with the mission ‘to produce a W3C 
Recommendation for describing structural constraints and validate RDF 
instance data against those’.

(Source: http://www.w3.org/2014/data-shapes)

Resource description framework in attributes (RDFa) is a way of expressing 
RDF-style relationships using simple attributes in existing markup languages 
such as HTML.

RDFa provides a mechanism to include data structured in RDF in HTML 
pages, providing a set of markup attributes that enable machine-readable 
information to be embedded in web pages.

The formal specification is contained in the document ‘RDFa Core 1.1 — Third 
Edition’, while the approach is explained in the ‘RDFa 1.1 Primer — Third 
Edition’. A dedicated website that outlines the objectives and the benefits of 
RDFa and provides pointers to informational materials and an index of tools is 
available at rdfa.info.

(Source: http://www.w3.org/TR/rdfa-syntax)

The RDF/XML serialisation is one of the possible ways of serialising RDF data, 
using an XML syntax (see also ‘Turtle’).

We use the terms ‘revise’, ‘revised’ and ‘revision’ to refer to the editorial 
process of incorporating amendments and carrying through other effects into 
legislation.

A provision, usually numbered, constituting the lowest level of division in the 
main body of an act or other primary legislation.

Serialisation is the process of translating data structures or object state into 
a format that can be stored (for example, in a file, or transmitted across a 
network connection link) and reconstructed later in the same or another 
computer environment.

RDF

RDFa

RDF/XML

Revised legislation

Section

Serialisation

82

ELI — Good practices and guidelinesShort title

Standard

Statute

Statute book

The title by which an act or measure is usually known. It is to be distinguished 
from the long title, which sets out the purposes of the legislation.

A published specification for, e.g., the structure of a particular file format, 
recommended nomenclature to use in a particular domain, a common set of 
metadata fields, etc. Conforming to relevant standards greatly increases the 
value of published data by improving machine readability and easing data 
integration.

(Source: http://opendatahandbook.org/glossary/en/terms/standard)

An item of primary legislation, such as an act or measure.

A term we use to denote the totality of the statute law in force at any 
particular time.

Statutory instrument

A type of secondary legislation made under authority contained in acts of 
parliament.

SPARQL

Turtle

URI

URL

URN

Version

SPARQL is a language to query RDF data. It is to RDF data what SQL is to 
relational databases. An overview of the main aspect of SPARQL is contained 
in the document ‘SPARQL 1.1 Overview’. The formal specification is defined in 
the document ‘SPARQL 1.1 Query Language’.

(Source: Open Data Support)

Turtle is one of the possible ways to serialise RDF data, using a text syntax. 
This is usually more compact and readable than RDF/XML.

A uniform resource identifier (URI) is a compact sequence of characters 
that identifies an abstract or physical resource. URI enables interaction with 
representations of the resource over a network, typically the World Wide Web, 
using specific protocols.

A URI can be composed of:

URL: uniform resource locator

URN: uniform resource name.

The most common form of URI is the URL, but it can also be found as a URN 
or as a combination of both. This last option is the one that provides URI with 
more consistent characteristics for the identification of resources.

(Source: ISA’s 10 rules for persistent identifiers)

Uniform resource locator. It can be defined as a URI that provides the means 
to access a web resource. URLs occur most commonly to reference web pages 
(http), but can also have a role in file transfer (ftp), email (mailto) or even 
database access (JDBC).

Uniform resource name. It is the historical name for a uniform resource 
identifier (URI) that uses the urn scheme.

1. ‘Version’ may refer to the ‘as enacted’ version of the legislation or the ‘latest 
available (revised)’ version.

2. ‘Version’ is also used in the context of revised legislation to refer to one of 
any number of versions of a provision (or higher level of division of legislation) 
that may exist in any number of different versions, usually created as a result 
of amendments made to it.

83

ANNEXESANNEX II: ELI ontology

The latest version of the ELI ontology can be found on the Metadata 
Registry website (1).

(1) http://publications.europa.eu/mdr/eli/index.html

84

ELI — Good practices and guidelinesANNEX III: Self-
assessment check list

The following check list allows decision-makers to perform a self-assess-
ment of their solution for publishing legislation, from an ELI perspective.

STEP

QUESTION

YES

NO

N/A

Organisation and policy
1
2
3
4
5

Have you identified your business case? (1)
Have you estimated the resources for the implementation of the ELI pillars? (2)
Have you set up a governance structure? (3)
Have you set up an ELI implementation project? (4)
Have you formulated a URI and metadata policy? (5)

Pillar 1 — Identification of legislation
1
2
3

Have you captured requirements relevant for HTTP URIs?
Have you designed URI templates? (6)
Have you configured the web server for ELI URI resolution? (7)

Pillar 2 — ELI metadata
1
2
3
4

Have you captured requirements relevant for metadata? (8)
Have you designed the metadata schema? (9)
Have you developed the metadata publishing routines? (10)
Have you published the metadata? (11)

Pillar 3 — Render the ELI metadata machine-reusable
1
2

Have you adapted the web pages to facilitate parsing and extraction? 
Have you provided the metadata in a machine-readable format?

o
o
o
o
o

o
o
o

o
o
o
o

o
o

o
o
o
o
o

o
o
o

o
o
o
o

o
o

o
o
o
o
o

o
o
o

o
o
o
o

o
o

(1) Good practice 1: Building on the knowledge, experience and tools of others (support by the ELI Taskforce)
(2) Good practice 2: Estimating implementation costs
(3) Good practice 3: Setting up a central organisation as a national coordination point for ELI implementation
(4) Good practice 4: Structuring your implementation project
(5) Good practice 5: Writing a policy document providing guarantees for long-term persistence
(6) Good practices 6: Designing URI template(s) to stay as close as possible to existing citation practice;  
Good practice 7: Modelling HTTP URIs by treating each piece of legislation as a unique resource; Good practice 8: Taking into 
account the concepts of the ELI ontology: legal resource, legal expression and format; Good practice 9: Considering the right 
level of granularity when identifying legislation; Good practice 10: Following common good practices for HTTP URIs;  
Good practice 11: Testing URIs against real data.
(7) Good practice 12: Using content negotiation and/or identifiers for language and format variants; Good practice 13: Providing 
service-level guarantees; Good practice 14: Monitoring website usage and links to legislation on the web through statistics; 
Good practice 15: Monitoring service levels and persistence of URIs; Good practice 16: Following a user-centered design taking 
into account type of users 
(8) Good practice 17: Considering the right level of granularity when creating metadata
(9) Good practice 18: Structuring information by linking it to other documents; Good practice 19: Creating metadata as part 
of the workflow, including validation services; Good practice 20: Generating standard metadata formats
(10) Good practice 21: Annotating legal information with RDFa markup
(11) Good practice 22: Dealing with legacy content

85

ANNEXESO
A
-
0
4
-
1
7
-
1
3
0
-
E
N

-

N

ISBN  978-92-78-41429-0