An integration of the Ethereum and the Financial Industry Business Ontology.
The article compares how blockchain technology differs from traditional centralized database systems. The Financial Industry has launched many projects to prove the concept of incorporating blockchain technology. Both sides also embrace the Semantic Web and have published ontologies. The alignment, identifying and formalizing common and related concepts in Finance and blockchain ontologies, is a bridge. It facilitates analysis and system design. In practice, and applied with populated ontologies, the alignment enables Semantic Web technologies.
The “Four Harmonious Friends” is one of Bhutan’s most universal and beloved tales. In the story, the bird finds a seed and plants it. Then, the rabbit waters it and the monkey fertilizes it. Once the seed sprouts and begins to grow, the elephant protects it.
(Smithsonian Center for Folklife and Cultural Heritage)
The Financial Industry has adopted Blockchain technologies.
A blockchain is a distributed database that maintains a continuously growing list of ordered records called blocks. Each block contains a timestamp and a link to a previous block. Blockchains are open, distributed ledgers that can record transactions between two parties efficiently and in a verifiable and permanent way. (Wikipedia).
Nodes in the blockchain network replicate the system’s state and validate pending transactions. Algorithms define the consensus of nodes to commit a set of transactions, which creates a new state of the system—a new block in the chain. A naïve algorithm simply requires the majority of nodes to agree. Thus, even if nodes crash or become corrupted, the blockchain as a whole continues to operate in a consistent state.
Bitcoin participants can transfer the crypto-currency without an intermediary bank. The payment system is distributed across the blockchain implementing a decentralized ledger. Blockchain nodes validate the digital signatures of the payer and beneficiary and ensure that the transaction is funded. The balance in a Bitcoin account is the aggregate of inflows and outflows, confirmed by the node’s consensus and recorded as a block. In a ledger credits and debits must balance. The nodes processing payments validate that pending inflows match outflows. Once, consensus has been reached the pending transactions are committed as a block. All notes will reset to the new state of the system.
Blockchain 2.0 extends the blockchain use cases beyond cryptocurrency. A Smart Contract is a piece of code residing on the blockchain database. Smart Contract functions implement logic and change the contract’s data. They can call other functions. They can be called remotely. For example, an account contract can process payment requests and issue reoccurring payment autonomously. Smart Oracles are contracts that communicate with outside systems. They can pull in reference and market data. They can export their balances and transactions. Ethereum is the dominant decentralized platform to run smart contracts.
Will Blockchain replace SWIFT? Chris Skinner of American Banker magazine provocatively asked at the AB conference and in a March 2016 article. The Society for Worldwide Interbank Financial Telecommunications is owned by the Global Banking Industry. SWIFT provides a messaging network for financial transactions.
Specialized Financial Institutions are responsible for safekeeping securities and other assets. Will the Blockchain make Custodians obsolete? No, but as Hayley McDowell writes in Global Custodian:
…blockchain could possibly replace current centralised business models in the financial sector, as distributed ledger technology (DLT) works its way through disrupting the industry one section at a time.
Hayley McDowell in Global Custodian
Will the Blockchain replace Euroclear, (DTCC, LCH)?
London Clearing House, Depository Trust & Clearing Corporation, and others facilitate the clearing of payment and securities transactions. This is the process from order to settlement, whereby funds and securities balances are moved between accounts..
Last year, Euroclear and Oliver Wyman management consultancy published a report on Blockchain in Capital Markets.
The current methods are highly complex, utilize fragmented IT and data architectures and suffer from a lack of common standards. This creates the continual need to reconcile data with massive systems and process duplication, leading to high costs and protracted time to execute tasks.
Euroclear
The report has a diagram laying out a utopian view of capital markets with Blockchain and smart contracts at the center. The Use Case below is a simplification of the Utopia, not depicting derivative, fund, and collateral ledgers.
Just like in the bitcoin example participants agree to transact. There are still market venues and trading systems for price discovery and matching. The Transact use case includes the Cash and Asset ledger. Both ledgers have extension to record transaction and to store positions and balances.
The Asset Ledger can pull in security, counterparty, and other reference data. Ledger information can be exported to outside Custody Management, Asset Servicing, and other on-site systems. The Semantic Web utopia is that outside information, especially reference data, is available as Open Linked Data stored in SPARQL Endpoints. The ontology alignment facilitates navigation—query joins of blockchain with outside data.
In summary, we can not put all financial reference data into the blockchain, and Smart Contracts will not take care of taxes and regulatory reporting. However, Smart Distributed Ledger Technology (DLT) will replace monolithic ledgers duplicated across Financial Institutions and functions. DLT will eliminate the need to reconcile between different ledgers.
Ethereum and EDMC embrace the Semantic Web and Ontologies.
The Semantic Web is an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation.
(Sir Tim Berners-Lee, director or the World Wide Web Consortium, W3C)
The Resource Description Framework (RDF) uses an elementary grammar to store information in triples.
Black Rock manages the iShares MSCI Emerging Markets ETF. Both are web resources identified by a Uniform Resource Identifier, URI. The Object Property “manages” connects the two resources.
RDF Schema (RDFS) extends RDF to allow the description of taxonomies of classes and properties. Black Rock is an Investment Adviser (rdf:type). We can define the class’s data and object properties.
There are 3 ontology levels based on their level of abstraction.
- An upper ontology (aka top-level ontology or foundation ontology) is an ontology that describes very general concepts that are the same across all knowledge domains. Well known core ontologies are BFO, GFO, DOLCE, SUMO and Dublin Core. Neither EthOn nor FIBO import upper ontologies. However, EthOn imports the Friends of a Friend cross-domain ontology. FIBO unfortunately redefines many upper concepts such as numeric, temporality, mereology. FIBO does import metadata concepts, skos, and Dublin Core.
- The goal of a core ontology is a global and extensible model into which data originating from distinct sources are mapped and integrated. (Doerr, Hunter, Lagoze) The core ontology applies to a specific domain, such as biology, medical, Legal and Finance. FIBO is a core ontology for the Financial Services domain. While it has upper and operational elements, the bulk is core.
- The Operational Ontology implements a core ontology that is specific enough to hold data. EthOn is an operational ontology for Ethereum smart contracts and Blockchain.
Operational ontologies include core ontologies, which in turn include upper ontologies.
Classes in the operational ontology will be subclasses of core ontology classes, and operational ontology properties are often subproperties of core ontology properties.
Consensys Media released the Ethereum Ontology
EthOn is a multi-purpose Ethereum ontology. In his article Semantic Ethereum, the author Johannes Pfeffer describes the benefits:
Ethereum is an ideal field of application for ontologies because a consensus about the semantics of the involved concepts is a prerequisite for reaching consensus about the state of the network. Any deviation from this consensus results in a fork. An Ethereum ontology may serve as a semantic specification of its concepts that complements its technical specification.
consensys.net
The ontology is based on the Ethereum Yellow Paper. It looks quite complete, representing the major concepts and properties of Solidity, the Ethereum Smart Contract programming language. The diagram shows the root class EthOnConcept breaking down into Account, Message, State, Network, Block and MMP Tree concepts..
Solid Arrows are subclasses. Blue property icons and thin arrows indicate object properties. The green icons denote a data property. Here is a complete class diagram in PDF with all 45 classes.
EthOn is an excellent ontology. It can do much more than just diagramming and documentation. Here is the EthOn specification.
The Ethereum Ontology should be populated with blockchain data!
This would make the full Semantic Web power available:
- Queries to aggregate, analyze, and report. SPARQL is the query language for the Semantic Web. Just like SQL for relational databases.
- Reasoning is used to derive new insights from asserted data. Inference engines (aka Reasoners) compute subsumption to defined classes and make external information, as in FIBO, visible.
- Validation to uncover inconsistencies in contracts and transactions. This is a by-product, the first phase of the inference engine run.
Ethereum developers must create smart oracles that serialize the state in the form of RDF triples. The complete world state should be exported for private blockchains.
The EthOn GitHub repository shows the Genesis account in OWL turtle notation. I also prefer turtle, but RDF is XML-based and thus easier to generate. Here is the EthOn example in RDF/XML:
<owl:NamedIndividual rdf:about=”http://ethon.consensys.net/addresses/0x0000000000000000000000000000000000000000″>
<rdf:type rdf:resource=”http://ethon.consensys.net/ExternalAccount”/>
<ethon:hasState rdf:resource=”http://ethon.consensys.net/AccountState1″/>
<ethon:address rdf:datatype=”http://www.w3.org/2001/XMLSchema#hexBinary”>0000000000000000000000000000000000000000</ethon:address>
<rdfs:label>Genesis Address</rdfs:label>
</owl:NamedIndividual>
<owl:NamedIndividual rdf:about=”http://ethon.consensys.net/AccountState1″>
<rdf:type rdf:resource=”http://ethon.consensys.net/AccountState”/>
<ethon:accountBalance rdf:datatype=”http://www.w3.org/2001/XMLSchema#integer”>0</ethon:accountBalance>
<ethon:accountNonce rdf:datatype=”http://www.w3.org/2001/XMLSchema#integer”>0</ethon:accountNonce>
</owl:NamedIndividual>
Financial Industry Business Ontology
The EDM Council is a 501(c)(6) non-profit trade association founded by the financial industry to elevate the practice of data management as a business and operational priority. The Council is a leading advocate for the development and implementation of data content standards and the publication of data management best practices.
(Enterprise Data Management Council)
The Financial Industry Business Ontology (FIBO) is a collaboration between the Enterprise Data Management Council (EDMC) and the Object Management Group (OMG). The EDMC leads design in collaboration with major Financial Institutions. OMG provides governance and publishes FIBO as a formal standard.
FIBO has more than 600 classes. In particular the taxonomies for roles, organizations, financial instruments are quite deep. There are schemes for classifications, identifiers, and codes. Reference data for US regulators, ISO Currency, and Country codes is already instantiated.
The class graph shows the FIBO classes most relevant for blockchain. The solid yellow dots indicate classes. Class restrictions establish object property connections between classes:
Existential restriction, some values from
Universal restriction, all values from
Like most enterprise models, FIBO differentiates between a Party and its Role. The PartyInRole has subclasses for Payer, Client, and many more roles. The Party must have an identity to a single Independent Party, either of which can be either a natural person or an organization. John Doe is a single instance in Independent Party and person, identified by SSN and other identification documents. John Doe can be a Client and Account Holder. He can be a Payer in a payment event. The Client Role is covered by a Service Agreement, a subclass of Contract. The Contract can be an Account. This completes one circle. Note that some implementations and data feeds may only have John Doe’s account number, but no information on the underlying service agreement. Transaction events apply to accounts. Transactions can be simple payments, Securities, or Accounting Transactions. The Transaction subclasses are not disjoint in FIBO. We can (and should) have a Transaction Event, the Payment and Accounting Transaction Event populated.
The science and practice of ontology alignment
Given two ontologies, aligning one ontology with another one means that for each entity (concept, relation, or instance) in the first ontology, we try to find a corresponding entity, which has the same intended meaning, in the second ontology… Apart from one-to-one equality alignments, … in the real world one entity often has to be aligned not only to equal entities, but based on another relation (e.g. subsumption).
(Ehrig 2007)
The same intended meaning applies to ontologies of the same level. For example, the Legal Knowledge Interchange Format (LKIF) to FIBO alignment has owl:equivalentClass axiom between FIBO Statute Law and LKIF Statute. In our case we are aligning from operational to core ontology. That typically means finding FIBO super classes for EthOn classes. The first ontology is EthOn, simply because it is much smaller than FIBO.
Anchor is set of correspondence between two ontology entities, which are usually required prior to performing other tasks, such as reasoning, partitioning and also matching.
(Euzenat, Shivvaiko 2013)
We apply the anchor concept a little broader and find correspondence between the EthOn concepts and FIBO clusters.
| EthOn | FIBO | comment |
| Account | Account | not equivalent, the FIBO entity is more generic |
| Block | N/A | operational only |
| Message | TransactionEvent | not equivalent, the FIBO entity is more generic and less detailed |
| MMP Tree | N/A | operational only |
| Network | NetworkLocation | same concept |
| State | various | FIBO doesn’t hold states accounts and other classes. Instead date (time) keys variant data. E.g. MonetaryAmount, hasEndDate |
Here is a complete class diagram in PDF with all alignments and related EthOn and FIBO classes.
The alignment/matching literature covers (semi) automatic techniques in detail. Alas, we don’t have populated ontologies yet, so tools can not infer correspondence based on class instances. The process applied here is manually rationalizing definitions and object property relationships.
Account
Three EthOn classes have corresponding FIBO concepts: External Account, External Agent, and Account State
EthOn External Account is a subclass of FIBO Account ethon:ExternalAccount rdfs:subClassOf fibo-fbc-pas-caa:Account ;
For operational purposes, we always want to align bottom-up. Rather than conceptualizing between EthOn account concepts and FIBO abstract Agreement super class, we start with most specialized subclass: External Contract – an account owned by an External Actor. This corresponds to the lowest FIBO class Account. The classes are not equivalent. While all EthOn External Accounts are also FIBO account, there are other accounts in FIBO that are not found in Ethereum (e.g. Bank Accounts).
The diagram has EthOn External Account at the bottom with the arrow to FIBO Account indicating the added subclass relationship.
The diagram shows some of the query inference possibilities:
- From a FIBO perspective, we can navigate to the Ethereum Public Key, Account State, and Balance.
- From a blockchain perspective, we can retrieve external world properties like legal documentation, counterparties, jurisdiction, terms, and principal.
EthOn External Actor is a subclass of FIBO Account Holder and/or Contract Principal
An External Actor is a Person or other entity set up to interface with an Ethereum node. EthOn doesn’t have any data properties for this class. Identifying properties such as name, social security number, and passport will be needed to match the External Actor with existing FIBO Autonomous Agents.
As mentioned earlier, FIBO differentiates between the agent and the role. We align the External Agent with the appropriate FIBO Party in Role.
- The FIBO Account Holder owns the FIBO Account. This role emphasizes the underlying Service Agreement.
- The FIBO Contract Principal is the first party to a contract. The principal role emphasizes the counterparties in a bilateral exchange.
We can implement an Account Holder, Principal, or both depending on the specific FIBO Blockchain use case. The diagram pulls in the related FIBO account and Contract.
From FIBO we can query EthOn External Actor and the related EthOn Accounts (not depicted here).
Starting with the EthOn External Actor, we can pull in FIBO reference data about the Contract and/or Account. Note the hasIdentity object property on Party in Role. The range of the property leads to the FIBO Legal Person / Organization.
EthOn Account State populates FIBO Monetary Amount.
The design pattern for history in EthOn is very different from FIBO. EthOn writes a new State for every change to an Account. FIBO has no “history” snapshot of the account. Instead, the numeric properties are classes with a date (time) and other classifications. The Monetary Amount holds the number, currency, and other characteristics of the amount.
There is no direct equivalence or subclass relationship between the two concepts. Instead, we use Semantic ETL to populate FIBO Monetary Amount instances from the EthOn Account State. The diagram shows the mapping.
Build URI maps the source Account State to the Monetary Amount. The function creates the instance URI using the EthOn state Root property. The target hasAmount property is simple cast (conversion from integer to decimal type).
The has Source Instance property preserves the lineage from Monetary Amount to the Account State Instance, so we can query to investigate blockchain details of amounts in FIBO. For a detailed treatment of Semantic ETL, see the Financial Regulation Ontology tutorial, chapter two.
Message
The EthOn Message Concept relates to FIBO Transactions. FIBO doesn’t have much detailed modeling for transactions.
EthOn Tx is a subclass of FIBO Transaction Event
The EthOn transaction breaks down into subclasses by function: Call, Create, Value.
Whereas FIBO transactions have subclasses by subject: Accounting, Securities, and Payment.
Therefore we deviate from our bottom-up alignment approach and make EthOn Transaction a subtype of FIBO Transaction Event.
Navigation is mainly from FIBO into EthOn to pick up transaction details.
EthOn Tx Receipt is a subclass of FIBO Transaction Confirmation
The EthOn transaction receipt is a confirmation. Note that both ontologies relate the transaction to its confirmation/receipt.
Network
Neither ontology has much detail on networks. We only state that EthOn Node is a subclass of FIBO Network Location.
EthOn defines Node as a participant in an Ethereum Network. FIBO’s Network Location is a location in a telecommunications network that may be identified by a network address (an identifier for a node or interface).
Navigating from EthOn to FIBO, we can source more reference information about the network and addresses.
Joining the FIBO into EthOn, we access the Blockchain.
Conclusion
The Financial Industry adapts to blockchain technology. The utopian use case has the distributed ledger at the center combined with external systems for reference data and servicing. The interface should be semantic. The Ethereum Ontology fully incorporates second-generation blockchain. The Financial Industry Business Ontology is institution-owned and designed.
We explained and applied ontology alignment methodologies. FIBO and EthOn align in all concepts critical to the distributed ledger use case: Accounts, Agents, Transactions, and Networks.
Class and graph diagrams of the aligned ontologies show the query and inference paths:
- For FIBO interfaced external systems to access blockchain details.
- For Ethereum Accounts (External and Smart Contracts) to look up external reference data.
Elephant and Blockchain become harmonious friends.
References
This is a recommended reading list. Sources for citations are next to the quoted text.
Online resources
EthOn / FIBO alignment (this post)
FIBO_EthOn_Alignment.ttl – (the ontology file in turtle notation)
Ethereum – official site
EthOn — introducing semantic Ethereum
Financial Industry Business Ontology (FIBO) website
Ontologies and Ontology Alignment (books)
The Science of the Blockchain
Roger Wattenhofer, Inverted Forest 2016
Semantic Web for the Working Ontologist, Second Edition: Effective Modeling in RDFS and OWL
Highly recommended; the best introduction to ontologies.
Dean Allemang, James Hendler, Morgan Kaufman, 2011
Ontology Alignment – Bridging the Semantic Gap
Marc Ehrig, Springer 2007
Ontology Matching
Jérôme Euzenat, Pavel Shvaiko, Springer 2013
Thanks for reading this far. I appreciate your feedback. Please respond with your questions. corrections, and suggestions on LinkedIn or email me jziemer@jayzed.com .