A workshop for GLEIF @ Frankfurt - Germany

1. LEI.INFO & The Ideas for
LEI System
A workshop for GLEIF by MakoLab SA

2. Motivation
 Enhance the LEI infrastructure by using
SEMANTIC TECHNOLOGIES
 Popularise LEI by adding it to schema.org
 Explore radically new possibilities for LEI System
technological foundations
2

3. Workshop plan
 MakoLab – who we are?
 LEI Resolver
• Public LEI Search Engine and Linked Data Resolver
• Private LEI Based Solutions
 LEI in schema.org
 GLEIO Ontology
• What’s “wrong” with XML data model
• Current LEVEL 1 Ontology
• Plans and discussion about the inclusion of LEVEL 2 concepts
 Using Blockchain for identity services and LEI
• MakoLab’s Proof-of-Concept
• Discussion of Potential BlockChain Proof-of-Concept for GLEIF
3

4. Bringing Semantic Web
Technologies to LEI System
 LEI Search Engine and Linked Data Resolver
 LEI in schema.org
 GLEIO Ontology

5. What is MakoLab LEI Resolver ?
 MakoLab LEI Resolver is the
combination of LEI Search Engine
and Linked Data URI Resolver.
 Linked Data URI Resolver is a web
based software solution that performs
dereference of an URI by returning
the representation of the resource
that it identifies
5

6. MakoLab LEI Resolver – how does it work?
5493001KJTIIGC8Y1R12
Create URI
http://lei.info/5493001KJTIIGC8Y1R12
Visual for Human Web Media (HTML)
Data for Machine consumption (RDF)
Picture for Paper Media (QR-Code)
1
2 http://lei.info/5493001KJTIIGC8Y1R12
6

7. URI Creation – MakoLab LEI Web Application
Few technological details:
TripleStore – AllegroGraph
Application Layer – Highly
Scalable .NET Web app.
Romantic Web (SW)
components
1
7

8. LEI Resolver – Visual Resolution
http://lei.info/5493001KJTIIGC8Y1R12 Visual for Human Web Media (HTML)
2
8

9. LEI Resolver – Data for machine consumption
http://lei.info/5493001KJTIIGC8Y1R12 Data for Machine consumption (RDF)
RDF Graphs can be returned
in multiple formats:
2
9

10. LEI Resolver – Meeting Linked Data Standards
http://en.lodlive.it/?http://lei.info/5493001KJTIIGC8Y1R12
http://lei.info/5493001KJTIIGC8Y1R12 Data for Machine consumption (RDF)
2
10

11. LEI Resolver – Meeting Linked Data Standards
Sophisticated Querying Mechanism
SPARQL END POINT
Allows for building third party applications
n top of the resolver
http://lei.info/sparql
11

12. Private LEI Resolvers
 Can be deployed to company Intranets
 Can be totally isolated from Internet
 Can be integrated with ANY corporate
source – if the source exposes Web API
 Precursor to Level 2
 Demo integrations: CorpWatch,
Bloomberg Symbology, dbPedia,
Freebase
12

13. LEI for schema.org

14. schema.org – global vocabulary for
searchSchema.org (2011), sponsored by the most
important search engines: Google, Microsoft,
Yahoo, and Yandex,
is a large scale collaborative activity with a mission to
create, maintain, and promote schemas for
structured data on the WEB pages and beyond.
These schemas cover entities, relationships
between entities, and actions. Today, over 10
million sites use Schema.org. Many applications
from Google, Microsoft, Pinterest, Yandex, and others
already use schema.org to power rich experiences.
Think of schema.org as a global Vocabulary for the
web transcending domain and language barriers.
MakoLab has built schema.org extensions:
2015 – auto.schema.org (Automotive Industries)
2016 – fibo.schema.org (Financial Industries)
14

15. fibo.schema.org
fibo.schema.org is an extension
of schema.org based on the most
comprehensive global financial
terms vocabulary: FIBO (Financial
Industry Business Ontology)
Collaborative project
of an international group of
individuals lead by MakoLab SA.
15

16. LEI in schema.org
Financial Extension for
schema.org created by MakoLab
and introduced to schema.org on
May 4th, 2016, contains property
definition that describes LEI:
http://schema.org/leiCode
16

17. GLEIO Ontology

18. From XML Schema to Ontology
18

19. 19
About XML schema for the CDF Format
 The role of the XML schema is to specify what constitutes a
valid document.
 XML schema compliant with the Common Data File Format is
merely focused on syntax and structure of XML documents.
 XML schema restricts the set of elements that can be used in
the files with global LEI data. But it doesn’t indicate how the
documents should be interpreted.
 XML schema for the Common Data File Format cannot be
understood by itself.

