Trusted Data Access Control Based on Logistics Business Collaboration Semantics

Abstract

In the context of the digital evolution of the logistics industry, the interconnection of logistics information systems and associated data have become an obstacle of business collaboration among various stakeholders. A critical challenge in this domain is ensuring controllable access to logistics business data, given the industry’s current state characterized by independence, autonomy, disconnection, and heterogeneity, alongside the non-negotiable requirement for data privacy. We propose a novel model of trusted data access control based on of logistics business collaboration semantics. This approach incorporates semantic inference technologies into attribute-based access control mechanisms, thereby enabling the streamlined formulation of access control policies and facilitating unified authorization and control. Moreover, the method addresses the issue of access control policy management and maintenance at the semantic level. The proposed solution can pave the way for enhanced business collaboration between business entities, and further enable the building of a data exchange service platform within the logistics industry.

1. Introduction

The sharing and exchange of data within the logistics sector are pivotal for the advanced development of logistics informatization [1,2]. As logistics companies digitize, they often establish their own logistics information systems, connecting to various databases. However, these systems are heterogeneous and decentralized, which leads to generating “information islands” due to the stringent data privacy requirements of different stakeholders. Given the critical role of logistics data as both a fundamental resource and a significant factor in productivity, facilitating data circulation is a crucial yet challenging task, exacerbated by the growing concerns over data security, particularly in terms of access.

Access control emerges as a crucial technology for enabling data circulation while safeguarding data security. It aims to regulate the access activities of data consumers, serving as an essential online data management technique. Traditional access control models are designed to resolve the authorization problem of data access, prevent unauthorized access, and ensure data are accessed in a secure and controllable environment. In an open and distributed environment, the attribute-based access control (ABAC) mechanism has become prevalent, being recognized for its flexibility and applicability [3]. Yuan proposed an ABAC method to achieve access control over web services by a flexible access control mechanism [4]. But it does not meet the requirement of ensuring the trusted identity of access subjects in data exchange. Guerrero proposed another ABAC framework to protect patients’ personal privacy by defining access policies with user attributes [5]. This framework ensures that only the authorized users can access sensitive data, but overlooks the the importance of semantic support. Fortunately, some efforts have noticed that the potential enhancements semantic support maybe can offer to access control precision in a novel manner. Pan proposed the concept of semantic authorization, allowing semantically equivalent roles to access semantically equivalent objects [6]. The framework proposed in Masoumzadeh [7] further expands the work of Shen [8] by providing a more detailed semantic model and complex authorization mechanisms such as delegation authorization. Carmnati proposed a semantic web-based framework for implementing access control in social networks [9]. This work addresses the issue of access control in social networks, ensuring that only authorized users can access specific social network resources. It solves some limitations of fixed role permissions in traditional access control models. By introducing semantic relations and reasoning mechanisms, the framework can more accurately match users’ access needs, and support more fine-grained permission management, so that users can better control their personal information and share resources. In the realm of trusted data access control, several scholars have explored pertinent research avenues. Bouazzouni [10] proposed an architecture for constructing a secure access control system founded on the trusted execution environment (TEE) and identity-based encryption (IBE) mechanism. This framework integrates role-based access control mechanisms and trust management concepts within cloud computing environments. Additionally, Ma [11] conducted in-depth research on the topic of trusted data sharing, focusing on blockchain-based flexible access control methods. Nevertheless, these methods may meet many problems in logistics industry. Many factors have to be considered such as trust and permission management among multiple supply chain participants. Two challenges are listed as follows:

• How to achieve unified authorization and access control among decentralized and heterogeneous information systems;
• How to ensure the trusted identification of the subjects in the data-accessing process.

Aiming to solve the above issues, we propose a unified authorization and access control model. At first, an ontology-based approach is utilized to deduce semantic information from logistics collaborations and abstract relevant attributes for access control. Then, blockchain and encryption technologies are employed to ensure the credibility of access subjects and data confidentiality. Thus, data security is guaranteed in the necessary data exchange for logistics business collaboration.

In order to better understand this article, we have defined and described some of the terms and concepts used in this article, as shown in

Table 1. Partial definitions and terminology.

Definition	Meaning
Logistics business collaboration semantics	Emphasis is placed on defining and standardizing the meaning of information exchange in supply chain cooperation to ensure data consistency and accuracy
Trusted data access control	Implement data access control under a blockchain based trusted mechanism
Collaborative logistics business	A business model of cooperation between logistics service stakeholders
Ontop	Virtual Knowledge Graph Tool

