Open Research Knowledge Graph: Towards Machine Actionability in Scholarly Communication

Despite improved digital access to scientific publications in the last decades, the fundamental principles of scholarly communication remain unchanged and continue to be largely document-based. The document-oriented workflows in science publication have reached the limits of adequacy as highlighted by recent discussions on the increasing proliferation of scientific literature, the deficiency of peer-review and the reproducibility crisis. In this article, we present first steps towards representing scholarly knowledge semantically with knowledge graphs. We expand the currently popular RDF graph-based knowledge representation formalism to capture annotations, such as provenance information and describe how to manage such knowledge in a graph data base. We report on the results of a first experimental evaluation of the concept and its implementations with the participants of an international conference.

INTRODUCTION
Documents are central to scholarly communication, as the vast majority of research contributions are formulated as papers in printed or electronic forms. While document-centred scholarly communication may be sufficient for addressing certain scientific questions, in practice, most of the contemporary scientific discourse (and its underlying problem domains) demanding an interdisciplinary research effort, in which scientists have to deal with a large amount of divers, and (currently) not interlinked information sources. Furthermore, scientific outputs are usually reported in forms of monolithic (electronic) documents. Most of these publications remains hardly accessible for computer analysis and processing, besides running simple text search or limited annotation functions on them. Therefore, despite that the text contained in publications can be indexed and used for searching, images, diagrams, tables, mathematical formulas, and references are hardly accessible to computers. This clearly indicates that scientific publishing has remained almost unchanged during the past several centuries, which is very unsatisfactory in the light of current technical development of the society in general.
There are further arguments pointing towards a major reform of current scientific paper publishing. For instance following recent scientific discourse is difficult (if not impossible), due to exponential expansion of scientific knowledge volume [7,26]. We are entering an era, when individual researchers cannot possibly cope with the extreme volumes of publications, which can easily result in vague, ambiguous and redundant research reporting. Consequently, this phenomenon is also identified as one of the main factors behind the reproducibility crisis [23].
Insufficient peer review is another problem. More than 1 million articles are published annually [6]. Finding referees, and managing high quality peer review process, are oftentimes difficult. This notion results in extended manuscript revision times and feedback cycles, where publication deadlines are often delayed and research outputs become outdated during the publication process. [32].
The challenge, we are facing in scholarly communication is also illustrated by how the digitalization techniques compare to other domains. Most information rich publishing and communication services (e.g. encyclopedias, mail order catalogs, street maps or phone books) went through a total digital transformation in the recent years. Examples are encyclopedias, mail order catalogs, street maps or phone books. In these domains, the traditional documentoriented publications where not just digitized and published digitally as PDF documents, as we do in scholarly communication now. Who would use a PDF of a phone book, mail-order catalog, encyclopedia or phone book now anymore? Which actually would be the comparable state to what we have in scholarly communication right now. Instead in these domains, completely new means how to organize and access the information were developed. Documentoriented mail order catalogs were replaced by e-commerce services, which allow faceted-browsing, filtering, comparisons, and many other features, not available in print. Similarly, street maps were replaced by navigation services. The difference is that these digital services not just digitized the analogue documents, but developed very specific means for collaboration, information sharing and access, which leverage and exploit the new digital possibilities. Another commonality is that instead of unstructured documents, these new services are now based on comprehensive and structured data or even knowledge bases.
As a result there is an urge for a more flexible, fine-grained, semantic and context sensitive representation of scientific knowledge. One way to achieve this, is presenting scholarly information as structured, interlinked, and semantically rich knowledge graphs [3].
A definition to the term "knowledge graph" was given by [13]: "a knowledge graph acquires and integrates information into an ontology and applies a reasoner to derive new knowledge". A knowledge graph, which is utilized to store, exchange and to infer (for example, using a reasoner) scientific knowledge in an open and transparent way, we name as an Open Research Knowledge Graph (ORKG).
In this article, we describe the first complete round-trip engineering of a knowledge graph based scholarly communication approach. We expand the currently popular RDF graph-based knowledge representation methods to be efficiently able to capture annotations, such as provenance information, in the body of scientific knowledge. We also detail our back-end and front-end ORKG implementations, based on the extended graph data model. Finally we report on the evaluation results, pertaining to our initial ORKG concept and software prototype implementation, with the involvement of international conference delegates at the Data Integration in the Life Sciences (DILS) conference.
The remainder of this article is structured as follows: In section 2 we introduce the problem, together with our general research approach. The details of ORKG are presented in section 3, discussing the details of our proposed technical solution. This is followed by the reporting on the process and the date collected during an evaluation study in section 4, with subsequent discussions in section 5. All related work is presented in section 6 and we close this paper with directions for future work and conclusions in section 7.

PROBLEM STATEMENT
Nowadays, published research contributions are in form of (typically digital PDF) documents, where authors structure articles in sections addressing problem statement, approach, evaluation, and conclusions. This approach to scholarly communication is not without challenges. The communicated information is often ambiguous and difficult to reproduce. Moreover, since information is in documents it is difficult for researchers to efficiently explore state-of-the-art research. Reviewing contributions, too, is becoming more resource intensive due to the vast number of publications and general lack of reviewers.
We illustrate the problem with an example from life-sciences. When searching for publications on the popular Genome editing method CRISPR/Cas 1 in scholarly search engines we obtain a vast amount of search results. Google Scholar, for example, returns more than 56.000 results, when searching for the search string 'CRISPR cas' 2 . For answering a specific research question, it is often required to join various keywords or search strings. Examples in the context of CRISPR/Cas include: • How good is CRISPR/Cas (wrt. precision, safety, cost)?  • What specifics have genome editing with insects?
• Who has applied it to butterflies?
Even when adding the search term 'butterfly' to the search query, we still receive more than 500 search results, many of which might be non-relevant. Furthermore, the relevant results might not be included (e.g., due to the fact that the technical term for butterfly is Lepidoptera, which combined with 'CRISPR/cas' returns 1.700 results). We argue that keyword-based information retrieval cannot fulfill the requirements of scholarly communication in the digital age. While there have been some approaches for developing automated techniques to assist researchers in managing the breadth and depth of information in scholarly documents, we suggest that completely new means for representing scholarly communication have to be developed, and that automated techniques can and will not reach the accuracy required. Working with digitized scholarly documents might only cure some symptoms of the problems currently observed in scholarly communication but not result in an effective cure. Imagine, how the analysis of PDF versions of maps or mail order catalogs using natural language processing and information retrieval techniques would compare to the currently prevalent techniques using database backed e-commerce applications or digital map systems such as OpenStreetMaps [35].
The document-based mechanism to represent scholarly communication do not allow to clearly identify concepts and their relationships. This results in ambiguities since different authors refer differently to the same concepts or use the same term for referring to different concepts. Also, the characteristics of concepts or relationships between concepts are not clearly defined in a way that algorithms and machines could support researchers in mastering the information. Automated techniques to identify concepts in a text (e.g., named entity recognition) as well as their characteristics or relationships (relation extraction), despite decades of research, do (and will) not reach a sufficiently high accuracy for meaningful applications. Some people might argue that recent advances in machine learning might be applicable to making sense of scholarly communication. We suggest that this is not possible, due to the lack of training data. Machine learning can only be applied when  algorithms can learn from tagged training data (produced by humans). To represent scholarly communication, training data does not exist and creating it would be extremely time-consuming even if restricting ourselves only to very narrow domains (e.g., consider the effort required to create a systematic literature review). The only way to resolve this problem is to develop a semantic means to represent scholarly communication.

OPEN RESEARCH KNOWLEDGE GRAPH
We propose to leverage knowledge graphs to represent information communicated in scholarly literature. Crucially, knowledge graphs not only contain bibliographic metadata (e.g., about authors, conferences, references) but semantic descriptions of scholarly contributions (i.e., the problem, approach, solution, implementation, evaluation of concrete research investigations). We call this knowledge graph the Open Research Knowledge Graph (ORKG).
One of the approaches to populate the ORKG is to crowd-source the information. To that end, we developed a prototype web application that we envision later to be integrated into journal and conference or open-access repository submission systems. In this section, we present the two main component of the system: the back-end and the user interface (UI).

