Embed Size (px)
Citation preview
LEI.INFO & The Ideas for LEI SystemA workshop for GLEIF by MakoLab SA
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
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
Bringing Semantic Web Technologies to LEI System LEI Search Engine and Linked Data Resolver LEI in schema.org GLEIO Ontology
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
MakoLab LEI Resolver – how does it work?
5493001KJTIIGC8Y1R12Create 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
URI Creation – MakoLab LEI Web Application
Few technological details:
TripleStore – AllegroGraphApplication Layer – Highly Scalable .NET Web app.Romantic Web (SW) components
1
7
LEI Resolver – Visual Resolution http://lei.info/5493001KJTIIGC8Y1R12 Visual for Human Web Media (HTML)2
8
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
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
LEI Resolver – Meeting Linked Data Standards
Sophisticated Querying Mechanism SPARQL END POINT
Allows for building third party applications on top of the resolver
http://lei.info/sparql
11
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
LEI for schema.org
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
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
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
GLEIO Ontology
From XML Schema to Ontology
18
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
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
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.
GLEIOCurrent LEVEL 1 ontology
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
GLEIO in Protégé
25
GLEIO about change1. 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
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
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
Example 2The 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
Example 3In 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.
GLEIOPlans and discussionabout LEVEL 2 concepts inclusion
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
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
Radically new possibilities for technological foundations of the LEI System
Digital Identification - a quest for ….
Non-repudiation Immutability Decentralization Transparency Resilience to system failures
34
Solution ...
35
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
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
More about BlockchainThe 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
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
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
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
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
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 secs1 LEI = 3 blocks = ~30 sec. 43
Web interface http://leiblc.mm.com.pl/POC.html
44
Web interface
45
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
What are GLEIF needs related to LEI infrastructure?What could MakoLab offer ?
48
Contact
Robert TrypuzMakoLab SA Rzgowska 3093-172 Łódź Poland
Mirek SopekMakoLab SA Demokratyczna 4693-430 Lodz Poland
+48 600 814 [email protected]