.

The paper is structured as follows: Section 2 reviews related work. Section 3 describes collaborative logistics business processes. In Section 4, we proposed the construction of an access control model based on logistics business collaboration semantics, detailing the construction of the ontology model, the logistics business collaboration ontology, semantic access policy sets, and the optimization of access control rules through inference engines. Section 5 introduces a semantic-based trusted data access control architecture and trusted data access control process, enhances the traditional virtual knowledge graph tool, and discusses the framework’s implementation in logistics. Finally, Section 6 shows a use case to evaluate the effectiveness and practicability of the proposed model.

2. Related Works

In this section, we will delve into the field of access control and related work on ontology-based data access. With the rapid development of information technology, data security and access management have become crucial issues. As a key mechanism for ensuring data security, access control research and practice continue to deepen. Meanwhile, ontology, as an effective way to describe and represent knowledge, has also shown great potential in the field of data access.

2.1. Access Control

Access control serves as a fundamental mechanism for ensuring secure interoperability among information systems. It consists of three elements: the subject, object, and access control strategy. Of these, the access control strategy stands as the key component of access control technology. The landscape of access control mechanisms has been significantly enriched by various models, including role-based access control (RBAC) [12], attribute-based access control (ABAC) [13], scenario-based access control [14], relationship based access control [15], and so forth. Among these, the attribute-based access control (ABAC) model stands out for its flexibility and comprehensive approach to resource access control, determined by user attributes such as identity, location, time, and role. ABAC represents a functional evolution of the role-based access control (RBAC) model by integrating attributes as a mediator between resources and users [16]. This model capitalizes on the diverse attributes of both resources and users, alongside the access environment, to cater to a wide range of access requirements through a nuanced interpretation of attribute types and meanings.

The integration of semantic techniques into ABAC began with Damiani’s work in 2004, extending the XACML policy language [17]. They extended the XACML context to include metadata associated with topics and objects. They modified the attribute value element (in the XA-CML policy language) using RDF assertions as the value of the attribute. In 2006, Priebe extended the XACML framework by adding inference engines and ontology management points to XACML, and provided corresponding prototypes [18]. In 2008, Muppavarapu and Chung combined semantic technology with the XACML standard to improve interoperability in data grids [19]. They adopted the same mechanism as Priebe’s approach to handle access requests, using an OWL ontology and SWRL [20] rules to extend the attribute list provided by users in access requests. In 2010, Shen extended the XACML architecture by adding an ontology management system [21]. He used the XACML policy language and XACML combination algorithm to standardize access control policies and resolve policy conflicts, respectively, and changed the policy language to SWRL to enhance the expressive power of policy specifications. Unlike Priebe’s approach, Shen’s approach can make access decisions faster.

Meanwhile, researchers have also noticed the relationship in specific scenarios: in particular, enriching role-based access control, the research on semantic web technology based on Sun, who proposed an SBAC model to understand the semantic relationships among entities within access control domains, including users, data/resources, and actions. Ghazal proposed an access control model and framework based on semantic business roles [22]. This model models business roles using semantic technology and combines intelligent algorithms to achieve dynamic management of permissions and intelligent allocation of roles. Abdulkadhim proposed a method of using semantic information to access authorization for multidomain data [23]. By establishing semantic relationships between data, access authorization for cross-domain data is achieved, improving the accuracy and efficiency of data access. Chondrogiannis proposed using blockchain and semantic web technology to implement smart contracts between individuals and health insurance organizations, using blockchain technology to execute and record transactions, and using semantic web technology to define the terms and conditions of smart contracts [24]. These models aim to support the definition of fine-grained access control policies, especially in sectors like healthcare, where the precision of access rights is critical.

2.2. Ontology-Based Data Access

Ontology-based data access (OBDA) is proposed by Calvanese to address the heterogeneity of data, facilitating a structured and semantically rich data access framework [25]. The concept of ontology, first introduced into the field of computer science by Neches [26], then refined by Gruber [27] and Studers [28] in turn, provides a clear formal specifications for shared conceptual models of ontologies. OBDA can leverage these ontologies to enable a more nuanced and context-aware access control mechanism. Various OBDA systems, both open-source like Ontop [29] and Morph [30] and commercially licensed like Stardog and Mastro, exemplify the practical application of these concepts, underlining the evolving landscape of access control strategies enriched by semantic technologies and ontology frameworks.