Scholarly Knowledge Graph Back-end
In order to meet ORKG requirements, the system needs to implement many aspects that govern and control the curation process, from defining the data model, and representing resources, to exposing the system via APIs.
Data model and architecture. The back-end uses a graph model that consists of nodes and edges. This model was chosen to simplify the process of adding information to the system without the need to learn more complex data models, such as RDF 3 . One of the greatest differences to RDF is that everything is modeled as an entity, i.e., it can be referenced by an identifier (ID).
The data model is centered around the concept of a statement. A statement is a triple that consists of a subject and an object (nodes) that are connected by a predicate (relationship). Nodes can have one of two types: resources and literals. Resources represent a concept, such as a scientific method or an author, whereas literals represent values, such as the name of the method or the author's name. Within statements, literals can only appear in the object position of the statement.
The main application is written in the Kotlin [25] programming language, within the Spring Boot 2 framework. The data is stored in a Neo4j graph database accessed by the application via the Spring Data Neo4j OGM 4 . From the architectural perspective, the design follows a classical layered architecture with ports and adapters ("hexagonal architecture"). To evaluate the different behaviors of technologies, adapters to different components are possible. For example, the persistence layer is able to handle linked property graphs (LPG) such as Neo4j as well as triple-stores. The domain layer holds the domain objects, such as statements, resources, and literals. The application layer is responsible for the application logic, such as the REST API. Building on the other layers, the user interface is responsible for querying and displaying the data forming the knowledge graph.
ID generation. In order to be able to link and retrieve statement or resource entities, IDs need to be generated when information is stored. Because we envision a distributed architecture, globally unique IDs are required to synchronize information between instances. However, global unique identifiers are complex to generate and manage. IDs need to be generated in a way that satisfies the requirements of being unique across all entities in the system, immutable, short (for easy input) and can be generated with reasonable performance. As summarized in Table 1, we have taken into account various methods for ID generation.
Universally unique identifiers (UUID) exist but are very hard for humans to read, remember, or understand due to their length.Merging or linking data between several instances of the ORKG infrastructure does not need universal uniqueness. However, the same result can be achieved by having locally unique IDs that are name-spaced. To satisfy the requirement of being short, positive numbers will be used with a prefix that determines the type, e.g., "P123" for a predicate. This is similar to the way Wikidata handles IDs. It has the drawback of being harder to read in a query but has the advantage of being short. Using a human-readable label would also be possible but cannot be automatically generated and therefore needs input from the user at the time of creation. It is technically possible to change to human-readable IDs from numeric ones later but due to the immutability requirement, it should be avoided so it does not cause problems for downstream users. Generating these IDs fast is crucial when a large number of statements is included in the graph. ID generation can be done with good performance by using the HiLo pattern, moving the responsibility of ID generation from the database to the back-end. In this pattern, the database creates a prefix (the so-called high number) that the back-end can then use to construct IDs by generating its own numbers (low numbers) and adding the received prefix. These low numbers are usually from a limited block of numbers (such as 1000) and can be generated without talking to the database. Once the client drained its number pool, it can request another prefix from the server. This reduces the amount of interaction between the database and back-end significantly and therefore improves performance.
RDF representation. The graph model can be exported to RDF via the Neo4j Semantics extension 6 . Due to the differences between our graph model and RDF, a "semantification" needs to occur. Most 6 https://github.com/jbarrasa/neosemantics importantly, the ORKG back-end auto-generates URIs for the data. Mapping (or changing) these URIs to an existing ontology needs to happen manually. The Semantics extension also allows importing RDF data and vocabularies. Hence, existing vocabularies can be imported, modified and extended. Unfortunately, only a subset of OWL is supported, e.g., the reasoning capabilities are very limited at this point and mainly comprise sub-class inference. The query language for the imported data is Cypher, i.e., Neo4j's native query language, as there currently is no support for SPARQL. However, we plan to add SPARQL support in near future based on our work for a query algebra for graph data [37] and the existing implementation for the Gremlin graph query language [38].
Data retrieval and querying. The back-end is exposed via a simple RESTful API 7 to be used by the front-end (User Interface). Data is queried by sending HTTP requests and is returned in JSON format. This allows other applications to talk to the database and work with data in ways other than those we anticipate. This decoupling also allows for greater flexibility while the project is still in development. A technical documentation of the current API specification is accessible online 8 .
Provenance and authentication. The back-end takes into consideration provenance information as metadata on the statements created, such as when and by whom an entity was created. Users will be able to authenticate against ORKG using single sign-on (SSO), e.g., using ORCID. This greatly lowers the entry barrier, fostering collaboration. It also allows us to implement more sophisticated role management.
Linking to other services. In order to enrich ORKG data with other metadata, it will be possible to load or link data from other sources, such as Crossref. A key requirement is to have connection points, such as DOIs. Although bibliographic metadata about scholarly communication is important, building yet another scientific information system is out of the scope of this project. Rather we aim to link and integrate other systems (e.g. DataCite, CrossRef) and their information via identifiers such as DOI, ORCID etc.
Community engagement and development. Interested parties will be able to use and test the infrastructure via the ORKG beta service, a deployment of the latest version of the ORKG. It will support requesting feedback on features early and allow for the project to be guided by the requirements of its users.
Due to the experimental and fast-changing nature of the project, it is vital to provide technical documentation to interested developers. We will also provide an easy way to download and run the ORKG infrastructure for local experiments, e.g., as a Docker image. This will allow interested parties to get a first glance at the technology and spark interest to contribute to the project with software. For an in-depth explanation of the ORKG architecture and technology used, written documentation and developers communication boards will be provided on platforms such as GitLab or GitHub.

Graph Curation and Exploration User Interface
The user interface (UI) facilitates access to the knowledge graph, by providing the ability to search, browse, create and modify the existing research contributions. The user interface was built with the following two key requirements in mind: (1) Usability (i.e., easy to use) to focus on the ability to allow all (co-)authors from any discipline to use the system without any previous knowledge or training on the system and (2) Dynamicity of the system to adapt descriptions of the scholarly data in a way that allows the user to control data curation with a maximum degree of freedom. The user interface design was inspired by the Wikidata project-the central community-created data management platform of Wikipedia [14,40]. The goal of the UI is to provide users with a wizard that guides them in creating graph-based representations of research contributions. This design choice reinforces with the usability requirement of the system. The UI is written in compliance with the ES6 standard of JavaScript using the React framework. The Bootstrap framework is used for responsive HTML design and user interface components.
Scholarly contribution curation. The system allows users to add new scholarly contributions, initially via a DOI using the Crossref infrastructure or by adding all information manually. The user can add new properties or select them from a list via the autocomplete feature. Afterwards, the created property will be linked to a resource either a newly created one or a resource already existing in the graph. The ORKG supports two types of resources (Literals, and Linked resources). Furthermore, the user of the application can edit values of the inserted scholarly contributions, at the resource level or the predicate level. The curation aspect of the system relies on the dynamicity requirement of the user interface to be able to provide a dynamic environment to collect all possible data of the contributions. Figure 6 exemplary shows selected attributes of the "Quick Sort" algorithm contribution with the possibility to edit the information and add new values (i.e., resources and literals). 9 Search and Exploration. To support exploring contributions, the main page lists all available resources. Navigation links to check resources and predicates support narrowing down the field of exploration. Furthermore, for quick access, functionality is available to search for any resource or a predicate via their labels. Each resource in the ORKG is expandable and can be explored to see what other resources are related to it. The relationships are displayed in subject-predicate-object form (similar to RDF triples), whereby the subject is the current research contribution, the predicates are presented in separate blocks on the left, and the related objects are grouped on the right side of each block.
State-of-the-art comparison. One major feature of the ORKG is the ability to perform a state-of-the-art comparison quite easily and quickly. The user can select a scholarly contribution and then compare it to all other contributions in the knowledge graph addressing the same research problem, ranked by similarity. Figure 4 depicts an example of comparing the resource Quick Sort to other known contributions. As a result, the system produces a table showing contributions with a similarity value. The resulting table shows the most common characteristics or properties between the evaluated contributions in an interactive manner that supports sorting the values to obtain deeper understanding of the connections.

EVALUATION
In this section, we detail the aims and outcomes of the evaluation process. For the initial user evaluation, we followed a qualitative approach to identify major (positive and negative) issues and what users perceive when working with the system. The evaluation process had two components: 1) Instructed interaction with the system and 2) A short evaluation questionnaire.

