An alignment of EthOn, the Ethereum Ontology and Financial Industry Business Ontology.
The article compares how blockchain technology differs from traditional centralized database systems. The Financial Industry has launched many projects to proof the concept of incorporating the blockchain technology. Both sides also embrace 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 the most universal and beloved tales in Bhutan. As the story goes, 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.
The Financial Industry adapts Blockchain technologies.
A blockchain 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 an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. (Wikipedia).
Nodes in the blockchain network replicate the state of the system. The nodes also validate pending transactions. Algorithms define consensus of nodes to commit a set of transactions. This creates a new state of the system – a new block in the chain. A naïve algorithm is simply, that the majority of nodes must agree. Thus even if nodes crash or become corrupted, the blockchain as a whole continues operation 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 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 nodes 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 dominate decentralized platform to run smart contracts.
Will the Blockchain replace SWIFT? Chris Skinner of the American Banker magazine asked provocatively at the AB conference and a March, 2016 article. The Society for Worldwide Interbank Financial Telecommunications is owned by the Global Banking Industry. SWIFT provides the messaging network for financial transactions.
Specialized Financial Institution 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.
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 Blockchain in
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.
The report has a diagram laying out an 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 system 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 onsite 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. 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 do away with the need to reconcile between different ledgers.
Ethereum and EDMC embrace Semantic Web and Ontologies.
The Semantic Web is an extension of the current Web in which information is given well-deﬁned meaning, better enabling computers and people to work in cooperation.
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 describing taxonomies of classes and properties. Black Rock is an Investment Adviser (rdf:type). We can define data and object properties of the class.
There are 3 ontology levels based on their Level of abstraction.
- An upper ontology (aka top-level ontology or foundation ontology) is an ontology which 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, 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. It is specific enough to hold data. EthOn is an operational ontology of Ethereum smart contracts and Blockchain.
Operational ontologies include core ontologies, which in turn include upper ontologies.
Classes in the operational ontology will be subclass of core ontology classes. Likewise operational ontology properties are often sub property 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.
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 denotes 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 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, first phase of the inference engine run.
Here is the challenge for Ethereum developers to create smart oracles that serializes the state in the form of RDF triples.. For private blockchains the complete world state should be exported.
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:
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.
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
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 Payer in a payment event. The Client Role is covered by a Service Agreement, 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).
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.
|Account||Account||not equivalent, the FIBO entity is more generic|
|Message||TransactionEvent||not equivalent, the FIBO entity is more generic and less detailed|
|MMP Tree||N/A||operational only|
|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.
Three EthOn classes have corresponding FIBO concepts: External Account, External Agent and Account State
EthOn External Account is 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
External Actor is the 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, 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 emphases the underlying Service Agreement.
- The FIBO Contract Principal is the first party to a contract. The principal role emphases the counterparties in a bilateral exchange.
We can implement 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 are 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 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 has Amount 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 detail of amounts in FIBO. For a detailed treatment of Semantic ETL, see the Financial Regulation Ontology tutorial chapter two.
The EthOn Message Concept relates to FIBO Transactions. FIBO doesn’t have much detail 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, 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.
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 from FIBO into EthOn, we access the Blockchain.
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 2nd generation blockchain. The Financial Industry Business Ontology is the 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 Network.
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.
This is a recommended reading list. Sources for citations are next to the quoted text.
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 into ontologies.
Dean Allemang, James Hendler, Morgan Kaufman, 2011
Ontology Alignment – Bridging the Semantic Gap
Marc Ehrig, Springer 2007
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 firstname.lastname@example.org .