We use Ontop as the basic model. Ontop is an open-source virtual knowledge graph tool that maps data from relational databases to RDF graphs and provides a SPARQL [31] query interface, allowing users to query data from relational databases using the SPARQL query language. Its flexibility, high performance, and ease of use make it an ideal tool for integrating relational databases with ontology models. Ontop supports multiple databases, such as Oracle, PostgreSQL, MySQL, etc. In addition, it also provides an editing plugin for the Protégé ontology software, enabling efficient integration of the pattern layer and data layer of the knowledge graph. The system structure of Ontop is shown in Figure 1, which is divided into four levels: an input layer, core layer, API layer, and application layer.

3. Collaborative Logistics Business Processes

In 1965, Higor Ansoff, an American scholar in strategic management, proposed the synergy concept in his “Corporate Strategy” book. By the 1990s, this concept was applied in logistics, leading to what is now known as collaborative logistics. This approach encompasses various logistics entities working together to share information and resources, thereby collectively completing logistics activities. This collaboration covers multiple operations such as order processing, inventory management, transportation, and warehousing, aiming to improve the logistics system’s overall efficiency and effectiveness. Achieving collaborative logistics typically involves utilizing information technology and logistics management systems to facilitate real-time information flow and data accuracy, thereby ensuring coordination and optimization across the board.

The activity flow of collaborative logistics business process is illustrated in Figure 2. The figure highlights nine key points of data exchange between logistics business partners, described as follows:

①: The supplier provides the carrier a goods list along with the actual goods detailing items such as goods names, individual item details (name, specifications, model, unit, quantity), SKU details (specifications, quantity, unit), consignor and consignee information, addresses, the freight charges and payment terms.

②: Upon receiving the supplier’s shipment, the carrier informs the urban distribution entity about the goods’ details, including name, pick-up and delivery address, contact information (confidential business data, abstracted from the contact), weight, volume, and the short-haul freight amount to the urban distribution entity. The urban distribution entity will then pick up the goods and deliver them to the designated location.

③: Similar to ②, upon the notification from supplier, the carrier passes the relevant goods information to dispatch center, who then arrange to pick up the goods.

④: At the distribution center (or third-party logistics), personnel verify and inspect the goods based on the provided goods list, sorting them according to the consignor’s SKU, and notify the cooperating logistics company for further transportation.

⑤: The distribution center forwards the consignment information to the dedicated logistics partner, including goods names, SKU details (specifications, models, units, quantities), dedicated logistics freight amount (generally including last-mile delivery fees), payment items, delivery address, and consignee contact details (typically providing the contact person and contact information of the carrier who signed the contract with the supplier).

⑥: Logistics companies engage with transport providers to perform goods movement followed the responding agreements. The logistics company at point A find transport companies and sign a transport agreement, outlining acceptance procedures and payment agreements based on the delivery to the logistics company B.

⑦: Upon delivery to the logistics company at the destination, personnel at B verify the incoming goods against the system information, to ensure the completeness and compliance with requirements.

⑧: Depending on the arrangement or consignee’s selection, other a local urban distribution company is responsible for final delivery, or the consignee picks up the goods directly.

⑨: The consignee verifies the received goods against supplier-provided shipment information and confirms receipt, often facilitated by ERP, OMS, or other systems for real-time status updates.

In the backdrop of the logistics business processes, most logistics companies have established their own logistics information systems, and the associated databases are geographically decentralized and heterogeneity. Industry-specific demands for localized data and privacy concerns often lead to the disconnected systems, forming "information islands" and hampering effective information sharing and resource integration. Such traditional situations prevail due to mutual distrust among logistics entities, resulting in low efficiency and unclear responsibilities. In addition, differences in views among different logistics business entities regarding the purpose, scope, and authority of data usage, further complicate data sharing.

Therefore, we propose a unified access control and authorization model, grounded in the collaborative semantics of logistics business processes, aims to overcome the challenges posed by semantic heterogeneity in information sources by aligning logistics business requirements with data characteristics.

4. Construction of Access Control Model

In this section, we propose the construction of an access control model based on logistics business collaboration semantics. Firstly, ontology construction process was described, followed by logistics business collaboration ontology and semantic access policy set. Finally, the use of inference machines to optimize access control rules was discussed.

4.1. Ontology Construction Process