Instructed User Interactions & User Survey
In order to evaluate the system, instructed interaction sessions were conducted with 12 participants (authors from different disciplines such as Computer Science, Data Science, Biology, Life Science) during the 13 t h International Conference on Data Integration in the Life Sciences 2018 (DILS2018) 10 . The aim of these interactions was to get first-hand observations and comments on our approach. Thus, this was the first prototypical implementation in which participants had to semantically describe their DILS papers, thereby creating ORKG content. The interaction sessions were conducted with the help of two instructors. At the start of each individual interaction sessions, the instructor explained the underlying principles of the system in two minutes, including how the system works and what is required of the participant to complete the session. Consequently, participants engaged with the system without any further guidance from the instructor. However, they were allowed at any time to ask the instructor for assistance. The completion time was recorded for each participant, together with the instructor's notes and the participant's comments on the interaction session. Timing was critical to establish the typical length of a user interaction, due to the fact that our system is expected to be integrated with manuscript submission systems and therefore should require little time. The interaction notes, participant's comments and the time recordings were analyzed together with outcomes of the user survey.
As an addition to the instructed interaction sessions, participants were invited to fill out a short evaluation survey. The aim of this questionnaire was to provide further insights into how users from 10 https://www.springer.com/de/book/9783030060152 different scientific disciplines experienced the system (e.g., comprehensiveness of terminology used, user-friendliness, UI design). The questionnaire was thus treated as a qualitative instrument, since the data was insufficient to establish any correlational or causal relationship [24]. This short user survey was pen and paper-based, and contained altogether 11 items. The items were designed to complement participant reactions to the system following their instructed interaction session, so that they could more deeply reflect on the aspects they found critical (both positive and negative) about the system. Participants filled out their surveys after the instructed interaction session. All 12 participants answered the questionnaire. The survey is available online 11 .

Results
As a result of the interaction and survey data (descriptive) analysis, we obtained a number of major topics, which received significant attention from the users.
(1) Difficulties with the HCI 12 Overall, participants found the system to be fairly easy to use, especially after receiving some explanation or examples. 75% of the participants found the UI fairly intuitive and easy to use, while 10% did not need any guidance, with 80% of the participants needed guidance only at the beginning. With regards to the user interface, five out of twelve participants suggested to make the UI more keyboard-friendly, for instance by adding a simple guiding wizard through the UI. As participant #3 stated: "More description in advance can be helpful". Two participants commented that the navigation process throughout the system is complicated for first-time users, and suggested other ways that could be done easier. As an example, participant #5 suggested to "Use breadcrumbs to navigate". Moreover, the timing of the participants averaged approximately 17 min with a maximum of 22 min and a minimum of 13 min. (2) Visualisation of the Knowledge Graph Four participants demanded visualization (i.e., graph chart) to be available when creating a sub-graph. For instance, participant #1 commented that "It could be helpful to show a local view of the graph while editing". This type of visualisation would facilitate the comprehension among users from multiple disciplines. Another participant suggested that we integrate a document (PDF) viewer within the application to highlight relevant passages or phrases for the user. Participant #4 noted the that "If I could highlight the passages directly in the paper and add predicates there, it would be more intuitive and save time". (3) Availability of vocabularies for curation Two participants commented on the use of a controlled vocabulary to guide the curation process. A vocabulary would make the process more fluent and intuitive. Focusing on the UI aspect, participant #6 suggested to "show an overview of the existing ontology to avoid a lot of new properties and objects".
Further details on the survey are presented in Table 2, giving an overview of how participants rated the main items of the survey.  much  in mins   1  4  4  5  3  2  6  16  2  2  3  5  4  8  7  19  3  4  5  5  3  9  7  15  4  3  3  5  3  6  7  13  5  4  3  5  3  6  8  14  6  4  3  5  3  8  9  13  7  3  4  5  3  7  6  19  8  3  2  4  3  8  6  13  9  4  5  3  3  7  5  14  10  4  5  5  1  8  8  22  11  4  5  5  1  8  8  20  12 - Table 2: Overview of answers on the most important concepts in the evaluation survey Again, the results do not provide statistical relevance since the cohort of participants is too small for statistical conclusions. However, the results provide a number of suggestions users indicated to be critical when using the ORKG, and what aspects of the UI and the interaction with the system in general should be improved. Table 3 shows a sample (for the sake of readability) of the usecase data collected during the evaluation of the ORKG with the participants of the international DILS 2018 conference. This table shows the data grouped into four main categories. Research Problem, which indicates what is the main problem or issue that the publication is addressing. Participants used a variety of properties when expressing the problem such as "Problem, Addresses, Focus, Subject, Proposes, and Topic". Approach shows what is the solution or approach taken to face the problem. For instance, the information about the approach was delivered through "Approach, Uses, Prospective work, Method, Focus, and Algorithm". Implementation is one of the most comprehensively described aspects in this study, arguably because it was easier for participants to describe technical details as concepts compared to describing the problem or the approach. Implementation is presented with two columns, one for the property (describing the implementation) and the other for the respective value. Evaluation is the last category participants filled, and is constructed in a similar manner as implementation. The complete dataset obtained in the case study is available online 13 .

DISCUSSION
With this first-hand experience of the ORKG, we were able to put multiple aspects of the system under scrutiny, better understand how users interact with the system, and obtain data and feedback on interaction and user experience. During the evaluation, the main focus was the user interface and how users found it throughout their experience. Since the user interface is the only aspect of the system that the participants would interact with, the survey was directed to certain aspects of user interaction. Early results showed that the system achieved some of the required objectives by being easy to use and capable of adapting to the collected data regardless of the discipline or the domain. The results of the survey ( Table  2) show how the participants reacted to each descriptive concept 13 https://doi.org/10.5281/zenodo.2549916 that we are looking for. Most of the results are above half, except the Guidance needed which shows that most participants did not really need the guidance to use the system, reinforcing the usability requirement of the user interface. All case study participants displayed an interest in the ORKG and provided valuable input on what should be changed, added, or removed. Furthermore, the participants suggested to integrate the system within libraries, universities, and other institutes allowing everybody to exploit the potentials and benefits of the system on a larger scale.
Finally, we highlight an important limitation. Since the ORKG relies on people to curate the data (i.e., expert crowd-sourcing), the process to convert a document-based contribution to a machinereadable model is remains challenging. Difficulties arise when trying to conceptualize key aspects of the scholarly contribution, such as problem or approach. Participants in the case study found this task quite challenging and time-consuming.

