5.2.1. Functional View of the DMS
As shown in Figure 6
, the peer component is split into two parts: a seller and a buyer side. It can be seen that on the buyer side
, the tasks of the peer component are:
to transform a user’s intention into a complex product request,
to distribute these requests to multiple market spaces,
to receive (partial) complex product offers,
to re-combine them into multiple complete complex product proposals,
to rank them according to the buyer’s context and requirements and
to coordinate the distributed buying transaction.
The buyer side is therefore comprised of the coordinator, the (de-)composer and a ranking component. To describe the complex product request in a domain-agnostic manner, we make use of the well-known Resource Description Framework (RDF) [27
], as it is the predominant technique for machine-readable representations of knowledge
on the web. This allows for the implementation of the peer application in a completely product- and service-agnostic way, so that it can be used for any type of application.
In addition, it enables specifying complex product requests that are comprised of products/services from very different domains. This immediately allows us to integrate an enormous body of existing vocabulary (i.e., ontologies) and world knowledge (i.e., existing machine readable data on the web, such as e.g., DBPedia).
The (de-)composer breaks up complex product requests described in RDF into individual product/service requests and communicates them to the DMS. Upon receiving individual proposals, it re-combines them into multiple complete complex product proposals and passes them to the ranking engine. Given a set P of proposals, the ranking engine can basically be represented as an assignment function , assigning a value to a given vector , which in turn represents a single proposal . Therefore, f can be seen as an objective function, which rates the proposals to a specific order based on its value (i.e., matches better than ). As a consequence, the smallest value of f computed over P denotes the best proposal according to the objective function. It must be noted that even though the terminology is similar, we actually do not cope with the optimization problem due to the impossibility to alter the single values directly; thus, the function is only used for ranking purposes.
User preferences can be expressed as constraints to the objective function. However, since such constraints divide the search space into feasible and infeasible regions, they can be seen as a kind of filter, which removes proposals from the search space and as such does not fit the concept of ranking. Therefore, solving a constrained problem is substituted by solving an unconstrained problem by getting rid of the constraints in favor of a penalty function
], which is added to the objective function’s value. A new unconstrained objective function F
is created, such that
. The result of
increases when user-defined preferences are violated. P
can now, e.g., be utilized to express relationships between proposal properties (e.g., perfect substitutes, etc
.) and other preferences (e.g., quality-over-price measures). In addition, data from the Internet of Things can be integrated in the penalty function to include user context data (e.g., using approaches, such as [47
]), which uses the user’s context (e.g., the current weather) or other IoT sources of data to calculate the penalty for the proposals, so that the best matching proposal is assigned the lowest penalty value. The ranking engine can therefore now assign an objective function value to each given proposal and order them by their objective function value. Other techniques for getting rid of constraints are also feasible and may incorporate methods of repairing infeasible proposals/solutions [49
]. Such approaches may be evaluated in the future.
On the seller side
, the peer component’s tasks are:
On the seller side, the core component is the offer engine, which provides a price tag for each product/service request and sends offers back to the market space. Additionally, the offer engine can encompass further functionalities depending on, i.e., the type and size of the seller (e.g., individuals, institutions or companies), the type of products/services they offer and other seller-related characteristics, which is out of scope of this paper.
The coordinator component is responsible for supervising the whole process and the distributed (buying) transaction. By using the aforementioned model for distributed transaction processing (cf. Section 5.1.1
), the coordinator draws on the transaction management process, assigning identifiers to transactions, monitoring their progress and taking responsibility for transaction completion, as well as for failure recovery and rollback.
The functional structure of the market space is depicted in Figure 7
. The market space re-uses components for de-composition and ranking from the peer application and adds components for matching supply and demand, as well as for the registration of sellers and their offerings.
The matcher component includes the matching service and the underlying domain-agnostic database. The database contains information about registered sellers, as well as the description of available products and services they can potentially offer. Again, these data are encoded in RDF so that the matcher and registration component are independent from the actual product’s domain. However, a market space that specializes, e.g., in tourism may choose to bring in domain knowledge in the form of, e.g., OWL ontologies or sensor data from a city, such that the matching result is improved.
5.2.2. Information View of the DMS
After describing the main functional components of the DMS in the following, we outline the transaction process and provide more details about the information flow and exchanged messages between functional components.
The transaction process shown in Figure 8
is modeled using the Business Process Modeling Notation 2.0 (BPMN 2.0 [50
]). It outlines the main activities within the transaction process, taking the user application perspective, and shows some message exchanges. In the following and as a matter of example, we describe a product/service offering (PSO) message (highlighted in blue) and a decomposed complex product request (PSD) message (highlighted in green).
The messages exchanged in the DMS are RDF documents. In principle, such documents may have arbitrary content, and we could have devised our own proprietary ontology to describe the products/services of our use case. However, as it is good practice in the Semantic Web to reuse existing vocabularies to improve interoperability, we have used existing vocabularies. In the following, we show examples of such messages for the use case described in Section 2.3
, where the user is a tourist planning a theater evening. Due to space constraints, we concentrate on the theater ticket.
As a base for the message description, we use the existing good relation ontology [21
] and, in particular, its domain vocabulary for event tickets. Listing 1
presents a part of an RDF description of the PSO message in Turtle syntax (Terse RDF Triple Language [51
]). The triples state that a particular event is offered by the company TRIO Tickets
and that it is accessible through a particular URI (Uniform Resource Identifier) (Lines 8–11), followed by triples stating details about the offering, e.g., name, description and further price specification (Lines 12–21). The corresponding graph of the PSO message is shown in Figure 9
Listing 1: Exemplary description of a PSO message.
The PSD message on the other hand is described as a SPARQL query [52
] and shown in Listing 2
5.2.3. Demonstrator Implementation
Currently, we have implemented a prototype of our proposed architecture that operates in a headless manner, i.e., we manually craft the complex product request and submit it to the DMS.
The DMS has been implemented in the Java programming language using a standard message queueing system (Apache ActiveMQ [53
]), and the peer applications interact with the DMS by exchanging messages via the message queueing system. The implementation of our prototype is already able to handle the aforementioned use case.
The ranking component is implemented using a very simple objective function
for demonstration purposes where
denotes the price of a theater ticket,
denotes the price of the Italian restaurant and
denotes the distance in meters needed to walk between the stages (which can be easily calculated by geodata information). The function itself is mainly cost-based and can be expressed as
. The penalty function now uses the weather forecast (which is gathered online from the Internet) to weight the distance
. The distance impact on the overall function can be expressed as in example 1.
such that distances loose impact according to the weather forecast. The weather impact given in this example is quite excessive due to demonstration purposes and can be adapted to other values. The overall function
now assigns values to proposals according to the overall objective (price sensitiveness), but still taking user preferences like weather conditions into account. More sophisticated objective and penalty functions can be used to model a more complex ranking behavior and to provide best matches according to user preferences.
Listing 2: Example of a PSD message as a SPARQL query.
A current limitation of the overall system is that we have not yet implemented the distributed transaction in order to buy parts of a complex product/service from different market spaces. In addition, we still have to implement generic ranking algorithms for different types of user-defined ranking. Furthermore, the use of a DHT-based P2P system for the discovery inherently has the problem of finding an entry point to the P2P system. In our current implementation, we use a well-known address for this. The challenge for the future in making the system usable is to provide use-case specific applications that convert user input automatically into complex product requests.