Ontology is a formalized specification of a shared conceptual model that acts as a method for knowledge modeling. With the continuous deepening of ontology technology research, many mature ontology construction methods have emerged, including IDEF5, proposed in the 1970s; enterprise ontology [32], applied to enterprise ontology development; a more general method that combines the skeleton method and GOMEZ-PEREZ; methodology; and currently the most commonly used Stanford University seven-step method. Through learning and researching the methods of ontology construction, we have divided the construction of access control ontology into four main stages.

(1)

Planning Stage

The initial stage involves clearly defining the ontology’s purpose and scope, focusing on capturing the essential knowledge of logistics business. On one hand, the necessary logistics business knowledge can be obtained through analysis and research on the logistics public information platform. On the other hand, the terminology and standardize concepts in logistics field is abstracted in logistics books and national logistics standards. Based on the concepts and terms specified in standards such as GB/T 18354-2001 National Standard of the National Standards of the People’s Republic of China Logistics Terminology and GB/T Guidelines for the Application and Development of Logistics Public Information Platforms, this paper analyzes the concepts and attributes in logistics business, clarifies the knowledge structure and workflow in the logistics field, and then formulates the object, subject and environmental attributes for attribute-based access control within the logistics domain.

(2)

Design and Implementation Phase

Following the planning stage, this stage is to classify knowledge and design access control ontology. This involves selecting an appropriate ontology description language and ontology modeling tool among 50 available tools such as JOE, KADS22, OILep, OntoEdit [33], Protégé [34], Ontolingua [35], and WebOnto [36]. We here choose Protégé due to its wide applicability, customizability, robust support community, and particularly because of its open-source nature and extensive documentation resources. With the optimal choice, we efficiently design and model the ontology, facilitating the definition of classes, relationships, attributes, and instances in a user-friendly environment.

(3)

Evaluation Stage

This stage involves assessing the constructed ontology against established ontology construction principles to ensure its validity and applicability. At first, the constructed ontology is evaluated in accordance with the principles of ontology construction. Then, the OWL inference engine checks and evaluates the consistency of the constructed ontology. Finally, we optimize and improve the ontology according to the feedback results, ensuring it accurately represents the logistics business collaboration semantics.

(4)

Maintenance Phase

Ontology construction is not a one-time effort but requires ongoing maintenance to adapt to the evolving landscape of logistics knowledge. As the industry develops and new insights emerge, the ontology must be dynamically optimized and updated. This iterative process ensures that the ontology remains relevant and effective in modeling the knowledge base for the access control model.

The construction and refinement of this ontology lay the groundwork for a semantic-based access control model tailored to the logistics industry’s needs. By capturing the intricate relationships and attributes within logistics business collaborations, the model aims to facilitate nuanced and effective access control strategies, enhancing data security and collaboration efficiency within the industry.

4.2. Logistics Business Collaboration Ontology

The ontology based on logistics business collaboration is constructed with organically combining the logistics domain ontology and the access control ontology. This ontology serves multiple purposes: firstly, the logistics domain ontology is designed to support data access and querying by providing a semantic model for OBDA, which is helpful to solve semantic problems in data access, integration, and querying; secondly, the access control ontology strengthens the data access control policies to ensure that only authorized users can access specific information. This combination enables controllable fine-grained data access in logistics business collaboration, while solving the semantic interoperability problem between heterogeneous subjects. In our model, the individual classes and hierarchical structure in the constructed ontology are shown in Figure 3. In addition, we use object attributes in OWL to map relationships between entities, some of which are shown in

Table 2. Object properties.

Property	Domain	Range	SubClass
hasLocation	Subject	Location	EnvironmentalAttributes
hasRole	Subject	Role	SubjectAttributes
hasTime	Subject	Time	EnvironmentalAttributes
hasType	Object	ObjectAttributes
permit	Subject	Object
deny	Subject	Object

. The details of the ontology are shown below:

The property of the access subject is defined as the subject attribute class, which is used to describe the characteristics of the access subject. The role classes are designed under the access subject attributes to represent the access subject roles. According to the functional architecture of the general logistics process, the role class is divided into supplier, forwarder, third-party logistics, carrier, warehouseman, quality inspector, logistics courier, and consignee, which are corresponding to the supplier role class, forwarder role class, third party logistics role class, carrier role class, warehouseman role class, quality inspector role class, logistics courier role class, and consignee role class, respectively.

The property of the accessing object is defined as the object attribute class, which is used to describe the characteristics of accessing object. The collection of attributes of accessing objects are mainly gathering from the types of resources within general logistics enterprises. During the modeling process, the attributes of the accessing object are divided into seven subcategories, namely personnel, settlement method, goods, expenses, transportation, address, and waybill, which are corresponding to the classes of personnel, settlement method, goods, expenses, transportation, address, and waybill, respectively.