RELATED WORK
Representing encyclopedic and factual knowledge using RDF and Linked Data is increasingly feasible. This is underscored by knowledge graphs such as DBpedia [2], Wikidata [41], and Yago [21] as well as industrial initiatives like Google, IBM, Bing, BBC, or Thomson Reuters.
In the library and scholarly communication context, much work has so far focused on representing and managing bibliographic metadata while the formal (i.e., machine readable) representation of scientific information communicated in scholarly literature has received very little attention, with the exception of few initiatives such as the Semantic Publishing and Referencing (SPAR) Ontologies [30] which, however, focus primarily on metadata and to some extent on document structure.
There has been some work on enriching various document formats with semantic annotations. Examples include Dokie.li [9], RASH [31] or MicroPublications [11] for HTML and SALT [18] for LaTeX. We started representing key findings of survey articles focusing on semantically describing research problems, approaches, implementations and evaluations in [15] and integrating bibliographic information in a knowledge graph [33].
Other work focused on developing ontologies for representing scholarly knowledge in specific domains, for example, mathematics [27], the RXNO ontology in chemistry or the OBO Foundry ontologies [34] in the life sciences. A knowledge graph for science must go beyond such efforts, by enabling the parallel and synchronized creation, curation, and augmentation of both terminological/ontological as well as assertional and discourse knowledge. For representing provenance and discourse we can build on the PROV ontology [28] and Document Components Ontology [12].
While there has been work on argumentation and reasoning in AI (e.g., [4,17]) and philosophy (often using specialized formalisms), more work needs to be done to represent argumentation, concept drift, and scholarly knowledge evolution in knowledge graphs.
The RDF data model and respective ontologies arguably appear adequate as a scaffold for representing scholarly knowledge. However, aspects such as provenance, evolution, and discourse are more difficult to represent in pure RDF (see the ongoing discussion about reification  such as RDF singleton properties [42], which can be used for representing and exchanging semantic data, we need to investigate more how graph data management techniques (e.g., using the Gremlin graph query algebra [22]) can be employed to store and manage the extremely large amounts of interconnected scholarly communication data and metadata. Hence, we argue that a knowledge graph for science can be build but must extend the triple (or quad) data model of RDF. The scholarly communication community has initiated numerous related projects. The Research Graph [1] is a prominent example of an effort that aims to link research objects, in particular publications, dataset, researcher profiles. The Scholix project [8], driven by a corresponding Research Data Alliance working group and associated organizations, aims at standardizing the information about the links between scholarly literature and data exchanged among publishers, data repositories, and infrastructures such as DataCite, Crossref, and OpenAIRE.
Other related projects include Research Objects [5], which proposes a machine-readable abstract structure that relates the products of a research investigation, including articles but also data and other research artefacts, as well as the RMap Project [19], which aims at preserving "the many-to-many complex relationships among scholarly publications and their underlying data. "

CONCLUSION AND FUTURE WORK
This article describes the first step of a large research and development agenda. We suggest that the transition to knowledge-based information flows is an absolute imperative in order to adapt scholarly communication to the digital world. This article describes a first complete iteration of the knowledge graph based scholarly communication concept: We described a knowledge-graph based data model, which uses RDF as a scaffold, but adds important features for provenance tracking and annotation. The data model is implemented in a graph database back-end. We also showcased a first prototypical implementation of the user interface, which provides three core features: curation of the scholarly knowledge graph, exploration and retrieval as well as comparisons of approaches for reviewing the state-of-the-art in a certain field. We performed an initial evaluation of the concept and implementation with the participants of the recent Data Integration in the Life Sciences conference.
As the next step, we aim to significantly improve the individual components of the ORKG architecture. For the data model, we aim to introduce the concept of knowledge molecules. They provide reusable, compact, relatively simple, structured units of knowledge, e.g., to represent research problems and contributions. With this, we aim to lay the foundation for a novel quality of (cognitive) knowledge graphs that are better at representing conceptual entities (in addition to the factual ones currently being dealt with by knowledge graphs). We also expect that such a novel concept of cognitive knowledge graphs will be better at dealing with semantics emerging from large scale collaboration as well as concept drift. On the user interface side, we aim to integrate more strategies for crowd-sourcing and human-machine cooperation, where researcher are enabled to contribute their research descriptions using flexible and lightweight widgets that are able to be tailored for the specifics of different disciplines. We plan to integrate an automatic analysis of textual research articles, to provide recommendations for the manual curation of the ORKG. The more contributions and descriptions are available, the more automated techniques using the existing representations as training data can be integrated. Finally, we aim to scale the case studies to larger venues and communities to experiment with various research areas and their representations and refine the authoring, curation and exploration techniques. In particular, we have to realize more applications that provide direct value to researchers, while or after contributing their descriptions, to ultimately render a network effect and thus make the ORKG comprehensively reflecting the world's scientific knowledge.


ChainSplitter: Towards Blockchain-based Industrial IoT Architecture for Supporting Hierarchical Storage

The fast developing Industrial Internet of Things (IIoT) technologies provide a promising opportunity to build large-scale systems to connect numerous heterogeneous devices into the Internet. Most existing IIoT infrastructures are based on a centralized architecture, which is easier for management but cannot effectively support immutable and verifiable services among multiple parties. Blockchain technology provides many desired features for large-scale IIoT infrastructures, such as decentralization, trustworthiness, trackability, and immutability. This paper presents a blockchain-based IIoT architecture to support immutable and verifiable services. However, when applying blockchain technology to the IIoT infrastructure, the required storage space posts a grant challenge to resource-constrained IIoT infrastructures. To address the storage issue, this paper proposes a hierarchical blockchain storage structure, \textit{ChainSplitter}. Specially, the proposed architecture features a hierarchical storage structure where the majority of the blockchain is stored in the clouds, while the most recent blocks are stored in the overlay network of the individual IIoT networks. The proposed architecture seamlessly binds local IIoT networks, the blockchain overlay network, and the cloud infrastructure together through two connectors, the \textit{blockchain connector} and the \textit{cloud connector}, to construct the hierarchical blockchain storage. The blockchain connector in the overlay network builds blocks in blockchain from data generated in IIoT networks, and the cloud connector resolves the blockchain synchronization issues between the overlay network and the clouds. We also provide a case study to show the efficiency of the proposed hierarchical blockchain storage in a practical Industrial IoT case.

I. INTRODUCTION
Internet of Things (IoT) is a paradigm that heterogeneous physical objects are interconnected through wired or wireless technologies, and further seamlessly connected to the Internet, enabling anywhere and anytime connectivity [1]. In recent years, we have witnessed the wide adoption of IoT applications across a variety of industry sectors [2], including manufacturing, home automation, transportation, and healthcare, to name a few. Most existing large-scale industrial IoT (IIoT) infrastructures nowadays are developed, deployed and maintained by individual parties. They are typically cloud-based and rely on centralized communication models [3], in which all devices are identified, authenticated, and connected through cloud servers that provide abundant computation and storage capacities.
Along with the rapid growth of the size and complexity of IIoT networks, centralized IIoT solutions however are becoming more expensive due to the high deployment and maintenance cost associated with the network and cloud infrastructures [3]. This problem is further exacerbated by the growing demand that IIoT networks from different parties should be able to communicate and collaboratively provide immutable and verifiable data. With traditional IIoT networks, data provided by individual industrial parties may not be trustworthy because they can be forged or modified by attackers or the owner of the data [4]. It is desirable to have mechanisms to verify the trustworthiness of data in IIoT networks.
Considering these requirements of IIoT networks, the emerging blockchain technology can serve as a promising candidate to provide immutable and verifiable services [5]. Blockchain is a distributed data structure comprising a chain of blocks which is based on a decentralized peer-to-peer (P2P) network. It removes the need of a central controller, and also allows parties to transact even though they may not trust specific individuals. By introducing the blockchain technology into IIoT solutions, the management of numerous unspecified devices and processes -including transactions and communications among the devices -will become much easier. Cryptocontract (e.g., self-executing, self-enforcing protocols) among IIoT devices can be recorded on blockchain as a smart contract [6] and executed automatically to greatly improve transaction efficiency [1].
The blockchain technology, however, cannot be directly incorporated into existing IIoT solutions, given the extremely constrained resources in IIoT networks, and the requirement of the blockchain technology that each participant must keep an exact copy of the blockchain to guarantee the consistency. For example, Bitcoin is one of the most successful blockchain-based applications to date. The Bitcoin blockchain, even though not updated frequently, currently contains more than 190GB of data, of which only some are related to currency transfers. Compared with Bitcoin, most large-scale IIoT systems generate much larger data volumes, and it is simply infeasible to store all the blocks in local IIoT networks. It is thus important to remove layers of inefficiency from the traditional storage structure in blockchain and design a new method which can scale out.
Motivated by these challenges, this paper presents a blockchainbased IIoT architecture, which uses the blockchain as a distributed ledger to maintain records of all transactions in the IIoT networks. The proposed architecture separates the IIoT infrastructure into three layers: local IIoT networks, the blockchain overlay network, and the cloud infrastructure. To address the storage challenges in IIoT networks, a novel blockchain storage structure is proposed to store the blocks in a hierarchical manner: the majority of the blockchain is stored in the cloud to leverage its abundant storage capacity, while the most recent blocks are stored in the overlay network of the individual IIoT networks. As the blocks continue to be appended to the blockchain, the percentage of each part is maintained dynamically, depending mainly on two factors: the size of the current blockchain and the size of the storage (e.g., disk) provided on consensus nodes. To seamlessly connect these three layers, the design details of two connectors, the blockchain connector and the cloud connector, are also presented. The blockchain connector in an overlay network prepares blocks from transactions (data generated in IIoT networks), and the cloud connector addresses the blockchain synchronization issues between the overlay network and the clouds. The rest of the paper is organized as follows. Section II presents the existing cloud-based IIoT infrastructure. Section III discusses the opportunities and challenges to integrate the blockchain technology into IIoT solutions. Section IV presents the proposed blockchainbased IIoT architecture and the proposed hierarchical blockchain storage structure. Section V and Section VI describe the functionalities of the blockchain connector and cloud connector, respectively. Section VII provides a case study in one IIoT scenario to show the efficiency of the proposed framework. Section VIII summarizes the related work. Section IX concludes the paper and discusses future work. Fig. 1 gives an overview of a typical cloud-based IIoT infrastructure, which mainly consists of three layers: device layer, gateway layer and cloud service layer. The device layer comprises heterogeneous IIoT devices, varying from powerful computing units to extremely low-power microcontrollers. These devices are connected to the gateway layer through various wired and wireless networking technologies, such as ZigBee, BLE, Ethernet, etc. At the gateway layer, most companies and organizations deploy their own customized gateways to manage the local IIoT networks, aggregate the data, and serve as the bridges to the clouds [7] [8]. These customized gateways are usually an integral part of the deployed IIoT infrastructure, which leads directly to "stovepipe" solutions [9]. This further causes the interoperability issues, that is data and services provided by one organization cannot be shared or utilized by devices from the other organizations (due to different networking protocols, data formats, etc.), and the employed security mechanisms are often proprietary and undocumented.

II. CLOUD-BASED IIOT INFRASTRUCTURE
For easy understanding and presentation, we use "IoT" to represent "IIoT" in the following description.
Traditionally, the device layer and gateway layer together form the local IoT networks. A typical local IoT network consists of the following four components (as shown in the left of Fig. 2

):
IoT Devices: Most IoT devices are deployed in the physical world to measure and sample their associated physical or cyber objects. They have constrained resources, including memory size, computation power, and communication bandwidth [10]. In addition, the devices and their adopted networking technologies are highly heterogeneous. This heterogeneity posts a grant challenge in interconnecting IIoT devices. It requires the interaction among the IoT devices to put the interoperability at the first place, such that heterogeneous devices are transformable in user's acceptable forms for both syntax and semantics [11].
IoT Storage: In a local IoT network, a centralized storage scheme is commonly adopted to manage the IoT data, instead of either local schemes (e.g., storing data within the local memory of IoT devices) or distributed schemes (e.g., storing data within some nodes with rich storage resources in the network). In a centralized storage scheme, the data are collected by the local gateway, and then sent to and stored in a local centralized storage. In our scheme, the local centralized storage could be either a historian or a private data center, in which all data are stored locally and privately. This centralized storage within a local IoT network can provide faster access to the recent data without accessing the cloud. Where and how the local storage is deployed in the local IoT network depends on the system design specification.
Data Engine: The data engine is a software component that transforms incoming and outgoing raw data to and from the IoT devices into required forms. For example, in the proposed blockchain-based IoT architecture to be elaborated in Section IV, raw data are formed as transactions, and encrypted and uploaded to the clouds upon requests. The data engine can be deployed on the gateway or a stand-alone computing facility in the local IoT network. To guarantee the security in the local IoT network, the data engine also provides additional services, such as key management (e.g., distributing and updating keys to secure data transfer in local IoT network) and security mechanisms (e.g., authentication, authorization and audit services).
Gateway: In a typical cloud-based IoT infrastructure, the gateway is a connection entity that links the local IoT network to a cloud. In our proposed blockchain-based IoT architecture in section IV, the gateway plays two main roles. On one hand, it is the sink of the local IoT network, providing data management and network management functions; on the other hand, it also serves as a P2P node on the blockchain overlay network, providing proxy functions, such as routing information provisioning, node authentication, and multicast group management [12].
In addition to the device and gateway layers, the cloud service layer provides cloud-related functionalities, such as database service and application service, to manage the data provided by the local IoT networks. Both the local IoT networks and the cloud service layer together comprise the most common existing cloud-based IoT infrastructure.

III. OPPORTUNITIES AND CHALLENGES TO INTEGRATE BLOCKCHAIN INTO IOT
Blockchain, based on a decentralized P2P network and integrated with cryptographic processes, can offer many new features and improve existing functionalities of IoT systems. Since blockchain is built for decentralized environments, its security scheme is more scalable than traditional ones, and its strong protections against data tampering will help prevent rogue devices. The following features of the distributed architecture of blockchain make it an attractive technology for addressing many of the security and trust challenges in large-scale IoT systems [13].
• Blockchain can be used to trace the measurements of IoT devices and prevent forging or modifying data.
• The IoT devices can exchange data through a blockchain to establish trust among themselves, instead of going through a third party. This significantly reduces the deployment and operation cost of IoT applications.
• The distributed ledger structure of blockchain eliminates a single source of failure within the IoT ecosystem, protecting the IoT devices' data from tampering.
• Blockchain enables device autonomy via smart contract, individual identity, integrity of data, and supports P2P communication by removing technical bottlenecks and inefficiencies.
• Configuration of IoT devices can be complex, and the blockchain can be well adapted to provide IoT device identification, authentication and seamless secure data transfer.
Blockchain technology has enormous potential in creating trustless decentralized IoT applications, and provides lots of advantages from the technical perspectives. However, blockchain technology is still in its early stages, and there exist many barriers that limit the current blockchain technology from being applied to IoT applications.
One of the most challenging problems is the storage issue when integrating the blockchain technology into IoT applications. In IoT scenarios, IoT devices can generate a huge amount of data in a short period, and both the data hash and the data itself need to be stored 1 . When a blockchain grows over time, all participating nodes will need larger storage capacity and higher bandwidth to keep up-todate with the transactions added to the ledger, which is potential to become very costly. In this paper, we focus on solving the limited storage issue when introducing blockchain into the traditional cloudbased IoT architecture. In the following, we first use a heuristic case study to illustrate the significance of the blockchain storage issue. Among many research topics emerging from the blockchain technology, Bitcoin is one of the most successful implementations of blockchain [14]. A Bitcoin block consists of a block header with a size of 80 bytes and a list of transactions as block payload (or block body) [15]. And both block header and block body are included into the block. Although the size of the block header is small, one of the major drawbacks of the existing Bitcoin witnessing scheme is that the auditors have to download the entire Bitcoin blockchain. As of November 2018, the Bitcoin blockchain contains more than 190GB of data, and it grows by 52GB every year [16] [17] [14]. It is a challenging task if not impossible to download and store the whole blockchain in resource-constrained IoT gateways. Thus, a more efficient blockchain storage structure is desired.
To better describe this challenge, we provide a numerical comparison, regarding the storage issue, between Bitcoin and a medium-size Industrial IoT (IIoT) system. In Bitcoin, the block size is currently limited at 1MB. The average size of a Bitcoin transaction, in one week of February 2019, is around 500 Bytes [18]. Considering that the average number of transactions per block is 2000, and a Bitcoin block is generated by the miner around every 10 minutes, in every second it has 3.33 transactions generated within the Bitcoin network and thus the average data volume is 1.67KB per second, which is pretty mild. On the other hand, the comparing IIoT system is based on Emerson Wireless Industrial Automation Systems [19]. We evaluate an industrial plant which has many wireless sensor and actuator networks (WSANs) deployed. We choose a medium-size system to estimate the average data volume, which consists of 50 WSANs, each having 100 nodes. We assume the average device sampling period is 1 second and the average message size is 100 bytes 2 . This leads to an average data volume of 500KB per second.
Assuming the block size is limited at 1 MB, from the above comparison, we have the observation that, in one week, the average block volume generated from Bitcoin network is about 1 GB, while the average block volume generated from the medium-size IIoT system is 302.4 GB, which is a huge amount of data that certainly cannot be stored in local IoT networks. It is worth noting that the required data for immutable and verifiable services are application dependent. Typically, these data will be stored at least one year in the industrial case.
In our proposed hierarchical storage structure for blockchainbased IoT systems, this issue can be addressed by a layered structure, where a blockchain overlay network is inserted in between the local IoT networks and the clouds. Resource-constrained IoT nodes only store a small portion of the blockchain that they need for their own transactions, while the majority of the blockchain is stored on the clouds. To ensure that this proposed layered structure work properly, interfaces (also called connectors in this paper) between the layers need to be carefully designed. In the following, we first present the blockchain-based IoT architecture with hierarchical storage structure, and then describe the two designed connectors, the blockchain connector and the cloud connector.

IV. BLOCKCHAIN-BASED IOT ARCHITECTURE
The proposed blockchain-based IoT architecture, as shown in Fig. 2, consists of three layers: local IoT networks, the P2P blockchain network, and the clouds. We first take a bottom-up approach to describe the key components of each layer, and then present the design details of the proposed hierarchical blockchain structure to mitigate the issue of storage capability.
A. System Architecture 1) IoT Network: In addition to their routine functions (see Section II), the key added task of local IoT networks is to prepare transactions from the massive raw data collected from the network. Due to the heterogeneity of devices and applications in local IoT networks, the data need to be formatted and encrypted in a consistent format, so that the generated transactions can be easily operated and chained together in the blockchain overlay network. These operations are mainly done in the data engine. To seamlessly assemble the transactions into the blocks, the proposed architecture employs a blockchain connector to serve as the interface between the IoT network and the overlay network (see Section V for the details). The blockchain connector provides the functionalities to secure the transactions and the mechanisms to manage the devices access. Within the IoT network, this can be achieved by deploying a security platform to guarantee the authenticity of raw data from the authorized IoT devices. For example, in Emerson's blockchain project, it leverages the Mocana Security Platform [20], which is based on trusted hardware, to ensure the security of transactions. Note that the proposed blockchain-based IoT architecture assumes that, by utilizing the security platform, securing and transferring the raw data into transactions happen in the local IoT network. The trust and security of local transactions can be guaranteed via security platform in a centralized and private manner. And, the gateway, as a peer in the overlay network, sends the prepared transactions to the overlay network. After obtaining the transactions, it is the responsibility of the overlay network (via the peers) to create blocks, verify blocks, and chain the blocks together.
2) Overlay Network: After the transactions are published from the local IoT networks via the gateways, nodes in the P2P overlay network are responsible for forming the blockchain. The use of a P2P overlay network can provide several desirable features, such as scalability, high availability, and self-configuration [21]. The gateways of local IoT networks are organized as peers of the P2P overlay via Blockchain Connectors (see Section V for the details), which provide an efficient relay to construct the blocks from the transactions. The proposed architecture assumes that the overlay network follows the specified blockchain consensus protocols, e.g., PoW (Proof-of-Work) or PoS (Proof-of-Stake) [22], or Byzantine Fault Tolerance (BFT) schemes [23], depending on different IoT applications. Roughly speaking, BFT-based protocols do not have double spending issues, which is more suitable for industrial IoT.
Industrial IoT scenarios typically adopt a permissioned setting, which is operated by the known entities and imposes more stringent access control. BFT-like consensuses have been widely investigated in permissioned blockchain [24] with the aim of outperforming PoW while ensuring adequate fault tolerance and faster finality of transactions. We assume the overlay network adopts a BFT protocol to achieve consensus process, such as scalable BFT for industrial secure metering [25]. And the threat model follows the definition in [25], i.e., Byzantine nodes are less than 1/3 of the total participating nodes.
3) Clouds: By connecting the local IoT networks to the clouds, the IoT applications benefit from the virtually unlimited computing and storage resources of the cloud to compensate for its technological constraints (e.g., limited storage size, processing capability, and communication bandwidth). In our proposed architecture, the blockchain overlay network serves as the bridge that connects local IoT networks and the clouds together. To smoothly connect the overlay network to clouds, besides the basic functionalities of the cloud service layer (e.g., data storage, data management, etc.), the proposed architecture requires an additional bridging component, referred as cloud connector to resolve the blockchain synchronization issues between the overlay network and clouds. The design details of the cloud connector will be presented in Section VI.
Notice that the clouds in our architecture are not maintained by a single group or entity. Instead, the clouds are organized as a decentralized cloud storage, in which there not exists a single operator. To ensure the data consistency among the clouds, our scheme needs a decentralized object storage system to manage these clouds. Storj network [26] can serve as a promising candidate, which provides a robust object storage that encrypts, shards and distributes data to the distributed nodes for storage. Storj storage management platform provides several key features, such as security and privacy, decentralization and Byzantine fault tolerance [26]. These key features can meet the designated storage requirements.