20. 20
LIMITATIONS OF XML
REPRESENTATION
An XML representation has many drawbacks and limitations:
lack of precise semantics
difficult extensibility
lack of global persistent identifiers
lack of inference (so also no content consistency check)

21. 21
Ontological answer to XML limitations
 Ontologies are focused on meaning. They are formal specifications of
shared conceptualizations.
 Ontologies allow to classify entities and have enough expressive power to
introduce constraints on the level of things.
 They are flexible enough to allow for extensions. New data based on
terminology from external resources can be added to an RDF graph.
 RDF/OWL ontologies use URIs, which are universal global unique
identifiers. By using URIs, browsers and other applications can retrieve
the data of the resource identified by that URI (see content negotiation,
LOD).
 Ontologies allow for inference. Reasoners for OWL ontologies can check
consistency of ontology, i.e. whether the set of ontological restrictions
(axioms) has a model. One can also verify whether the facts explicitly
expressed in an OWL ontology do not break the restrictions.

22. GLEIO
Current LEVEL 1 ontology

23. 23
About General LEI Ontology (GLEIO)
1. GLEIO specifies the conceptualization of a domain of things described by Common Data
File Format. It provides definitions of concepts and establishes semantic relations
between entities.
2. GLEIO is an OWL ontology compliant with the CDF Format. We made sure that each
element from the CDF Format found its counterpart in GLEIO
3. GLEIO is also linked with Financial Industry Business Ontology (FIBO). Bridging
connections are part of GLEIO’s specification.
4. GLEIO provides a knowledge scheme for LEI Resolver.
5. It was designed to satisfy Linked Open Data principles.
 Its canonical URI is http://lei.info/gleio/

24. 24
GLEIO
in
Protégé

25. 25
GLEIO about change
1. GLEIO is intended to make explicit temporal aspects of LEI data and allow for tracking
changes.
2. We proposed an innovative knowledge schema for representing change.
3. Currently: GLEIF publishes daily an updated concatenated file without any indication what
have changed.
4. What can change?
 An LEI registration status can change in time
