Introduction

IT-based platforms have proven their significance in facilitating data-sharing and interoperability among organizations [1]. A few of their benefits perceived by business entities are improving their planning process, enhancing their capability to fulfill large work orders, and stimulating the creation of new business models [2,3]. Despite these gains, establishing a data-sharing ecosystem has challenges, e.g., conflicting data formats and standards between companies' software systems and the lack of technical enforcement in disclosing sensitive data [4,5].

Proceedings of the Workshop of I-ESA'22, March 23-24, 2022, Valencia, Spain EMAIL: d.r.firdausy@utwente.nl (D.R. Firdausy); p.dealencarsilva@utwente.nl (P. de Alencar Silva); m.j.vansinderen@utwente.nl (M. van Sinderen); m.e.iacob@utwente.nl (M.E. Iacob) ORCID: 0000-0001-9743-9754 (D.R. Firdausy); 0000-0001-6827-1024 (P. de Alencar Silva); 0000-0001-7118-1353 (M. van Sinderen); 0000-0002-4004-0117 (M.E. Iacob) Subsequently, these hurdles in carrying out data exchange led to the advancement of the International Data Spaces (IDS). This initiative is a decentralized and usage policy-enforced datasharing ecosystem that puts forward trust, security, interoperability, and data sovereignty in mind [6,7]. IDS grants the participants access to join and share data in the ecosystem through the IDS Connectors. These software components will be critical to enabling secure data exchange between a data provider and data consumer by enforcing usage policies for the data consumer to use, process, and proliferate the shared data [8]. As a gateway between a company's enterprise systems and their partners', the IDS Connectors may soon be offered and supplied by software and service providers in numerous configurations to satisfy diverse sets of participants' needs and capabilities. As a result, the information to request these IDS Connectors will be increased in a scattered manner throughout the Web, hampering the potential participants' ability to discover them and ultimately limiting their adoption of the IDS vision. To cope with this issue, we propose the idea of an IDS Connector Storea repository of metadata describing the functionality and contextual information about data connectors.

In the meantime, Semantic Web technology has gained more prominence in information sharing. It has been implemented in an increasing variety of contexts in recent years to enhance the discoverability and accessibility of resources on the Web [9]. One of the building blocks that constitute the Semantic Web is Ontology, which is a formal and explicit specification of a concept used to add a layer of metadata to the described resources to define their meaning [10]. This procedure makes the Web more accessible and understandable for more refined search results by software agents in providing information to human agents. Even though considerable research has adopted the Semantic Web approach, the ones that attempt to cope with the widespread proliferation of the IDS Connectors are still minimal. Therefore, we propose the application of Ontology and Semantic Web technology to the development of the IDS Connector Store to facilitate the discoverability and selection process of the IDS Connectors.

The organization of the rest of this paper follows. Section 2 will address the question that probes the methodological steps required to develop the ontology for the IDS Connectors. Then, Section 3 elaborates on producing the ontology requirements specification document, highlighting the competency questions related to discovering and selecting the IDS Connectors. Finally, in Section 4 and Section 5, we will present the first conceptual draft of the mentioned ontology described in OntoUML and pose a discussion among the conceptual modeling community to specify the ontology further in Web Ontology Language (OWL).

Research methods

The first prominent step in developing an ontology-based software application is the formulation of the ontology requirements specification document (ORSD). In this research, we adopt the scenariobased NeON Methodology, emphasizing the reuse of existing ontological and non-ontological resources in developing the ontology [11]. In addition to the requirements specification activity guidelines, this methodology also provides a template to formulate the ORSD as a filling card that describes the purpose, scope, implementation language, intended end-user, intended uses, requirements, and pre-glossary terms of the ontology under design [12]. The process followed to produce the ORSD based on this methodology will be discussed in more detail in the next section.

This paper aims to produce a preliminary ontology for the IDS Connectors to facilitate their discoverability and selection for the IDS participants. To maintain interoperability with the domain reference ontology, NeON suggests a quick search of knowledge resources for possible reuse during the development. For this purpose, the IDSA has published the IDS Information Model that describes the fundamental concepts of the IDS, covering entities from the participants to the infrastructure components [13]. This IDS Information Model grounds the ontology proposed in this work. The resulting conceptual model is depicted in OntoUML [14]. This model serves as the basis for further implementation into OWL to describe the IDS Connectors and distinguish them with subjectpredicate-object triples according to the Resource Description Framework (RDF) format [15]. Through this semantic annotation, several sentences can be formed to explain the IDS Connectors. For instance, company A maintains an IDS Connector X, IDS Connector Y is offered in a flat-rate pricing model, or IDS Connector Y complies with GS1 standards [16,17]. As a result, software agents will be able to discover the IDS Connectors that are appropriate to their data exchange demands.

IDS connector ontology requirement specification

The requirements specification identifies the ontology's purpose, scope, and implementation language. As presented in Table 1, three main end-users that will take advantage of the knowledge given by the IDS Connector ontology are listed. The business representatives are the first target users due to their interest in spotting potential business opportunities in the current business landscape. For the potential IDS participants, the presence of their partners and the prospect of securing a strategic partnership with other existing participants signal the value accessible to them by participating in the data space. Such a scenario might influence their willingness to consolidate into the IDS ecosystem.

