Matchmaking and cooperation are interactions widely available within internet-based platforms. However, to start using such functionality, one must rst become a member of the platform. In an e ort to push matchmaking and cooperation into the protocol stack of the Web, we demonstrate how an existing taxi service is integrated with a decentralized Web based infrastructure, the Web of Needs (WoN), using a chatbot that can be programmed declaratively to enter into certain types of agreements with users. The bot mediates between an existing Web service and users of the RDF-based WoN network.
Business as well as private interactions are increasingly mediated by internet based two-sided or multi-sided platforms. A common trait of all such platforms is the fact that they o er tools for both sides of a transaction, for example, taxi drivers and passengers. Their technology requires that users in both roles be onboarded in a rst step; afterwards, the intention of engaging an interaction is only published within the bounds of the platform and hence can only be satis ed within it.
Arguing that another { more open { mode of interaction is possible, we
have developed a set of protocols we call the Web of Needs(WoN) [
In our applied research, we are aiming for building a WoN-based, decentralized solution for transportation. To get started, we chose the use case of calling a taxi because it is a simple case of transportation allowing for low-cost practical tests. The demo at hand3 shows the implementation of the agreement protocol in combination with automated negotiation. The interaction takes place between us (a human user) and a bot that is connected to the REST interface of a taxi service. First, we use the owner webapp to post the need for a taxi, stating pick-up and destination locations (Figure 2a). Subsequently, we are contacted by the taxi bot (Figure 2b). When announcing its taxi service, the bot sets the won:NoHintForCounterpart ag in its posting, which causes matchers not to send a hint to our posting4. Instead, only the bot is noti ed of an opportunity to interact; it can choose whether to make an o er or not. In our case, the bot connects with us, we accept the connection, and after the taxi bot has evaluated the data in the conversation (locations, times, etc.) it makes a proposal to execute the ride (Figure 2c). Finally, we accept that proposal (Figure 2d), which therefore becomes an agreement.5 3 See https://matchat.org/ 4 Note that our posting has no matches in Figure 2b 5 Readers should note that the taxi bot that was used in this demo may not be running at all times, and that the outcome of conversations with the bot may vary over time. (c) The taxi bot makes a proposal after (a) Posting a search for a taxi, specifying analyzing the conversation data. start and destination of the ride. (b) Our posting, searching for a taxi, has been contacted by the taxi bot. Next to it, a 'What's Around' posting that matches anything nearby, demonstrating that it is a general purpose application not speci cally made for the taxi use case. (d) We accept the proposal. The taxi bot is sending a taxi.
Fig. 2: Screenshots from the WoN Owner application during the negotiation for a cab ride. The purpose of this prototype is an end-to-end demonstration of a simple transportation use case, so far only showing the initiation of the interaction, for example, calling a cab. The later stages - communication about the actual arrival of the car, the arrival of the passenger, completion of the ride and success of the payment, are planned for future work. Our approach for representing the complete transaction in the conversation consists of representing the transaction as a state machine that can be evaluated independently on either side of the transaction. Our idea is that the initial proposal contains, among other data, the de nition of the state machine that the transaction will then be represented with. The de nition of that state machine contains states and de nes how messages sent by the participants a ect those states.
In addition to this extension of the protocol, we aim for representing and testing more complex cases of goods transports, as well as, eventually, cases from other domains. 4
This work demonstrates outcomes of the projects OLN - Open Logistics Networks, funded by the Austrian Federal Ministry for Digital and Economic A airs in the pogram COIN - Cooperation and Innovation and CoShA - Cooperation and Sharing Applications, funded by the Austrian Ministry for Transport, Innovation and Technology in the program Mobilitat der Zukunft.
However, it is possible to test the agreement functionality with two distinct user accounts.