(see: http://lei.info/549300U5FI25Y6MFOS85).
 The headquarters address of a legal entity can change
(see: http://lei.info/549300YV1HQLBVHOI649).

26. 26
GLEIO divides all entities into
1. entities that change - variable entities – have
different manifestations at different times, and
those that change
2. entities that do not change - non-variable
entities - do not have different manifestations
as different objects at different times.
 Here we have manifestations of
variable entities. Each such
manifestation has its time stamp (being its
beginning of existence).

27. 27
Example 1
 Every day our LEI application
reads a complete concatenated
XML file.
 A new manifestation of a legal
entity is created, if a change was
found (e.g., its headquarters
address has changed).
 Manifestations are linked by
temporal precedence relation
hasPredecessorEntityManifestation

28. 28
Example 2
The changes in LEI
registry is also
represented in GLEIO
by manifestations.
For instance, the status
of LEI registration can
change from “Issued”
to “Lapsed” (here we
still have to do with the
same LEI). In that case,
we create a new
manifestation of the
LEI.

29. 29
Example 3
In some other cases, for
instance when the LEI
status is “Duplicate”, it
will have its successor.
In some sense it ceases
to exist and stops being
updated.
Its successor becomes
the “issued” LEI.

30. GLEIO
Plans and discussion
about LEVEL 2
concepts inclusion

31. 31
Who is who? Who owns whom? Who owns
what?” GLEIO can be extended on the relationships proposed in LEVEL 2, i.e.:
• Various definitions of parent relationships
• direct parent relationships
• ultimate parent relationships (inference from a chain of direct parent relationships?)
• sets of entities that belong to the same group
• Other relationships that are not described as parent-child relationships
• joint ventures and joint operations
 Precise definitions are needed.

32. 32
Data history
“For policy or research purposes, it may be more important to be able to trace the
relationships among entities through time (including when a relationship starts or ceases
to exist) than to trace changes in their Level 1 data, such as a change of address.
Consideration of corporate actions such as mergers, acquisitions, and spin-offs often
figures prominently in constructing meaningful time series.
Thus, it is important from the start that history is built into the data model conceptually,
even though the collection or management of such information may not be implemented
in the first phase.”
Collecting data on direct and ultimate parents of legal entities in the Global LEI System – Phase 1

33. Radically new possibilities for
technological foundations of the
LEI System

34. Digital Identification - a quest for ….
 Non-repudiation
 Immutability
 Decentralization
 Transparency
 Resilience to system failures
34

35. Solution ...
35

36. What is Blockchain?
 Blockchain is the underlying technology of Bitcoin and other cryptocurrencies.
 The Blockchain is in essence a database technology featuring distributed,
tamper proof operation and is typically used as a public ledger of
timestamped transactions.
 It provides methods for verification of the existence of the transactions at a
particular times. Such verifications can be done independently by any other
system participant.
https://en.wikipedia.org/wiki/Bitcoin
https://www.oreilly.com/ideas/understanding-the-blockchain
36

37. More about Blockchain
Blockchain was invented in 2008 and first implemented in 2009 (as part of original
Bitcoin software).
Blockchain technology enables creation of tamper-resistant data structures while
making it publically available to all parties.
The underlying theoretical model is based on hash functions and public-key
cryptography and with growing size of the data, makes is practically impossible to
tamper with data.
Practical immutability of the database is achieved by its specific architecture and
the use of the specific Proof-Of-Work methods that are hard to execute making the
tampering practically impossible.
37

38. More about Blockchain
The actual data stored in a Blockchain
database (called “transaction”), are secured by
public-key cryptography (signed by private keys
or their creators), to prevent any third party
from modifying it.
“Transactions” (and the entire block containing
them) need to be confirmed. After this step all
the chains in the Blockchain contain the
confirmed block and the chain grows. There
are usually many confirmations needed to be
performed (by participants called miners) for
the block with transactions to be accepted. The
confirmation is by design computationally
expensive procedure (Proof-of-Work)
38

39. Blockchain evolution
 Blockchain 1.0 – Bitcoin and other Crypto Currencies
“The deployment of cryptocurrencies in applications related to cash, such as currency transfer,
remittance, and digital payment systems”
 Blockchain 2.0 – Contracts
“The entire slate of economic, market, and financial applications using the blockchain that are
more extensive than simple cash transactions: stocks, bonds, futures, loans, mortgages, titles, smart
property, and smart contracts”
 Blockchain 3.0 – Applications
“Beyond currency, finance, and markets—particularly in the areas of government, health, science,
literacy, culture, and art.”
Quotations from: “Blockchain” by Melanie Swan, O'Reilly Media, Inc.
39

40. Using Blockchain 2.0 for LEI – An idea
Currently, the single XML record for LEI entity is treated as "atomic", in the sense of being
curated by the global LEI authority that publishes it. As such, an XML representation of single
LEI record can be considered as a state for single smart contract.
Each such contract would offer method for accessing the representation, and a dynamic data
structure that holds "revisions" of the representation. That is, when the LEI record changes
globally, its new representation would be added to the state of the contract. Such
contract can hold many revisions of the representation, bound only by the capabilities of the
network global storage. We call such contract "entity contract".
Together with entity contracts, someone can devise one or more "master contracts", that keep
track of individual entity contracts and make accessing an easier process. One must remember,
however, of the tradeoff between complexity of such contracts and their cost of creation and
execution.
40

41. Using Blockchain 2.0 for LEI – An idea
The network of participants can be a global network like Ethereum, where transactions are
validated by third party anonymous participants, or can be an isolated network of private
participants that does not expose their contracts for public execution.
The suggested architecture for LEI: Consortium blockchains
A consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of
nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and
of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be
public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks
being public together with an API that allows members of the public to make a limited number of queries
and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered
“partially decentralized”.
Vitalik Buterin - https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/
41

42. MakoLab’s
Proof-of-Concept
 Ethereum as smart contract
platform
 Ethereum clients form a private
network of participants
 Each client synchronizes its
blockchain with others
 Smart contracts are deployed on
the blockchain and executed from
there
 Three LOUs modelled
 Clients are connected in a
distributed cluster
 Single node is: 8GB/4 cores/ 3,2
GHz/Intel i7 42

43. More details
 Fast index service used for
searches
 Individual web interfaces for each
LOU
 POC functionality:
Search, Creation of contracts for
LEIs records, registration in the
master, creation of the new
revisions …
 Estimated mining time for single
LEI:
mining of 1 block itself, with low
difficulty PoW, typically less than
10 secs
1 LEI = 3 blocks = ~30 sec.
43

44. Web interface http://leiblc.mm.com.pl/POC.html
44

45. Web interface
45

46. Potential Proof-Of-Concept v2.0 for GLEIF
 Creating Blockchain database with ALL existing LEI records
 Modelling realistic LEI revisions
 Modelling consortium & private LEI Blockchains
 Testing different blockchain implementations
 Analysing various Proof-of-Work possibilities vs number of mining nodes
 Testing blockchain-indexer and Web access interfaces
 Performance tests – conclusions for hardware
 Security audit
 Design of final system architecture
46

47. What are GLEIF needs related to
LEI infrastructure?
What could MakoLab offer ?

48. 48
Contact
Robert Trypuz
MakoLab SA
Rzgowska 30
93-172 Łódź
Poland
robert.trypuz@makolab.co
m
Mirek Sopek
MakoLab SA
Demokratyczna 46
93-430 Lodz
Poland
+48 600 814 537
sopek@makolab.com