Web of Needs in a Nutshell

The Web as related to commerce suffers from a fundamental asymmetry. While there is a great number of commercial offers available, consumer needs are rarely represented explicitly. Thus, the most widely applied process of connecting the prospective consumer of a resource with its supplier is Web search. We are developing an infrastructure that will allow consumers to describe and publish their needs and have them interact with offers in a semi-automatic process, reducing the need for manual search and enabling a wide range of unprecedented applications.

The Status Quo

In any society that is based on division of labour, one principle is always present in one form or another: Transfer of resources. This transfer takes place when one actor has control over a resource she is prepared to give away and another feels a need that can be satisfied by obtaining the resource. Thus, these actors are connected by an reciprocal relationship between a need and an offer.

Offer and need differ substantially in their ontological status. Both are abstract notions, intentions of taking part in the transfer of the resource in question. However, an offer appears as the thing being offered, whereas a need always denotes the absence of something, so it can never appear as a physical thing. This difference leads to the form of the marketplace, where physical objects are on display on different kiosks, representing offers. Buyers have no option but to walk from kiosk to kiosk, searching for things that satisfy their needs.

The current state of the Web as related to e-commerce follows this form almost exactly, thereby perpetuating the asymmetry of need and offer: web sites offer goods for sale, amounting to a staggering number of distinct offers. On the other hand, users who want to satisfy a need have to perform Web search and peruse the results in order to find relevant offers. As in the classic marketplace, the users’ needs are unknown to anyone but themselves, and a lot of effort is spent in trying to guess them through the analysis of browsing or buying patterns and similar approaches.

Our Mission Statement

We argue that the traditional form of the market is no longer the necessary form. Web technologies allow for needs as well as offers to be represented as documents of equal status, all published on the Web. Automatic matching services can find suitable pairs for a resource transfer. The transfer itself can be mediated by a protocol, reducing human interaction to a necessary minimum.
Stressing the fundamentally different status of needs in such a system we refer to it as a web of needs.

Our Vision: a Global Need Infrastructure

The primary element of the infrastructure is a common modeling language for specifying needs and offers. They are published as RDF documents according to linked data standards on specialized types of servers referred to as WON nodes. Published need/offer documents are crawled and compared by independent matchmaking services. The owners of suitable need/offer pairs can agree on a transfer using an open protocol, which is routed through the WON nodes, allowing for addressing privacy and trust issues.
For taking part in a transaction, no more is required than implementing the protocol correctly. Users of the infrastructure are not bound to any specific platform or website.

Use Cases
The following use cases will be enabled by the infrastructure:

  • Simple resource transfer – Actor A has control over a resource and is willing to pass it on and actor B needs the resource. Example: Sue would like to go kitesurfing but lacks the equipment. Carol is happy to give her her old kite.
  • Conditional resource transfer – Same as use case 1, with the addition that one (or both) of the actors only want to execute the transfer if some additional condition pertaining to the transaction is met. Example: Sue actually needs the kite within two weeks’ time. She specifies this and requires that the date for the transfer must be fixed within 24 hours so that she has enough time to make alternative arrangements. Carol is fine with that – they close the deal by making an appointment.
  • Combining multiple needs/offers – Same as use case 1, with the addition that one (or both) of the actors only want to execute the transfer in connection with another transfer. Example: Sue actually also needs a kiteboard, so she issues two needs and states that she will only accept one if she can also get the other. Carol accepts these conditions, and so does Peter, who is willing to give Sue one of his old boards.
  • Mutually constrained needs/offers – Same as use case 1, with the addition that Actor A requires resources with properties that are logically linked to each other. Example: Sue wants to go on a kitesurfing holiday to Rhodes. She issues needs for a return flight to Rhodes and accommodation for two weeks, requiring that the dates of flights and accomodation correspond and fall in a specified period of time. Different airlines offer return flights two weeks apart, and different hotels and pensions offer accommodation. Sue chooses among the corresponding offers, which name conditions for payment.
  • Dependency Paths – Actor A requires a resource, actor B is able to produce it, but its production requires other resources.

Example: At the kitebeach, Jill offers training for beginners, depending on someone lending her the equipment for this purpose. She issues an offer for training and a need for each piece of equipment a beginner needs. The offer is combined with the need, allowing her to fulfil the offer only when the needs are satisfied, and vice versa.

Expected Benefit

Assuming the implementation of the WON infrastructure at Web scale with a large user base, we see far-reaching potential consequences. To name a few, it could allow for markets currently fragmented in multiple dimensions, such as location, type of goods, customer segments, type of transfer (such as buying, rental, or barter), or simply by website (Amazon, Ebay, …) to amalgamate into one global marketplace, raising competition and lowering price dispersion. Moreover, consumers could have one interface to that market – their preferred need management service provider – and could get rid of the burden of Web search or search on different platforms. Need and offer descriptions being available even after a transaction has taken place, users could be enabled to formulate new ones based on past ones, making recurring tasks easier to perform. A publicly available history of needs and the offers they were satisfied by would represent an unprecedented resource for making informed political decisions or performing market research. Services could emerge that focus on needs instead of offers, e.g., allowing the re-use and guided improvement of need combinations that have already been used successfully by others, like the combination of needs for flights, hotel, kitesurfing training lessons, and car rental.

Challenges

Building the infrastructure outlined here requires solutions to a number of problems in addition to the design of a description language, protocols and matchmaking, which will be part oft he first major research project. For example, end users need to be provided with intuitive tools to enable them to formulate complex needs, offers, and combinations thereof correctly and with ease. Distribution models need to be devised for the timely transfer of new need or offer descriptions from their origin to the relevant matchmaking services. Moreover, security and trust issues need to be addressed, and privacy concerns have to be balanced with the benefits of openness. Finally, the infrastructure must be connected to existing payment solutions so as to enable serious trading and allow it to unfold its full potential.