Furtherly, the personnel category includes four subcategories, namely carrier information, consignee personal information, cargo owner personal information, and driver information. The settlement method class is further divided into subcategories of the transit fee settlement method class, commission settlement method class, advance payment fee settlement method class, receiving fee settlement method class, freight settlement method class, and delivery fee settlement method class. The cost category is divided into 25 subcategories, namely the transit fee category, agency fee category, receipt fee category, deduction fee category, receiving fee category, pick-up fee category, cash fee category, delivery fee category, total freight fee category, standard freight fee category, front freight fee category, rear freight fee category, insurance fee category, agency fee category, premium fee category output value expenses, prepaid expenses, total withdrawal expenses, total cash expenses, total monthly settlement expenses, total receipt expenses, total deduction expenses, total expenses, commission expenses, and price difference expenses. The transportation category also consists of vehicle information subcategory, transportation mode subcategory, and transportation route subcategory. The address class is divided into the receiving address class, shipping address class, and transit location class.

The class of environment attribute ontology represents the physical environment where the subject operates, describing the environmental characteristics that the subject needs to comply with when accessing the target object. The environmental attributes are divided into two categories, the location and time when the access subject initiates the access, corresponding to the location class and time class, respectively. Specifically, the access location is labeled with the status of whether it is in the work network.

4.3. Semantic Access Policy Set

The semantic access policy set is a cornerstone of the proposed access control model, leveraging the expressiveness of semantic web rule language (SWRL) to define custom access control rules. Following the access policy, the access permission can be decided by the user’s attributes. The value of “allow” access permission is returned if the access conditions are satisfied; otherwise, the value is “deny”. According to the semantics in functional architecture (

Table 3. Functional architecture in collaborative logistics Processes.

Role	Function
Supplier	Raw material suppliers or original manufacturers of products represented by enterprises
Forwarder	Organize the entire process, such as developing transportation plans, contacting carriers, tracking goods, etc.
Third-party logistics	Third-party logistics is responsible for managing and executing logistics activities related to goods transportation, warehousing management, supply chain management, etc.
Carrier	The company or individual responsible for transporting goods can be a logistics company, transportation company, or individual operator, etc.
Warehouseman	Responsible for managing all inventory in the warehouse, including receiving, storing, picking, packaging, and shipping
QualityInspector	Responsible for checking the quality and quantity of goods to ensure that they meet the requirements of the shipper and consignee
LogisticsCourier	Responsible for logistics distribution/reception work for the first and last mile
Consignee	The person or company who received the goods

) of the collaborative logistics business process, the custom access control rules can be formalized with SWRL, which offers a powerful syntax with a combination of OWL (Web Ontology Language) and RuleML (Rule Markup Language).

4.3.1. SWRL Rule Structure

Access control rules are formally specified by SWRL. The general structure of an SWRL rule is defined as follows:

$Rule=B1\Lambda B2\Lambda B3\Lambda B4\Lambda ......Bi.......\Lambda Bn\to A,1\le i\le n$.

This structure supports the formulation of rules where a series of conditions (B1, B2, …, Bn) lead to an assertion (A). In the context of access control, these rules can specify that if certain conditions regarding the subject’s attributes are met, access to a specific object is either permitted or denied.

In particular, to grant exceptional permission to the data requester in special scenarios, a “privilege” attribute is automatically added after each policy result of "deny" when the data owner formulates access policies. This attribute acts akin to a "master key", allowing data access under special conditions. Benefiting from this attribute, data requesters can be granted temporary and conditional access for the data if they deduce that they are in a special situation, even if their attribute set does not meet the access requirements. To validate the need for such privileged access, requesters are required to upload appropriate documentations demonstrating the urgency of their situation, and the data owner must review and approve them. In normal situations, system users have to follow the established general access control rules.

4.3.2. Example Rules and Their Functions

(1)

Granting Access Based on Role and Conditions

Rule1 = Subject(?x) Object(?y) Supplier(?a) hasRole(?x, ?a) Receive_address(?y) Worksite(?b) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) -> permit(?x, ?y)

Following Rule1, if the role of entity x is the supplier and the access request to the shipping address y is begun through the intranet during working hours, it is judged that entity x is permitted to access the shipping address y.

(2)

Denying Access Based on Role and Object