B. Hierarchical Storage Structure of Blockchain
As stated in Section III, how to store the blockchain for largescale IoT applications is a critical issue. In the original design of blockchain, every participating node has to store all the blocks locally. This storage mechanism is prohibitive when applying to large scale IoT applications, and a new structure needs to be devised to address the storage issue. The main purpose of this paper is to handle the storage issues via hierarchical structure. Before we present the proposed hierarchical storage structure for blockchain, we first make some assumptions on the overlay network. For example, assuming BFT algorithm as the underlying blockchain consensus protocol, the adopted BFT protocol should be robust enough to deal with a large number of participating nodes, and the ratio of Byzantine nodes is less than 1/3.
To address the storage issue in the proposed blockchain-based IoT architecture, we adopt a hierarchical storage structure in which the blockchain data, or chain of blocks, are stored separately at two locations: the majority in the cloud storage and the latest portion in the peer nodes of the overlay network. Note that the local IoT networks might have the ability to store or download the blockchain, but it is not required in this proposed architecture. We assume that the main task of the local IoT network is to collect raw data generated from IoT devices and construct transactions.
The constituent nodes in the overlay network, known as overlay nodes, can be either the IoT gateways or other powerful devices with much richer computing and storage resources, such as highperformance computers. The main task of the overlay nodes is to generate valid blocks that can be added into the blockchain. Different from the resource-constrained IoT devices, the overlay nodes have enough local storage to store a small portion of the blockchain, which is needed for computing new blocks and keeping them before sending them to the cloud.
To reduce the storage requirement, the overlay nodes only store the latest portion of the blockchain locally, and have the rest of the blocks in blockchain stored in the clouds. Fig. 3 shows an overview of the proposed blockchain structure. It consists of three major parts: the first part is to deal with transactions in a centralized and private manner (e.g., information processing in gateways); the second part is to form the blocks according to the most recent blocks in a P2P overlay network (e.g., following consensus protocol); the last part is the majority of blocks stored in the cloud. The authorized parties can access the data from the cloud and provide various smart services for IoT applications [27]. In our proposed hierarchical storage architecture, blocks can be uploaded and stored (or we can say synchronized) in multiple clouds while ensuring their consistency. The main purpose of using the cloud to store the blockchain data is to meet the storage capacity requirements from the large-scale IoT applications. Storing blocks in multiple clouds can prevent attacks where the data in a particular cloud (or a small set) are modified, if we assume most clouds are honest. The proposed scheme uses Storj storage, a distributed and decentralized cloud storage platform, to distribute and manage the data blocks in the clouds. Besides, other decentralized cloud storage platform can be used as a potential solution, such as IPFS file systems [28], to manage the data.
To seamlessly connect the hierarchical storage together, we need to define two interfaces (alternatively called connectors) to integrate these three layers together. The blockchain connector in an overlay network prepares blocks from transactions (data generated in IoT networks), and the cloud connector addresses the blockchain synchronization issues between the overlay network and the clouds.

