People frequently use internet-based messaging systems to coordinate. In order to achieve that, it is su cient for them to exchange natural language messages. The message history they generate can be seen as a shared database that can be tapped into by personal assistive systems; moreover, messaging is increasingly used for human-computer communication. However, if natural language understanding is required for such systems to function properly, the cost of developing them is high and only few market players will be able to compete. If, on the other hand, it is possible to mix machine-interpretable data with natural language conversations, assistive or conversational programs may be developed more easily. As a rst important challenge, we tackle the problem of negotiating agreements and unambiguously represent what has been agreed upon in a machine-readable form. In this paper, we propose an extension of the Web of Needs, a decentralized, Linked Data based matching and messaging system, to allow conversation partners to produce a mutually agreed-upon RDF dataset.
Agreement is commonly considered as \a negotiated and typically legally
binding arrangement between parties as to a course of action"[
A third option is gradually evolving in the form of chatbots and other conversational systems. The way such systems are typically built, they mix natural language conversation with structured or semi-structured data exchange, for example by providing natural language patterns for allowing users to perform the equivalent of API function calls, or GUI widgets to ask users for speci c information. This setup allows for more exibility on the side of the service provider. However, the success of the transaction depends on the chatbot understanding the person correctly.
The eld of electronic negotiations research (for a taxonomy of the eld,
see the work by Strobl and Weinhardt [
Motivated by this vision, we describe an extension of a decentralized, Linked
Data based communication system, the Web of Needs (WoN) [
This paper is organized as follows. In Section 2 we explain how our work compares to existing approaches in the eld of electronic negotiation systems. Section 3 establishes the technological background required to understand our contribution. The contribution itself is described in Section 4, which is followed by a discussion of important design decisions in Section 5. 2
This section is divided into two parts. In the rst part we compare our approach with other e-negotiation systems and protocols. Responding to the community's interest, in the second part we compare agreements in WoN to blockchain-based solutions. 2.1
The purpose of the protocol extensions described in this paper is to facilitate
and organize electronic two-party negotiations in the Web of Needs. Systems
that employ Internet technologies (e.g. open Linked Data) and are deployed
on the Web are usually called e-negotiation systems (ENS) [
According to the Montreal Taxonomy [
In the Web of Needs the goal is to support negotiation between humans in
the rst place but keep the system open and structured enough for automated
agent negotiation. Argumentation based negotiation approaches [
These structured agreements are more than just an interaction history of
messages and can be compared to what is referred to as commitment stores [
The agreement protocol layer is built on the Web of Needs message protocol
layer, which generates a signed message interaction history for the two
participants of the communication. This guarantees authentication, integrity and
nonrepudiation for agreements or contracts (cf. [
Maturity. WoN is still being developed, the protocol can be expected to change. It has not undergone an independent security review yet, nor is the current protocol documented in full. To the best of our knowledge, nobody has ever seriously tried to hack WoN. Blockchains, on the other hand, are quite mature and widely considered secure.
Network structure. Blockchains are distributed whereas WoN is decentralized. Some WoN nodes are bound to become more important than others (i.e., host more needs). Outage of a WoN node means that all needs it hosts are unavailable.
Data distribution. The blockchain essentially is a transaction log shared by all parties that want to have transactions or sign blocks. In WoN, conversations are data structures shared only between the participants and the WoN nodes they use.
Currency. Blockchain-based smart contracts require some kind of currency. In contrast, a clear design goal in WoN was to build a technological layer for expressing reasons for interaction, establishing contacts, and communicating and to separate this layer from an accounting layer on which payments are made. This decision has two reasons: rst, WoN is not tied to any speci c payment system and may well be able to interface with all of them. Second, for some interactions, payment is not necessary, or may even be detrimental in the sense that they may never occur if they were tied to payment.
Strength of guarantees. The guarantees that can be made for a WoNbased agreement are weaker than a blockchain based smart contract, at least if the blockchain has enough mutually independent miners. In WoN, one must always be prepared to be communicating with an attacker who controls the WoN node she is using. Some of the possible attacks are: a) An attacker can at all times remove all traces of the needs she creates or the conversations she has via those needs at any time from her WoN node. In that case we are left with the complete conversation history on our WoN node, but no counterpart to talk to, or to report to the police, for example. Therefore, additional trust mechanisms may be required. b) An attacker may choose to ignore messages. We will never be able to prove that they received the message if they do not want to. In WoN, you can only prove the message history that both parties have approved. c) An attacker may control her own WoN node as well as the one we are using. As we sign all our messages, our WoN node cannot fake our messages, but it can decide to drop them, or to drop messages coming from the counterpart. From our point of view, the conversation will consist of all messages that were let through.
Fake interactions. Because no proof of work or proof of stake is required in WoN, it is always possible to set up fake conversations, which may be used in an attack to trick users into thinking a participant has been around for a long time and received many positive reviews (another feature we're planning), but in fact has just set up a new fake need. In contrast, the data in a blockchain cannot be faked.
Self-execution of contracts. In the ethereum system, contracts are written in a programming language, such that they react to state changes in the blockchain. In WoN, agreements as proposed in this paper are just arbitrary RDF datasets that the participants agree upon, i.e., static data. However, it does seem possible to achieve similar functionality by embedding e.g. SHACL shapes, SPARQL queries, or Javascript in a WoN agreement and de ning how that code is to be evaluated. 3
Our approach for the negotiation of agreements over Linked Data is based on the Web of Needs (WoN) architecture. In this section, we explain the aspects of WoN that are required to understand our approach.
The central idea of WoN is to connect people or software agents based on their intentions, or as we call them, needs, in a decentralized infrastructure built on top of Linked Data and related Web technologies. When their needs have been matched, users of di erent Web domains can establish a communication channel. The architecture does not limit users in the description of their needs, nor is the content of the messages they exchange restricted in any way. One core bene t of this approach is that matchmaking, arguably a highly centralized functionality in today's Web, can be realized in a decentralized fashion. When connected, users have conversations by exchanging messages. In the simplest case, a conversation is a chat session. However, the messages can contain arbitrary RDF data, and they are stored online in an immutable fashion, e ectively providing an add-only RDF store shared between users. They can thus collaboratively build a shared RDF data model of their relationship and use it for aligning their expectations and coordinating their actions. 3.1
Users (or software agents) publish a Linked Data resource on the Web describing their interest in an interaction. This resource is referred to as a need, the agent that created it is its owner, who used an owner application to create the resource, which in turn published it on a server that supports the WoN protocol, called a WoN node. The need description can contain a self-description and a description of the need it should be matched with. Independent matching services can subscribe to changes on the WoN node and crawl their content. Whenever a matching service nds a suitable pair of needs, it informs them of each other's existance. Consequently one could describe a need as a persistent, self-describing search query that can be discovered by other such queries, and that serves as a bi-directional communication proxy.
WoN nodes ful ll two purposes. On the one hand, they store and serve all the data, and on the other hand, they serve as message brokers, routing messages directed at needs and o ering updates via a publish-subscribe system. 3.2
Messages are realized as RDF datasets that are created by owners or WoN nodes, and that are de-referencable under their message URI, minted by the sender, on the sender's WoN node. Message datasets contain three types of graphs: content graphs, envelope graphs and a signature graph. Content graphs can contain any kind of RDF data (including higher-level protocol data, see Section 4) that the sender wants to communicate to the recipient. Envelope graphs contain meta data about the message like the addressing information or references to other envelopes that were created during processing of messages. Both kinds, content and envelope graphs are cryptographically signed during the process of sending and receiving messages. Envelope graphs are added consecutively by each party processing the message, linking them up in a chain. The signature of the last ('outermost') envelope graph in the chain is placed in a signature graph. The rst ('innermost') content graph of a message links to the content graphs and includes their signatures. The structure of a message which is sent from an owner to a WoN nodes is depicted in Figure 1.
A message that is delivered to another need is sent to that need's WoN node,
stored there, and dereferencable on that node under an URI that the sender's
node mints in the recipient's node's URI space. The two copies, the local copy
and the remote copy reference each other so as to make the message delivery
tractable. All participants sign the data they add to the message using their
respective WebID [
We de ne D to be the set of all possible RDF datasets. The boolean-valued function isMsg : D ! ftrue; f alseg indicates whether a given dataset is a processable message. M = fm 2 DjisMsg(m) = trueg is the set of all possible messages. As messages do not have default graphs, messages are sets of named graphs, i.e. M P(I G), where P denotes the powerset, I denotes the set of all possible IRIs, and G denotes the set of all possible RDF graphs.
A WoN node always responds to a message it receives with a SuccessResponse or a FailureResponse message, which is itself delivered to the sender of the original message and stored on the WoN node. The sender of a message may either be an owner, a remote node, or the WoN node itself. A message is referred to as failed if any of the WoN nodes involved responds with a FailureResponse message. If at least one of the WoN nodes does not respond to the message at all, it is referred to as ignored. We use the boolean valued functions failed : I P(M) ! ftrue; f alseg and ignored : I P(M) ! ftrue; f alseg to express that a message with a given IRI has failed or was ignored in a given set of messages. 3.3
A need is created by sending a Create message containing the need description along with a public key to a WoN node. The need creator mints two URIs in the URI space of the WoN node in the process, the message URI (as explained above) and the Need URI. The latter is used as the root resource of the need description. Upon receiving the message, the WoN node makes the need description available as Linked Data and responds with a SuccessResponse.3
Need owners can ask other needs to establish a Connection by performing a
handshake of a Connect and an Open message (or a Close message to deny
the connection). Matching services can suggest a connection by sending a Hint
message to one or both of the needs involved. In that case, the connection is
created by the WoN node, but the owners still have to establish the connection
by an Open/Open handshake. In an established connection, the need objects
can freely exchange ConnectionMessage messages.3 The exchanged messages
form two parallel signature chains on both WoN nodes as new messages refer to
signatures of earlier (formerly unreferenced) messages. Moreover, these chains
reference each other since each transferred message contains a reference to its
remote copy. The message chain structure resulting from connecting two needs
is depicted in Figure 2.
3 In an earlier work [
Needs and connections have event containers, which are modeled after
pageable LDP containers[
When processed by the WoN node, an envelope graph is added to the message. Besides other message metadata, references to previous messages in the same event container are added in the form of signature references citing the signature value. By doing so, all messages become part of a signature chain, making message modi cation prohibitively hard, as signatures depend on signatures created by the two owners and up to two nodes involved in a conversation. When a connection is created for a need, the rst message in the connection references the need's create message, thereby tying the need's messages to the connection's. 4
In the following, we consider a conversation between two need owners, o1 and o2 that connects their needs n1 and n2 via their connections c1 and c2.
The conversation is the union of all messages that are accessible to o1 in the conversation with o2, at the point in time when m is the last message seen by o1. This point in time is de ned as either the reception of the remote response if o1 is the sender of m. If o1 is the recipient, the point is de ned as the time the response to m in c1 is sent.
The set of all possible conversations is de ned as the powerset of all possible messages C = P(M) (which, as stated earlier, is equal to P(I G)). We de ne the raw conversation dataset Cr(o1; o2; m) as the union of all messages in the 4 Note that the current implementation of WoN is not based on LDP, it only uses the paging interface of LDP containers. event containers of n1; n2 and c1. As we will regard o1 and o2 as xed for the remainder of the paper, describing the situation from the point of view of o1, we will write Cr(m) instead of Cr(o1; o2; m).
The raw conversation dataset consists of all messages exchanged, or attempted to be exchanged. It is used to verify the integrity of the message history based on the chain of message signatures. It can be seen as a monotonically growing RDF store that the participants can only manipulate by adding messages. In the context of WoN, this dataset is intended to be used as a device that allows users to coordinate, that is, to build a shared, and at least partly agreed-upon model of their relationship. In order to allow for the latter, we de ne higher-level conversation protocols based on Cr. For doing this, we rst make some auxiliary de nitions:
The function iri : M ! I gives the IRI of the input message.
The function iris : C ! I yields the IRIs of all all message in the speci ed conversation dataset.
The function msg : I C ! M yields the message dataset of the message with the speci ed IRI in the speci ed conversation dataset.
The function sender : I C ! I yields the IRI of the sender of the input message.
The function happenBefore : I I C ! ftrue; f alseg is true if there is a signature reference path in C from the message identi ed by the second IRI and all of its Responses to the message identi ed by the rst IRI and all of its responses, respectively.
The function content : I C ! G yields the union of all content graphs of the message with the speci ed IRI in the speci ed conversation dataset.
The function strip : M ! M removes all content graphs from the input message.
In the following we de ne a number of conversation protocols based on these de ntions. 4.1
As stated earlier, message delivery can fail, and messages can be ignored. In both cases, we are dealing with messages that were not provably delivered to the conversation partner. In this protocol layer, we want to present only the content that was provably delivered, therefore we exclude the content of these messages in the acknowledged selection Sack : C ! C: where
Sack(C) =
[ m2iris(C)
cleanup(m; C) 8 strip(msg(m)) if failed(m; C) = true cleanup(m; C) = < _ ignored(m; C) = true : msg(m) otherwise (1) (2) 4.2
We intend to allow participants to specify SHACL shapes [
For modelling the modi cation of messages, we introduce the Modi cation ontology5, pre xed 'mod'. It speci es only one ObjectProperty, mod:retracts, that is used in triples linking two message IRIs, the subject being the retracting message, the object being the retracted message.
The function retracts : I C ! P(I) returns all message IRIs linked to from the input message via mod:retracts in any of its content graphs. The function isRetracted : I C ! ftrue; f alseg is de ned as follows: isRetracted(m; C) = m 2 iris(C) ^ 9r 2 iris(C) : m 2 retracts(r; C) ^ sender(m; C) = sender(r; C) ^ happenBefore(r; m; C) = true
The modi cation functionality is provided by the modi cation selection Smod : C ! C as
Smod(C) =
[ m2iris(Sack(C))
modifyMessage(m; Sack(C)) where modifyMessage(m; C) = 8 strip(msg(m)) if isRetracted(m; C) = true <
strip(msg(m)) if retracts(m; C) 6= ; : msg(m) otherwise (3) (4) (5)
The e ect of this selection is that the content graphs of retracted messages and those of the retracting messages are removed in the result. The selection is applied to Sack, hence modi cations only have an e ect if they do not fail and are not ignored.
The messages referenced through the mod:retracts property are said to be retracted. 5 See http://purl.org/webofneeds/modification [2017/07/23]. The fact that the message history can be modi ed does not mean that both participants agree on anything. It just allows them to revise earlier statements, which is not su cient to coordinate actions between agents. In order to coordinate, it is required to come to a shared understanding about facts, which requires that the agents state the facts and that they signal each other that they agree on them. In the Semantic Web, the core of such an agreement naturally is a set of triples. Consequently, the agreement protocol allows the participants to select a set of triples as agreed-upon.
The result is formally de ned as the agreement function Fagr : C ! D, yielding a dataset in which each graph corresponds to one agreement in the conversation C and the associated graph name is an IRI that identi es the agreement.6 In the following, we de ne Fagr.
In order to represent agreements, we allow participants to propose the content graphs of a set of earlier messages as the content of an agreement, to accept a proposed agreement, and to cancel an accepted agreement.
Again, we introduce an ontology, the Agreement ontology7, pre xed 'agr' that de nes the properties agr:proposes, agr:proposesToCancel, and agr: accepts, and the classes agr:Proposal and agr:Agreement.
agr:proposes, domain agr:Proposal, is used to link the IRIs of two messages p and c in a triple iri(p) agr:proposes iri(c). Such a triple only has an e ect in this protocol if it occurs in a content graph of p, making p a proposal that can be accepted. We call the message c an clause of the proposal. There is no limit on the number of clauses in a proposal.
agr:accepts, domain agr:Agreement, is used to link the IRIs of two messages a and p in a triple iri(a) agr:accepts iri(p). Such a triple only has an e ect in this protocol if it occurs in the content graph of a if p is actually a proposal. In that case, we say that a accepts the proposal p. There is no limit to the number of proposals that can be accepted by one message a.
agr:proposesToCancel, domain agr:Proposal is used to link the IRIs of two messages a2 and a1 in a triple iri(a2) agr:proposesToCancel iri(a1). Such a triple only has an e ect in this protocol if it occurs in a content graph of a2, if a1 is an earlier agreement that has not been canceled yet
There are no restrictions concerning the combined use of these properties in one content graph, that is, one message can accept any number of proposals, propose any number of other messages, and propose to cancel any number of agreements. As will be explained in the following, the e ects of these statements do not in uence each other. It is thus possible to propose an agremeent that replaces another one by mixing agr:proposes and agr:proposesToCancel. It is even possible to make a proposal and agree to another proposal in one message.
The agreement protocol depends on the acknowledgement protocol and on the modi cation protocol: We want to make sure that only provably delivered messages can play a role in the agreement protocol, and we want to allow that until accepted, proposals and clauses can be retracted. However, after its acceptance, an agreement must remain una ected by later retractions - the only way to get rid of an agreement must be to make a new one that cancels it.
For de ning the agreement function we need to make some auxiliary de nitions:
accepts : I C ! P(I) returns all message IRIs linked to from the input message via agr:accepts in any of its content graphs.
proposes : I C ! P(I) gives all the message IRIs the input message links to via agr:proposes in any of its content graphs. 6 Note that Fagr, in contrast to Smod and Sack, does not simply select named graphs from a dataset. Rather, it selects them and recombines their triples, hence we do not refer to it as a selection. 7 See http://purl.org/webofneeds/agreement [2017/07/23]. proposesToCancel : I C ! P(I) gives all the message IRIs the input message links to via agr:proposesToCancel in any of its content graphs.
hasContent : I C ! ftrue; f alseg) indicates if the message with the speci ed IRI in the speci ed conversation dataset has at least one content graph.
The function isProposal : I C ! ftrue; f alseg is de ned as follows: (6) (7) isProposal(m; C) = isProposal is true for message m in the conversation dataset C if C contains all messages that are proposed or proposed to be canceled. These messages need to happen before m (thereby also disallowing m to propose itself) and need to have at least one content graph. This last condition ensures that such a structure is not a proposal if evaluated over Smod(C) and one or more of its clauses have been retracted, because such a clause does not have a content graph in Smod(C).
The function isAgreement : I C ! ftrue; f alseg is de ned as follows: isAgreement(m; C) = m 2 iris(C) ^ 8p 2 accepts(m; C) : isProposal(p; C) = true ^ happenBefore(p; m; C) = true ^ sender(m; C) 6= sender(p; C): isAgreement is true for message m in C if that message accepts a proposal that was made earlier by the counterpart of the sender of m.
isProposal and isAgreement only regard messages before their input message m, hence they can be evaluated over C(m) instead of C without changing the result. Doing that is actually required if we allow retraction of messages (using Smod), because messages added to C after m may change the result of isProposal and isAgreement. Therefore, for evaluating agreements over Smod, we have to do it at point m in the conversation, or Smod(C(m)), which is used in the following de nitions.
As we want to allow agreements to be cancelled later, we have to distinguish between valid and canceled agreements. The function isValidAgreement : I C ! ftrue; f alseg is de ned as follows: isValidAgreement(m; C) = isAgreement(m; Smod(C(m))) = true ^ :9c 2 iris(C) : isAgreement(c; Smod(C(c))) = true ^ 9p 2 iris(Smod(C(c))) : p 2 accepts(c; Smod(C(c)) ^ m 2 cancels(p; Smod(C(c))): (8)
isValidAgreement is true if agreement m was not canceled by a later agreement c, which would have to accept a message p that proposes to cancel m. Note that c is itself not checked for validity this way, so if c does cancel m, and c is itself cancelled later, m remains cancelled. There is no way to restore a cancelled agreement.
Now that we have de ned valid agreements, we can proceed to show how to calculate the content of one agreement, and how to calculate all contents of all agremeents in the conversation, which is the output of Fagr.
The function clauses : I C ! P (I), yielding the IRIs of all clauses in an agreement (valid or invalid), is de ned as follows: clauses(m; C) = : ; = <8 fc 2 I j c 2 proposes(p; Smod(C(m)))g; p 2 accepts(m; Smod(C(m))) if isAgreement(m; Smod(C(m)) otherwise (9) The function agreementContent : I
C ! D is de ned as follows:
[ c2clauses(m;Smod(C(m)) agreementContent(m; C) = content(c; Smod(C(m)))
The agreement function Fagr, applied to Cr, yields a dataset in which each graph corresponds to one valid agreement in the conversation. The name of each such graph in the result dataset is the IRI of the message that accepted the agreement.8 The triples in each such graph are the union of the triples of all content graphs in all clauses of the agreement. Note that if the agreement has no clauses (i.e., it only cancels other agreements), the corresponding graph is empty.
This construction allows for identifying the messages pertaining to an agreedupon graph by looking up the agreement IRI and follwing agr:accepts and agr:proposes. Likewise, it is simple to ask for canceling an agreement: the IRI required to do that is the IRI associated with the agreement's graph in Fagr(Cr). 8 Thus, the IRI of the accept message denotes two di erent graphs in two di erent datasets - it refers to the accept message in the conversation dataset and to the agreement in the agreement dataset. We choose to accept this ambiguity.
The Web of Needs protocols have been implemented9 and can be tested on a public demonstrator10 The work at hand is part of an e ort to apply WoN in the transportation domain, in which we plan to use agreements for the coordination of transportation jobs (e.g., setting/changing a pick-up or delivery appointment). At this point, we have not implemented agreements yet, so we cannot provide an experimental evaluation of the approach at hand. We will proceed to implementing the extensions described here and evaluate their applicability for that use case in simulations, a case study, and nally in eld study. In this work, we re ect on our solution by discussing some of our design decisions, which we do in the following.
Cascading retracts. The option to retract earlier messages requires the special case to be considered in which the retracted message is itself a retracting one. In designing the protocol, we considered the options to a) to disallow such messages (leading to a failure of the message) b) to let such messages not have any cascading e ect, or c) to let a retract have a cascading e ect. Moreover, we considered enabling a restore operation for retracted messages in combination with a) and b).11 Our decision was guided by simplicity of computation and by an intuitive evaluation of the importance for users. We decided not to support restoring retracted messages as this does not seem to be an important feature of a communication application (judging from state of the art messaging applications), and because such a feature may enable deceiving an unsuspecting user by retracting a message and later silently restoring it. Consequently, we decided to avoid cascading retracts. The computationally simplest solution we found was to de ne a message as retracted if there is a later message retracting it, without checking if that message is retracted, and in addition to that to remove the retracting message itself from the modi ed selection. The same reasoning was applied for designing the cancelling of agreements: it is not possible to restore a cancelled agreement, and cancelling has no cascading e ect.
Granularity of modi cations. When considering the modi cation of the
conversation content, the decision on the granularity of the modi cations has to
be made. We are aware of current discussions of the related patch
functionality12 in LDP[
Retraction may fail. All messages can fail or be ignored. Worse, an
authenticated byzantine participant [
Proposing proposals. Technically, it is possible to propose a proposal or an already agreed-to agreement. The e ect is that the content graph of the proposal or agreement message can become the content of an agreement. The protocol could be adapted to prevent such agreements, but we do not see any harm done by them.
No special message type for retraction and agreement. One may argue for at least some of the messages we introduce in this paper to be realized with new top-level message types. We decided against this and rather opted for a clear separation of communication layers. The basic protocol is used for making connections and exchanging messages. Retraction as well as reaching agreements is about a client-side interpretation of the message history, and consequently we decided to realize that functionality in a separate higher layer. 6
In the work at hand, we propose a new way to interpret a Linked Data based conversation between agents in the Web of Needs as a shared, add-only RDF database. We introduce new protocol layers as views of the raw conversation data available to each participant. These layers provide a) a cleaned-up view, removing the content of failed and ignored messages and b) a modi ed view, allowing participants to retract messages they sent earlier. Using these two layers, we introduce c) an agreement view, enabling the participants to produce a mutually agreed-upon RDF dataset consisting of the RDF payload of selected earlier messages.
The contributions of this work represent one step toward a generic, decentralized (or federated) protocol that supports natural language conversations as a special case of the exchange of arbitrary RDF structures between participants. Therefore, the agreements introduced in this paper may consist of natural language clauses or any other RDF content, supporting negotiations between humans, of humans and software agents, and among software agents.
A related extension currently being designed is an additional protocol allowing agents to de ne information requirements using SHACL shapes, thereby allowing to ask for certain information in a non-ambiguous, machine-processable way. We envision the use of intelligent client-side assistants that may assume different responsibilities such as lling in already known data like the user's home address etc., or organizational tasks like managing appointments on behalf of the user.
We are planning to implement the proposed protocol extensions and evaluate them in the context of transportation by connecting Web APIs of transportation companies to WoN via speci cally designed bots bridging between the two systems.
We would like to express our appreciation for valuable criticism and ideas contributed by Soheil Human, Fabian Suda and Kevin Singer, members of the team at SAT and to Eike Walsdor for guidance on improving the formal de nitions. We would also like to thank the participants of a discussion on the semantic Web mailing list on negotiations for sharing their expertise.11 Finally, this work would not have been possible without the funding in project Open Logistics Networks (OLN), funded by the Austrian Research Promotion Agency in the COIN program.