Using Schema.org and Solid for Linked Data-based Machine-to-Machine Sales Contract Conclusion

Demo at the Web Conference 2022

Two robotic arms, controlled by rule-based Linked Data agents, trade a good in Virtual Reality. The agents follow the necessary steps to conclude a sales contract under German law. To conclude the contract, the agents exchange messages between their Solid Pods. The data in the messages is modelled using suitable terms from Schema.org.

Authors: Xinni Wang, Christoph Braun, Andreas Both, and Tobias Käfer from AIFB @ Karlsruhe Institute of Technology (KIT), Germany and Datev eG, Germany

Watch the video » Get the code » Read the PDF »

Introduction

With social interactions moving to exchange of messages via the inboxes of agents (e.g., natural or legal persons, machines, or canines) in their Solid Pods, we were wondering what is missing in this set-up based on the web architecture to form contracts, such that people, machines (or dogs) can e.g., trade goods. We thus first present the legal procedure to form a contract in real life, then our technical version of the procedure followed by our data modelling. We next give an example of how we implemented the technical procedure using rule-based agents and continue with a discussion on what we think is missing in the web architecture for the interaction to succeed. Last, there is our demo video and code in case you are coming to the demo when the authors are not present.

Meme "On the Internet, nobody knows you're a dog"

The sequence diagram shows the transaction procedure of our demo from a legal point of view. A legally effective sales contract must have an offer. An offer needs to contain all key business conditions (lat. essentialia negotii) such as the good to be traded and the price. After that, there must be an acceptance of the offer without any alterations to the conditions stated in the offer. The customer starts with an invitation for tender for the good to be sold (lat. invitatio ad offerendum). The seller checks the availability of the respective good and makes an offer if the good is in stock. Otherwise, the seller rejects the invitation to tender. If there is an offer from the seller, the customer checks if the price exceeds the customer's limit or its balance. If the limit or the balance is exceeded, the customer rejects the offer. Otherwise, the customer accepts the offer. After the acceptance of the customer, the seller sends an invoice to the customer to indicate a payment in advance. The customer then starts the payment transaction. The seller hands over and transfers the ownership of the good once the payment transaction is successful. If the payment transaction is not successful, the seller withdraws from the sales contract due to non-performance by the customer.

transaction procedure

Interactions in the Technical Implementation of the Legal Process

We assume that all involved agents have Solid Pods, where the agents exchange messages via their inbox. The following sequence diagram shows how exactly the agents communicate with each other for the first two steps of the transaction procedure. The customer agent sends an invitation to tender to the seller's Solid Pod inbox via HTTP POST request. The seller agent sends an HTTP GET request to its own inbox and in return get the invitation to tender sent by the customer agent. The seller agent then sends an offer to the customer's Solid Pod inbox via HTTP POST request. The customer agent sends an HTTP GET request to its own inbox and in return get the offer sent by the seller agent. The seller would first check if the good of the invitation is still in stock before sending the offer. This is not shown in the sequence diagram.

Sequence Diagram for Solid interactions

Data Modelling using schema.org

We model the relevant data for the application in RDF. In the following, we cover the terms for the happy path of the sales contract conclusion between the seller and the customer. That is, we omit details like the payment processing and cancellations (e.g., due to insufficient funds of the customer). The progression of the contract conclusion forms an interlinked set of Linked Data resources.

The involved schema.org classes during the sales contract conclusion. We depict classes as circles and use arrows to denote RDF properties that we used to connect such classes, which respect the schema:domainIncludes and schema:rangeIncludes information on schema.org for the properties. We used the vocabulary as: terms of the W3C ActivityStreams Recommendation outside of the happy path (dotted) and for technical details (dashed), where no suitable terms in schema.org were available.

ontology

Example Rule

The Notation3 code is an exemplary rule for the seller's rule-based Linked Data agent. The rule causes the seller to send an offer to the specified customer's inbox folder via HTTP POST request if the seller owns a certain demanded good. In this case the good is offered for 20 Ether. For the prefix definitions, please consult prefix.cc. We use Notation3 with ASM4LD operational semantics [5].