V. DESIGN OF THE BLOCKCHAIN CONNECTOR
The blockchain connector can be viewed as a middleware in the proposed architecture, residing on the overlay node. It has several essential functions to securely generate the blocks and chain them together. The functions include permission management, access control, transaction validation, data signature, and chain forming. In the following, we will describe these functions in detail. Note that the functionalities of the blockchain connector can be further extended to meet the requirements of different IoT applications.

A. Permission Management
Blockchain connector functions as an interface to the overlay network, and its permission management mainly serves to the local IoT network. In general, blockchains can be classified into permissioned and permissionless blockchains [29]. In a permissioned blockchain, the permission management is required to manage the identity of its participants via certain procedures, such as whitelists or blacklists. In contrast, the participants in a permissionless blockchain are either pseudonymous or anonymous, like Bitcoin and Ethereum. However, using anonymous validators increases the risk of Sybil attack [30], where the attacker gains a disproportional amount of influence on the system. The protection mechanisms for Sybil attack, such as PoW consensus protocol, is costly and wasteful in permissionless blockchain. In general, the permissioned blockchain is able to legally host identity-related assets, while the permissionless system cannot. Considering the unique features of most IoT applications, the proposed blockchain-based IoT architecture adopts the permissioned blockchain, which can efficiently deal with massive transactions, and only legitimate identities/nodes can construct blocks in the blockchain. Also, most BFT consensus protocols require the permission management for the consensus nodes [23].
Besides the permission of validation, other basic permissions, e.g., joining the network, submitting transactions, aggregating transactions into blocks, and creating assets, can also be managed by the permission management services.

B. Access Control
In a permissioned blockchain, authentication and access control technologies are two critical mechanisms to address the security and privacy issues in IoT applications. With access control, the users of the IoT applications will have full access to their data and have control over how the data will be shared. The user can assign a set of access permissions and designate who can query their blockchain. The access control permissions can be flexible and handle more than "all-or-nothing" permissions [31]. Similar to permission management, the access control mainly targets to its local IoT network, and in a blockchain network, there no exists a centralized controller or authenticator.
Many existing access control mechanisms can be adopted in the blockchain connector. For example, in [32], the authors proposed an automated access-control manager using blockchain that does not require trust in a third party. The access-control manager ensures that users own and control their personal data and can perform the fine-grained access control, i.e., altering the set of permissions and revoking access to previously collected data. In [33], the authors developed the ChainAchor system which can address the issues of identity and access control within the shared permissioned blockchain. ChainAchor can provide access control to entities seeking to submit transactions to the blockchain to read/verify transactions on the permissioned blockchain.

C. Transaction Validation and Data Signature
The mechanism to validate transactions is specific to the blockchain. In general, the transactions are validated via being reexecuted by the nodes that receive the blocks. For instance, the transaction validation mechanisms in Bitcoin rely on two general scripts: locking and unlocking [34]. Its verification scheme is mainly based on Unspent Transaction Output (UTXO) model, which defines an output of a blockchain transaction that has not been spent, i.e. used as an input in a new transaction.
Different from the complex transaction validation in Bitcoin, in IoT scenarios, the main task of the transaction validation is to prevent the data modification attacks in the P2P network. The transaction validation process generally can be divided into two phases: the initial verification and the transaction validation. The initial verification consists of validating the transaction's integrity by hashing the received transaction and comparing its hash against the hash value computed in the data engine. After the transaction passes the hash verification, the transaction validation process is simple; it adds a universal "mark" and the new hash value to the policy header of the verified transaction. Since the verified transaction changes the mark field, it needs to compute the new hash of transaction. As long as the transaction validation finished, the transaction can be replayed to the neighbors. If the transaction fails to pass the validation process, the node in the overlay network might require the same transaction from the same gateway to perform the above validation process again. The validation scheme can set up an upward-boundary to the number of requests for the same transaction to avoid malicious gateways.
Due to the publicity of communication messages and the existence the malicious nodes, it needs to deal with the data's confidentiality integrity and authenticity (CIA) when applying blockchain in IoT systems. The blockchain connector thus requires to sign transactions (as a block) before sending out for verification. The blockchain connector can be implemented on the local IoT gateway, thus the gateway must have the ability to perform the specified signature scheme. This however needs the local IoT gateways to provide the cryptographic primitives to perform the digital signature, such as ECDSA scheme [35].