Rule2 = Subject(?x) Object(?y) Warehouseman(?a) hasRole(?x, ?a) Worksite(?b) Shipper_Information(?y) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) -> deny(?x, ?y)

If the role of entity x is the warehouseman, and an access request to the shipper information y is begun through the intranet during working hours, x is refuses to access the shipper information.

(3)

Emergency Access with Privilege Attribute

Due to the system automatically adding a ’privilege’ attribute after each policy result of ’deny’, the added rules are as follows:

Rule3 = Subject(?x) Object(?y) Warehouseman (?a) hasRole(?x, ?a) Worksite(?b) Shipper_information (?y) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) emergent(?x, true) -> permit (?x, ?y)

If the role of entity x is a warehouseman and whose access request is for the shipper information y, and x in particular is really in an emergency situation, it is determined that entity x allows access to shipper information y.

The above strategy for formulating SWRL grammar rules represents just a part of the application example. To more effectively cater to logistics scenarios, it necessitates further refinement, additions, and modifications to these rules.

4.3.3. Adaptive Rule Formulation for Logistics Scenarios

These SWRL rules represent a framework for defining access permissions that can be tailored to the specific needs of logistics operations. The inclusion of a “privilege” attribute after a deny decision introduces a nuanced approach to access control, acknowledging the potential need for flexibility in urgent situations. To effectively implement this model, logistics organizations must consider their unique requirements and contexts, adjusting and expanding upon these foundational rules to suit their operational needs.

In essence, the Semantic Access Policy Set, through the use of SWRL, offers a sophisticated means to encode access control policies that are dynamic, context-aware, and capable of handling the complexities of logistics business collaboration. This approach not only enhances the security and efficiency of data access within logistics but also ensures that access control policies are adaptable to the evolving needs and scenarios within the industry.

4.4. Optimization of Access Control Policies

The optimization of access control policies is crucial to ensure that these rules are both efficient and conflict free. This process involves identifying and resolving conflicts and redundancies in rules. The Jena inference engine, an open-source framework for processing and reasoning over RDF data, plays a pivotal role in this optimization process. Jena provides a suite of tools and APIs that facilitate various inference tasks on RDF data, including ontology-based inference, rule inference, and data integration, making it an ideal choice for optimizing access control policies within the context of logistics business collaboration. The main steps for optimizing access policies using the Jena inference engine are as follows:

(1)

Initialization and Parsing

The first step is to initialize Jena and parse the OWL file, which is a description file automatically generated by the system after creating the access control ontology in Protege as described in Section 4.2. This file contains essential information such as ontology names and class relationships (e.g., parent–child relationships). Parsing this file enables the Jena inference engine to comprehend the ontology’s structure and semantics. The content structure of the parsed OWL file is shown in Figure 4.

(2)

Reading Policy Files

Following the ontology parsing, Jena also needs to read a policy file with a ‘.rules‘ suffix, containing all the access control rules defined in the SWRL language. Part of the content in the parsed rules file is shown in Figure 5. This operation allows Jena to reason over the rules set against the defined ontology.

(3)

Detecting Conflicts and Redundancies

Jena’s reasoning results are then leveraged to detect conflicts and redundancies, and further to correct them. For instance, in the access control rules, logistics delivery personnel are granted access to the delivery address. However, in actual operation, users define a rule that “does not allow logistics delivery personnel to access the delivery address”, resulting in rule conflicts. Upon detecting conflicts or redundancies, manual intervention is required to resolve these issues. While Jena can identify problems, it lacks the capability to autonomously resolve them. Therefore, adjustments to the rules must be made manually to ensure they are logical and consistent. When dealing with rule conflicts, it is essential to prioritize rules based on their importance. Typically, user-defined rules are considered to have higher priority than pre-defined rules.

(4)

Rule File Management

The Jena inference engine allows users to place rules in a separate file for program calls. This enables the division of logistics rules into different files, which can be imported as required. This approach effectively prevents the issue of slow system response speed caused by a large rule library. Furthermore, because rule files are independent of the application, they can be dynamically added, deleted, or modified without impacting the overall system.

There are several benefits to optimizing access policies using the Jena inference engine:

(1)

Dynamic Rule Management

Facilitates the dynamic management of rules through separate, easily modifiable files, enhancing system flexibility and responsiveness.

(2)

Conflict Resolution

Identifies and helps resolve conflicts in access control rules, ensuring semantic consistency.

(3)

Redundancy Elimination