Conversely, the interests of the existing participants can take many forms. One example is to find other prospective partners to engage in strategic information exchange to leverage their value chain performance. The IT representatives will need to further translate these business strategies to the IT implementation strategies by investigating the suitable IDS Connector matching their needs and capabilities. Such a demand leads to concerns about which IDS Connectors fit their business domain or industrial standards adopted for data exchange. In response, software and service providers will be interested in making their IDS Connectors discoverable by external software applications.

Table 1 IDS Connector Ontology Requirement Specification Document Purpose

To serve the IDS Connector Store as a knowledge base in describing the IDS Connector to guide existing and potential participants of the IDS ecosystem to the relevant IDS Connector.

Scope

The ontology focuses on describing and discovering the IDS Connectors according to contextual information (e.g., the business domain, pricing model, and enforced data access policy) with the granularity represented by the competency questions.

Implementation Language

The ontology is represented in OntoUML, with further translation into OWL. -Java, Spring Boot, JavaScript, NodeJS, VueJS, Python, etc. -On-Premise, Cloud: SaaS, etc.

Intended End-Users

The functional and non-functional requirements specification then follows the Ontology Engineering activity. The ontology development work on the IDS itself was initiated by the IDSA by publishing the IDS Information Model. This work grounded the development of this IDS Connector ontology, putting it as a prominent non-functional requirement. On top of this, several functional requirements in the form of competency questions lead to the semantic-enabled discovery and selection process of the IDS Connectors. These questions are grouped by considering the immediate interests of the relevant end-users. Frequent terms are extracted from the competency questions, leading to the enumeration of objects for answering the end user's query. We instantiate the entities listed in Table 1 above by referring to the literature [5,18], industrial standards [16,17,19], IDSA documentation and publications [8,13,20], and the publication of the Smart Connected Supplier Network (SCSN), one of the IDS forerunners in the Dutch manufacturing supply chain [21,22].

Preliminary IDS connector ontology conceptual model

Using the IDS Reference Architecture Model (RAM) and the IDS Information Model (IM) as a starting point, we have identified several concepts relevant to answering the CQs above, namely the Participant and the Connector concepts [8,13]. As shown in Figure 1, we identify the former concept as the IDS Actor and extend it further into two specializations. The Core IDS Actors refers to the participants who either own and provide or request and use data. Meanwhile, the IDS Supporting Actors are associated with parties that ensure the continuation of the data-sharing ecosystem. The Software and Service Provider carries this duty by providing essential components to participate in the data space. Meanwhile, the Broker Service Provider supports the core actors with the function to look up for the other actors and the Connector used by the different actors through the functionality offered by the IDS Connector Store. In addition, the Supporting IDS Actor also covers other roles, such as the Clearing House and Identity Provider. However, as the IDS RAM describes, these roles can be assumed by the same organization that takes the part of the Broker Service Provider [8].

The IDSA expresses the Connectors from several different perspectives. On the one hand, the IDS IM describes the concept of a Connector to be the generalization of the Base Connector, Trusted Connector, App Store, and Participant Information Service [13]. Here, we distinguish these Connectors into the Core Connector and Supporting Connector, each used by the corresponding type of role. The IDS RAM justifies this distinction by describing that the functions falling into the supporting category, i.e., the App Store Provider, Broker Service Provider, and Identity Provider, rely on the Connector technology to carry out their functions [8]. On the other hand, the IDS RAM also characterizes the Connector from its Deployment Context, Security Profile, Catalog, and Host. The Deployment Context is designated as the Connector's deployment environment, i.e., on-premises or cloud-based. Security Profile explicates the Connector's capability to enact a secure data exchange and processing environment. Host signals the communication protocol that the Connector supports to expose resources, i.e. HTTPS URLs, MQTT topics, etc. Whereas, the Catalog facilitates the participant discovery in the ecosystem based on the digital resources that the Connector provides or consumes.

We extend the Connector concept with additional properties to facilitate its discovery and selection. The Business Domain describes the context where the Connector is developed to be specialized. Standards refer to the criteria to which the connector complies. The Pricing Model implies how the end-users are expected to pay for the Connector's usage and acquisition. The Application Framework informs which technology stacks are used to develop and support the Connector's runtime. Finally, the Data Usage Agreement is understood as the contract composed of the Data Usage Policy Pattern and agreed by the interacting Core IDS Actor to govern the data usage. As of now, five types of data usage patterns are supported by the Connector, and more designs may be added in the future.

Conclusion

This paper introduced a preliminary ontology conceptual model to describe IDS Connectors that will serve as a façade of a Connector Store. Since this ontology is still under development, we plan to refine it further to accommodate more relevant competency questions to facilitate the discovery of IDS Connectors and IDS actors. The next step is to translate this model into OWL representation for semi-automated machine reasoning. Then, we populate the resulting representation with instances of IDS Connectors and IDS Actors and load it into a triple store such as TriplyDB to make it publicly available [23]. Then, we plan to evaluate the published ontology by translating the competency questions into SPARQL queries to verify the ontology's correctness, consistency, and completeness. Hence, we plan to validate the utility of the ontology by assessing the relevance of the posed competency questions with expert opinion and the end-users identified in Table 1, besides verifying if the answers returned from the SPARQL correspond to end-users expectations. Lastly, the completed and published ontology will be operationalized into a proof-of-concept implementation of the IDS Connector Store by connecting the triple store with a user-interfacing application to support the discovery and selection of IDS Connectors in an IDS-compliant data-sharing ecosystem.