D. Block and Chain Forming
Another two important functions of the blockchain connector are the block forming and the chain forming. The block forming is used to form blocks from a set of transactions while the chain forming is to chain the generated blocks together to form the blockchain.
Once passing the transaction validation and the transactions are signed, the blockchain connector in a gateway, as a consensus node in the overlay network, can propose blocks from the transactions according to specific rules or smart contract [36]. The verified and signed transactions are then broadcasted, via the blockchain connector, to the overlay network for consensus processes. Typically, devices in an IoT application might generate many transactions at the same time. The consensus node (or gateway) should have enough buffer to store the incoming transactions from all consensus nodes. The blockchain connector gathers the transactions that have been sent out over the blockchain network but have not yet been included in a confirmed block. Depending on the specified consensus protocol, the actual block and chain forming processes might be different. In the designated scheme, we adopt a BFT-based consensus protocol.
We briefly introduce how a BFT-based consensus protocol works for forming blockchain in our setting. BFT is an epoch-based consensus protocol, with the advantage of instant finality. In each epoch, one participating node (or gateway in our setting) is elected to be a leader and the leader coordinates each participating node. To simplify the description, a participating node and a gateway (equipped with blockchain connector) are the same entity as a consensus node in blockchain overlay network. In each epoch, the leader first verifies the integrity of the received transactions, and orders these validated transactions. A set of transactions are bundled together to form a block body, and the leader performs the Merkle tree hash on the block body to get a Merkle Root. The Merkle Root, together with other auxiliary information (e.g., the previous block hash, timestamp), are put into block header. In each epoch, only one leader node can propose the block. Then, this proposed block is broadcasted to each participating node for verification and consensus process. Depending on the adopted BFT algorithm, it might have a different number of communication rounds among the participating nodes and leader. Typically, the blockchain connector can implement a smart contract to order these transactions, and the blockchain connector maintains the latest block he knows. Once the block is confirmed among the honest nodes, this block is added to the blockchain of each consensus node and the blockchain connector updates its latest block information for the next epoch block forming.
In case of the malicious leader, the consensus process goes into a view-change procedure to elect a new leader. By leveraging BFT consensus, it can ensure the instant finality of blockchain in each consensus round, which is more suitable for IoT scenarios. By the property of instant finality, each consensus node keeps a same copy of blocks among all the honest participating nodes.

VI. DESIGN OF THE CLOUD CONNECTOR
Similar to the blockchain connector, the proposed architecture also defines the cloud connector between the overlay network and clouds, which updates and synchronizes the blocks into clouds. If we take the overlay network as a central element or a black box in the proposed blockchain-based IoT architecture, the blockchain connector serves as an input source from local IoT networks, while the cloud connector serves as an output port to the cloud service layer.
In this section, we focus on the introduction of the functionalities of the cloud connector. The cloud connector deals with the issues on when and how the blocks in the overlay network need to be synchronized to the cloud. In addition, it can provide mechanisms to deal with exceptions, such as the malicious overlay nodes in the overlay network. In general, the cloud connector includes three important components: the request handler, the synchronization engine, and an exception handler, as shown in Fig. 2.

A. Overview of the Cloud Connector
The deployment of a cloud connector is very flexible. It can be either deployed on the overlay nodes (like the blockchain connector), or integrated as a cloud management mechanism in the cloud service layer. Given that deploying the cloud connector in the cloud is subject to the single point failure attack in the proposed architecture, we install the cloud connector on the overlay nodes.
The cloud connector is the interface between the overlay network and the clouds. It mainly includes a unified cloud protocol module for communicating with the overlay network. For secure communication between the overlay nodes and clouds, other mechanisms are still needed to guarantee the security. Here we only focus on when and how to synchronize the blocks in the overlay network to the clouds. From the connectivity perspective between the overlay network and clouds, it is not a good practice to perform synchronization immediately once a new block is generated. Instead, we intend to synchronize the blocks as a group based on the occurrence of certain triggering events or when some predefined time interval expires. Thus, our synchronization mechanism is mainly a hybrid scheme. Meanwhile, we assume that the overlay network always has a network connection with the cloud.
To successfully synchronize the blocks between the overlay nodes and the cloud, the cloud connector needs to have the ability to handle when and how to perform the synchronization process. In the following subsections, the request handler is used to decide when the blocks in the overlay network need to be synchronized to the cloud; the synchronization engine is to deal with how the synchronization is performed; and the exception handler is to handle the potential exceptions during the synchronization process.

B. Request Handler
Different overlay nodes may have different storage for the latest blocks in the overlay network. In the case that there is not too much space for an overlay node to store new blocks, the node broadcasts a message 3 , together with its latest block, to the whole overlay network to notify a request to synchronize the blocks to the clouds. The peer nodes who receive this request check the received latest block with its own latest block. If both blocks are the same, the peer sends an "agree to synchronization" response to the current leader. As long as the leader receives the same "agree to synchronization" response from more than 2/3 total peers 4 . Then, the leader agrees to this synchronization request and broadcasts the aggregated response information (e.g., who vote to this synchronization). This process is actually a round of BFT consensus process. Note that each communicated message is signed by its sender, thus even a malicious leader cannot compromise the decision of synchronization from other nodes. After the synchronization process among the overlay nodes, each overlay node has the same blockchain, which indicates that the last block in each overlay node is the same. To prevent the flooding attack by malicious nodes, we assume there exists a minimum storage capacity for individual overlay nodes so that a certain number of blocks can be stored. It is recommended that each node in the overlay network has the same storage capacity; otherwise, there exists some resource wasted for the nodes with large capacity. According to this minimum storage capacity and speed of blockforming, a time interval can be set between two consecutive broadcasts. After the peer nodes receive the synchronization requests, they will connect to the cloud to synchronize the blocks.

C. Synchronization Process
After the cloud receives a synchronization request from the overlay node, it starts the synchronization process. This process synchronizes the blockchain and the transactions at the same time.
In the cloud connector, it has a field to specify the blockchain header, which is the most recently synchronized block in the cloud. In case that the cloud receives multiple synchronization requests, the cloud connector only needs to keep one copy of both the blockchain and its transactions. To resolve this issue, the basic idea is to let the cloud connector compare the blockchain header in the cloud with the current blockchain header from the overlay network. If both headers are the same, then the cloud is synchronized and denies this synchronization request; otherwise, the cloud will synchronize the blockchain and transactions from the overlay network. There exist several sophisticated works to solve file synchronization across multiple storages, such as MetaSync [37] and UniDrive [38].
Once the block synchronization process is finished, the cloud needs to send out the response message to notify the overlay network so that the overlay nodes know that the status of the current synchronization. The response message typically has two types: regular response message and exception response message. The exception response message is used to notify the overlay network that errors happened during the synchronization process. This might require the repeat of the synchronization process. While the regular response message from the cloud needs to include in the most recently updated block information, the overlay nodes will only keep the most recently updated block, and swipe out all other blocks. We assume the communication between the overlay network and the cloud are secure e.g., via secure communication channel or security platform. Then, the overlay nodes consider this feedback block as the first block in its partial chain, and continue a new round block forming process until the storage space is full. Due to the separation of the synchronization process and the consensus protocol in the overlay network, the overlay network does not stop the formation of the new blocks.

D. Exception Handler
To guarantee that the blockchain is chained together as it was, the cloud needs to regularly perform a verification process to check if the currently synchronized blockchain is consistent. This task is performed by the Storj cloud platform within the clouds. The exception handler is required to be performed before the cloud sends out the respond message (as in the synchronization process). If some errors (e.g., inconsistency among the clouds) happen during the synchronization process, the cloud will send out the exception response message, otherwise, it will send out the regular response message. Compared to the nodes in the overlay network, the cloud typically has sufficient computing resources. If an error is detected, the cloud will try other nodes to synchronize the blockchain and transactions. If the cloud detects the error (e.g., refusing to synchronization or synchronous wrong blockchain) twice from the same overlay node, this node will be marked as a potential malicious node, and the cloud will notify the node administrators to inspect the malicious behavior.

VII. CASE STUDY
This section provides an industrial case study to illustrate the efficiency of the proposed framework. We choose a medium-size industrial system, based on Emerson Wireless Industrial Automation Systems, to estimate the average data volume generated when

From
The address of local metering device, e.g., UUID of meters