Detects and allows for the removal of redundant rules, streamlining the rule set for efficiency.

In summary, the Jena inference engine offers a robust framework for optimizing access control policies within the logistics domain. By leveraging Jena’s capabilities, logistics organizations can ensure that their access control policies are both effective and aligned with the semantics of their collaborative operations, thereby enhancing data security and operational efficiency.

5. Semantic-Based Trusted Data Access Control Process

In this section, we will introduce the semantic-based trusted data access control architecture and the trusted data access control process, and innovatively improve the traditional virtual knowledge graph tool Ontop by integrating advanced access control features, abbreviated as AC_Ontop.

5.1. Architectural Components of AC_Ontop

The architecture of the proposed semantic-based trusted data access control consists of 6 modules as shown in Figure 6.

• Input Layer: Manages database connection, generates SQL queries from SPARQL requests and transforms data for knowledge graph construction and querying.
• Ontop Core Layer: Includes modules for parsing and optimizing SPARQL queries, generating SQL queries and managing access control policies with an Access Control Agent.
• Api Layer: Provides interfaces for user and application interactions with the Knowledge Graph system.
• Application Layer: Focus on development and implementation of practical applications suing knowledge graphs.
• Authorizing Identity Layer and Verification Layer: We employ blockchain technology for identity verification and authorization, introducing a layer that offers standardized interfaces and unified specifications to integrate identity authentication management modules across diverse transportation mode business information systems into a consolidated distributed digital identity authentication system. This approach addresses challenges posed by inconsistent identity identification structures among systems, complexities in securing cross-platform identity information flows, and intricate cross-domain identity authentication procedures. The identity verification and authorization process is structured into five distinct modules, encompassing eight meticulous steps, as shown in Figure 7.

Initially, the applicant submits application information through the registration portal to initiate the registration process (step 1). Then send the identity registration request to the administrator to verify the user’s identity. When the verification process is successfully completed, issue the registration key to the user (steps 2 and 3). After receiving the registration key, the registration site initiates a request to the certificate authority (CA) server of the blockchain. The CA server performs the registration and activation process of smart contract 1, where identity information will be recorded in the blockchain. In addition, the CA server returns the public key, private key, and other related details to the user (steps 4 and 5). The registration portal stores the user’s public key in IPFS to simplify the management and retrieval of public keys. IPFS returns a unique CID for the public key (steps 6 and 7). In the final step, users obtain their private keys and are responsible for their secure storage (step 8).

5.2. Semantic-Based Trusted Data Access Control Process

The semantic-based trusted data access process is shown in Figure 8. As mentioned above, the access control agent is responsible for access control judgement and the management of user access control policies. The access control mechanism is initiated when an access request is found, and it returns a decision to allow or deny. Also initiated is the SPARQL endpoint, which allows the user to retrieve RDF data using the SPARQL query language, which allows the user to query and retrieve data from the database in a semantic manner without having to understand the underlying relational database structure. Ontology mapping solves the problem of data heterogeneity by using a unified standard ontology to establish a semantic association with the data source. The access control agent and ontology mapping obtain ontology information from the ontology cloud manager. The set of access policies about the data is written by the data owner according to the SWRL standard, and each policy defines two possible outcomes: permit or deny. To resolve policy conflicts, the system comes with a policy conflict detection that helps the user to check if the rule is correct. The encryption and decryption agents utilize blockchain public and private keys for their encryption and decryption operations. The process ensures secure and authorized data access through several key steps:

Step1: Identity Registration and Access Request. The data requester registers its identity in the blockchain, selects the needed content according to the standard data dictionary, sends an access request, then generates a token. The token carries the access request, the waybill number, the data owner ID, the data requester’s attribute information, and the public key. The subject instance is automatically created based on the data requester’s attribute information.

Step2: Access control and SPARQL Query Processing. When the system receives an access request, it calls the Access Control Agent and SPARQL Endpoint, respectively. The SPARQL endpoint stores the query results in a virtual table, while the access control agent, based on the set of access control policies pre-defined by the data owner, uses the reasoning engine to determine whether the data visitor is allowed to access. Based on the judgement result, the system will return an access decision of allow or deny. If access is allowed, the system will retrieve the corresponding data from the virtual table.

Step3: Data Encryption and Retrieval. The data taken out are encrypted through the encryption and decryption agent. Authorized data are encrypted using the requester’s public key before transmission. The requester then uses its own private key to decrypt the data.

6. Use Case