{
    ?notification a schema:Demand;
        schema:itemOffered ?object.
    ?seller schema:offers ?notification;
        schema:owns ?object.
    ?customer schema:seeks ?notification.
    ?customer ldp:inbox ?inbox.
} => {
  [] http:mthd httpm:POST ;
     http:requestURI ?inbox ;
     http:body {
         <#off> a schema:Offer;
             schema:itemOffered ?object;
             schema:availability schema:InStock;
             schema:price 20 ;
             schema:priceCurrency "ETH".
         ?seller schema:offers <#off>.
         ?customer schema:seeks <#off>.
    } .
} .

Discussion

Legal personality

The legal procedure requires the agents to have the legal capacity to form a contract. Legal personality for machines (and canines) is subject to scholarly discussion, e.g., in robotics. Our demo is about the question: once this question is solved, how to perform the forming of the contract on the web architecture?

Philosophy of Language, the Law, and the Web

What expectations can a recipient of a confirmed order have? Has the agent who confirmed the order legally committed themself to provide a good or service? In other words, has the agent performed a commissive speech act [2]? Can agents perform speech acts by sending HTTP POST requests to inboxes in Solid Pods? That may require to specify semantics for data exchange, as shown in this demo, similar to what the multi-agent systems community has done around the FIPA Agent Communications Language [4].

Semantics of the HTTP POST Request

If we can perform speech acts using HTTP POST requests, what semantics should we apply?

Data Modelling

What vocabularies can be used to describe those speech acts? For our demo, we (ab)used schema.org, the vocabulary of the Activity Streams W3C Recommendation could be another candidate, which has a similar, but in places different, coverage of types of activities. Those vocabularies would need to be enriched with corresponding semantics:

  • Has the customer agent performed a commissive speech act by sending a HTTP POST request with a schema:Demand payload?
  • Or has the customer agent performed a directive speech act since the customer agent is not committing itself to accept an offer regardless of the price but rather sending an invitation to tender?
  • Can the schema:Invoice sent into the inbox be considered an assertive speech act like an order confirmation or would it rather be classified as a directive speech act since the invoice can be seen as a request for payment in advance?

Application Potential: Ecosystems

From an industry perspective, the main potential of a work such as ours, is to enable digital ecosystems across domains, countries, and organisations. A core limitation of current industrial scalability is the effort required to align data formats and service interfaces for interoperability. We believe that the adherence to the Linked Data principles reduces such effort: Given the extensible data format of RDF, enterprises can, at the same time, define use-case specific data models while adhering to globally accepted terminology. Given the ubiquitous HTTP protocol, which builds on the internet, enterprises can interact with software around the globe. As our demo shows, vocabularies with well-defined semantics are a cornerstone for real-world use, e. g. when processes that stem from the legal profession are to be implemented. The Schema.org vocabulary, among others, can be one of the foundations of a growing Linked Data ecosystem. Next to vocabularies, we believe that a cross-organisation ecosystem requires standardised sequences of interactions, as shown in this demo, such that business models of different organisations can get integrated using Linked Data. Solid paves the way, e. g. by building the necessary access control mechanisms.

Screencast about the demo

In the video below, we give an introduction to our demo by giving technical details and presenting a walk-through.

Setup

We built our demonstrator using the publicly available Solid Pods from solidweb.org. This Pod provider runs the Node Solid Server in version 5.6.20. As a user interface for the inboxes in the Solid Pods, we developed the SolidInboxWatcher, a Solid App that monitors an inbox for new and deleted entries and the entries' updates. We used Linked Data-Fu 0.9.12 as agent runtime, patched for the (valid) peculiarities of the Turtle data emitted by the Node Solid Server. The Virtual Reality uses the JMonkey engine in version 3.2.4-stable, for which we wrote a REST interface to the scene graph [3] executed using Jetty 9.2.29 on Java 8. We adapted the contents of the Virtual Reality for the purposes of this demo. The payments went over a privately hosted Ethereum chain, interfaced using Ganache and visualised using MetaMask.

Code

Please find the code for this demo on GitHub.

References

Authors