To
The target gateway, either field gateway or edge gateway, that the metering measurement is sent to Type What type of measurement, e.g, warning Device info The information of metering device

One Time PK
The device's one-time public key used to encrypt the message from device to gateway so gateway can verify its integrity and confidentiality

TimeStamp
Unix timestamp when a device is measured its measurement (assuming all plants are) synchronous locally. Also, a timestamp is used to accept as valid if it is greater than the timestamp from the previous data block

TX ID
To identify the order of measurement from "from" to the same "to". Each measurement has a unique ID during its block epoch Data Measured value from physical devices Hash Type Indicate what digest algorithm used, e.g., SHA-256, SHA-512

TX Hash
The digest of the measured value

Sig Type
Indicate what signature algorithm used Signature The signature of the measurement implementing the proposed hierarchical storage architecture 5 . The adopted system performs a continuous condition monitoring on industrial Smart Metering scenarios [39], which consists of 50 WSANs (Wireless Sensor and Actuator Networks), each having 100 nodes. Each node is an industrial gateway, connected via SATA to a 2.5" drive bay for storage.
We first present the industrial data structure for this case study (including transactions and blocks) and then provide the quantitative analysis on of the storage volume.
A. Data Structure 1) Industrial Transactions: Transactions in cryptocurrencies (e.g., UTXOs in Bitcoin [40]) are quite different from industrial transactions, as they need to carry the industrial information on their own transactions. In the following description, we use a smart metering system as an example to outline the basic structure of an industrial transaction, which can be generalized into other industrial cases. Table I shows a conceptual structure of the transaction with description.
Here we specify some cryptography-related fields of Table I. One Time PK uses secp160r1 of Elliptic Curve Cryptography (ECC) (20 bytes); TX Hash is based on SHA-256 algorithm (32 bytes); Signature is based on Boneh-Lynn-Shacham (BLS) [41] signatures, which only require 33 bytes to achieve the same level security as 2048-bit RSA [42].
2) Industrial Block: A block in our industrial blockchain is called a "data block". A data block is directly related to the transactions, which come from physical resources and local networks. Each data block consists of two parts: a block header and a block body. The header contains metadata about its block. The body of the data block contains the transactions. These transactions are hashed only indirectly through the Merkle root. The description of each field of a data block is as shown in Table II. Notice that most cryptocurrencies, e.g., Bitcoin, only store the transactions' hashes and the Merkle

Block Hash
An identifier to identify a block, which is a cryptographic hash.

Version
The block version number, with which the system can upgrade the software and specify a new version.

Merkle Root of TXs
Merkle tree root, a data structure that summarizes the transactions in the block.

No. of TXs
Identify the number of transactions to be included in block body.

Signature
The signature of the block, which is signed by the creator of the block.

Timestamp
Show the time when a new block created.

Data Block Body
No.
Shows the order of transactions in one data block sequentially from 1 to N, where N is the total number of TXs in this block.

TX ID
Extracted from Transaction.

TX Data
Extracted from Transaction.

TX Hash
Extracted from Transaction. tree root into the blockchain, but industrial cases need the whole transaction to be stored in the data block for further analysis in condition monitoring.

B. Analysis
A typical transaction size for smart metering in continuous condition monitoring is in the range of 120 ∼ 180 bytes for quantitative analysis. For example, if 150 bytes is the average transaction size and the average device sampling period is 1 second, then the average data volume per second for a medium level industrial IoT platform is 50 W SAN s * 100 nodes * 1 sample/second * 150 bytes = 750, 000 bytes/second (750KB/second). Compared with the average data volume of 1.67 KB per second in the Bitcoin network, this storage requirement in the industrial case is pretty huge.
In our smart metering system, each consensus node (e.g., gateway) is equipped with one 128GB SATA Harddisk to store the blockchain. Considering the data volume generated and the size of the hard disk on each consensus node, the system updates the consensus node's data blocks to the cloud every 24 hours.  shows the block data storage requirement for one-week's evaluation in a medium-size industrial case on each consensus node. The existing approaches represent the generic solutions that store all the blockchain data on consensus nodes without resorting to storing the block data on external storage, such as cloud storage. As the figure shows, the blockchain storage requirement for existing approaches is huge. For a week period, the block data generated can be more than 500GB. Without effective backup storage, the old data will be overwritten by the newly generated blockchain, and one 128G disk is only large enough to store one day's data. Our approach utilizes the hierarchical blockchain storage to maintain the most recent blocks in consensus nodes, and the majority of the blockchain is synchronized into the cloud. We use the 200Mbps data link to synchronize the data from consensus nodes to the cloud. In this case study, it takes about 1 hour to upload one-day's blockchain to the cloud. As the synchronization processes and block forming processes in the overlay network happen simultaneously, the system does not need to stop. The subfigure in Fig. 4 shows the data volume change during the synchronization processes. We observed that the data volume cannot go down to zero during the synchronization processes, since the new blocks are still forming on the overlay network to link the blocks to the blockchain. Fig. 5 shows the overall percentage of the blockchain stored on consensus nodes as the time increasing over 30 days. From this figure, we can observe that the percentage of blockchain data stored on the consensus nodes is continually decreasing as time increases. Although the data volume of the whole blockchain continues growing, the blocks stored on the consensus nodes cannot be larger than a threshold because of the storage limitation of the consensus nodes. For instance, this threshold is 100GB in our case. When the blockchain data volume reaches this threshold, it triggers the synchronization processes to synchronize the recent blocks to the cloud.

VIII. RELATED WORK
The blockchain technology was first introduced along with the Bitcoin by Satoshi Nakamoto [40]. A tremendous amount of efforts from both academia and industry have contributed to the research of blockchain. When applying blockchain into IoT, it is still subject to several challenges, such as storage issues. This section provides the literature reviews on the blockchain storage.
Some researches focus on increasing the usability by reducing the storage requirements on the client side. In Bitcoin [40], Nakamoto proposes to use simplified payment verification (SPV) without running a full network node, and a user only needs to keep a copy of the block headers of the longest PoW chain. However, it does not mention how to reduce blockchain storage on the full network node, and its verification is more vulnerable if the network is overpowered by an attacker. Xu et.al. [1] propose a blockchain-based storage system, Sapphire, for data analytics applications in the IoT. They present an OSD-based smart contract (OSC) as a transaction protocol, in which object storage devices employ embedded processors in the devices to process apart from storing data.
Lunardi et.al. [43] propose a distributed access control on IoT ledger-based architecture. Due to limited storage on the gateway, the authors propose to parameterize and define the amount of information to be stored in the local IoT ledger, which only stores the new information in the block ledger. However, the authors did not mention the solution to store old information to the external storage, and the way to achieve that. Sharma et.al. [44] propose a blockchain-based distributed architecture with Software-Defined Networking (SDN) enabled controller fog nodes at the edge of the network. By leveraging a distributed fog node architecture that uses SDN and blockchain, the proposed model tries to bring computing resource to the edge of the IoT network. This structure reduces the access latency to large amounts of data in a secure manner, however, it does not deal with the blockchain storage issues.
Wilkinson et.al [45] propose a P2P cloud storage network, Storj, allowing users to transfer and share data without reliance on a thirdparty data provider. The storage network periodically cryptographically checks the integrity and availability of the file. In Storj, it uses MetaDisk [46], a blockchain for decentralization metadata storage, to keep the consistency among the clouds. Similar to Storj, Sia [47] also is a platform for decentralized storage, which enables the formation of storage contracts between peers. In Sia, it requires the storage providers to prove, at regular intervals, that they are still storing their client's data. In our proposed scheme, we use Storj to manage the cloud storage to maintain the consistency of blockchain among clouds.
Although a large amount of work has been contributed to integrating the blockchain technology to IoT systems and applications, to the best of our knowledge, none of them has dealt with the storage issue which is purely based on the blockchain structure. Our work is the first attempt to mitigate this issue on the chain level.

IX. CONCLUSION AND FUTURE WORK
Blockchain technology and the application of the technologies in IoT systems have gained a great deal of attentions from both academia and industry. However, it is a challenging problem to store and manage blockchain in IoT networks, due to the massive data generated from IoT applications and the limited resources in the IoT infrastructures. This paper proposed a hierarchical storage structure to store the majority of the blockchain in clouds, and maintain the most recently generated blocks in a blockchain overlay network. We further present a blockchain-based IoT architecture to maintain both blocks and transactions generated by the IoT networks. Two software interfaces, a blockchain connector and a cloud connector, are defined to construct the blocks and synchronize them to the clouds. As a future work, we plan to work on the implementation of the proposed blockchain-based IoT architecture in more real IoT applications and thoroughly evaluate its other performances, such as latency and throughput.