To evaluate the effectiveness and practicability of the proposed trusted data access control mechanism, grounded in the semantics of collaborative logistics business process, we conducted a case study within a logistics business scenario. We focused on a logistics collaboration network in Linyi City, involving carriers, suppliers, consignees, and warehousemen. These entities required sharing data and collaborating throughout the business process. For example, Supplier A and Carrier B might need to share access credentials and permission lists through multiple intermediaries for data transmission and sharing. Traditional approaches to this scenario often face challenges such as inadequate data security, inefficient data sharing, and trust issues among partners. However, the proposed model addresses these challenges effectively by assigning standard semantic tags like “shipping location” and “goods status” to share data. This enables the development of a fine-grained access strategy, allowing the data requester to accurately access allowed data, thereby ensuring data security and integrity.

In our use case, User A is identified as a supplier, while Users B and C are warehousemen. All three users initiate access requests to the shipper information field of shipment number 2202004319 within Company A during working hours via an internal network. Notably, User C is in a situation that necessitates privileged access. To regulate access to the shipper information field, Company A formulates two policies, as follows:

Rule1 = Subject(?x) Object(?y) Shipper(?a) hasRole(?x, ?a) Shipper_Information (?y) Worksite(?b) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) -> permit(?x, ?y)

Following Rule1, if the role of entity x is the shipper and the access request to shipper information field y is begun through the intranet during working hours, it is judged that entity x is permitted to access shipper information field y.

Rule2 = Subject(?x) Object(?y) Warehouse_man (?a) hasRole(?x, ?a) Worksite(?b) Shipper_Information (?y) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) -> deny(?x, ?y)

If the role of entity x is the warehouseman, and an access request to shipper information y is begun through the intranet during working hours, then x is denied access to shipper information y. Due to the system automatically adding a "privilege" attribute for each policy result that is ’deny’, an additional policy is introduced, as shown in Rule3.

Rule3 = Subject(?x) Object(?y) Warehouse_man (?a) hasRole(?x, ?a) Worksite(?b) Shipper_Information (?y) WorkingHour(?c) hasTime(?x, ?c) hasLocation(?x, ?b) emergent(?x, true) -> permit(?x, ?y)

If the role of entity x is a warehouseman whose access request is for shipper information field y, and x in particular is really in an emergency situation, it is determined that entity x allows access to shipper information y.

Based on the access control rules defined above, determine whether the three users are allowed to access the shipper information field.

According to the above scenario, experiments are conducted on traditional Ontop and AC_Ontop, and the results of the experiments are shown in

Table 4. Ontop and AC_Ontop test results.

OBDA	Test User	Expected Results	Test Result
AC_Ontop	User A	permit	permit
	User B	deny	deny
	User C	permit	permit
Ontop	User A	permit	permit
	User B	permit	permit
	User C	permit	permit

. The results of the study show that AC_Ontop successfully enhances the security of the data while maintaining the accuracy of the original data query service, which implies that the new addition of the access control model does not negatively affect the data retrieval but rather strengthens the security of the data.

This section also tests the data query time and access inference time separately. Under different numbers of requests, the test time is shown in Figure 9. It can be seen that the data query time and access inference time are both within an acceptable range.

7. Conclusions and Future Work

As the demand for data exchange grows, particularly in the logistics sector, it has become increasingly pressing. The logistics industry involves substantial information exchange and collaboration across various aspects, such as cargo transportation and warehouse management. Consequently, establishing an efficient and reliable data exchange platform, along with a robust data access control mechanism, is of paramount importance to the logistics sector.

This article utilizes semantics in collaborative logistics business processes to establish a trusted data access control mechanism in a decentralized environment. This model not only solves the problem of semantic interoperability between heterogeneous logistics entities, but also achieves unified authorization and access control, thereby addressing the contradiction between user privacy and data sharing. In addition, in order to effectively address the challenges of heterogeneity and data privacy in logistics business entity information systems, and achieve controllable data exchange, this article improves Ontop by integrating the access control scheme proposed in this article into Ontop, named AC_Ontop, on the basis of achieving information exchange and semantic unity among various logistics business entities. This method can not only meet the need for data to remain local, but also ensures controllable data sharing, which helps to improve collaboration and efficiency in the logistics field.

Although the model proposed in this article can solve some of the problems in distributed secure access to logistics data, there are still some issues that need further research, such as rule readability and ease of writing. Our future work will focus on addressing these issues to improve the effectiveness and applicability of the model.