So far, the Web of Data (WoD) has only marginally considered the problem of nancing itself. In most of the cases, research funds (either public or private) and donations are supporting the creation and maintenance of WoD services. Applying typical Web nancing mechanisms to the WoD is not straightforward, since the machine-processable nature of the WoD introduces new challenges. For example, users may access the data through applications that lter out advertisement. We believe that delayed-answer auctions are a possible way to overcome such a problem: when a user submits a query, the SPARQL endpoint serves the answers in sequence of batches. Behind the scenes, sponsors bid to increase the chances that data they are interested in promoting appears at the beginning of the sequence. In this demo, we show how this delayed-answer auction can be realized. We built a scenario where users can query for restaurants in New York City and restaurant owners act as sponsors.
The Web of Data (WoD) consists of interlinked data owned and provided by
di erent entities. The result is one giant, distributed RDF graph which stores
knowledge related to all di erent kinds of topics. On a technical level, the WoD
has successfully extended the World Wide Web (WWW) idea, enabling the
integration and querying of distributed and heterogeneous graph data. On an
economical level, however, key concepts and techniques to nance these new services
are lacking behind [
The core idea of the delayed-answer auction is to delay parts of a SPARQL answer to in uence the probability that a certain solution set is considered by the user issuing the query. Given solutions composing a SPARQL query answer, each of them has a di erent delay. Consequently, the solutions are not delivered in one batch, but are delivered in a sequence of batches at di erent time. Naturally, the sooner a solution is provided to the user, the higher the probability that the user considers it. We call sponsors the entities interested in minimizing the delays of certain solutions. However, a sponsor is not just promoting any arbitrary solution, but solutions which contain service links, i.e. URIs to speci c services or Web pages. Examples of sponsors are hotel and restaurant owners, product shops or touristic departments of cities. The delayed-answer auction allows sponsors to increase the chance that a user will consider buying their service, similar to advertisement in the WWW. Unlike advertisement, however, data containing service links are legit solutions to the SPARQL query and do not constitute additional and, potentially, distracting information.
The design of the auction mechanism relies on two key questions: how to assign the delays and how to charge the sponsors. To decide which solution should receive which delay, the mechanism ranks the di erent solutions according to the bids that the included service links receive. A solution containing a service link with a high bid is ranked before a solution containing a service link with a lower bid. This ranked list is used to decide the order on which solutions are returned. It is worth noting that the auctioneer can decide to perturbate this ranked list to allow solutions containing low (or missing) bids to also receive a top position, although with a lower probability. To increase the comprehensibility of our demo, we did not implement such perturbations, however.
In our delayed-answer auction, sponsors only pay if a user actually looks
up the corresponding service link. To determine the actual price a sponsor has
to pay when the service link is looked up, we use the pricing mechanism of
the weighted Vickrey-Clarke-Groves (VCG) auction [
P j=b(i) m
P j=b(i) v2nd j pj 1 (1 prel)Nj
Nj pj 1 (1 prel)Nj
Nj ; where b(i) refers to the batch number of link i|counting starts from the batch with the lowest delay|and m refers to the total number of batches. Nj is the sum of solutions contained in the batches from 1 to j and prel refers to the probability that a speci c solution is relevant to the user|this probability is the same for all solutions and has to be estimated by the auctioneer when setting up the auction. The parameter pj indicates how likely it is that the user stops waiting for more solutions after receiving batch j and selects one of the received solutions, or abandons the search. Again, the pjs have to be estimated by the auctioneer when setting up the auction. Finally, vj2nd indicates highest reported bid in the next batch after batch b(i)1.
It is worth stressing the importance of the delays to create the necessary competition to incentivize sponsors to bid money. Without them, there would be a very limited in uence on the order of the solutions and, consequently, on the probability that a user follows up a certain service link. This is because the inherent structure of a SPARQL query answer allows an application to easily reorder any orderings of the solution one might impose. 3
To show the feasibility of the delay-answer auction and how it works, we built a demo2. The setting is the one of a search engine for restaurants in New York, built on top of some open data service. We used Blazegraph as a triple store and OpenStreetMap3 to collect the restaurant data (converted to RDF).
Outdoor Seating Take Away
Wheelchair Access
1 Select * Where { … } SPARQL query
Look Up http://example.com 6 5 1 7 5 Delay Delay Delay
2 ⋈ 8 Link 3 9 Pay
4 Bid RDF Data RDF Data
1 Interested readers can nd in [
After the di erent solutions have been ordered according to the bids, the query answer ( E ) starts to be sent to the user ( 5 ). The solutions are grouped into batches: a batch is a set of solutions which have the same delay. The delay periods are decided by the auction designer when setting up the auction. The transmission of the answer is therefore asynchronous, and it ends when no more solutions are left, or the user cancels the search. The demo adopts a polling strategy, but pushing strategies are viable as well.
The user interface displays the received solutions on a map, including all available data and the service link. The user can browse through the received results and eventually click on one of the service links ( 6 ) or abandon the search. Clicking on a service link redirects the user to the auction platform ( 7 ), which in turn, redirects the user to the booking page of the restaurant ( 8 ). This redirection is necessary for the auction platform to register the look up of the service link. Once such a look up is registered, the sponsor is charged the respective price ( 9 ).
As we have seen, using the delayed-answer auction, the auctioneer can generate revenue from the payments of the sponsors. In turn, part of this revenue is invested into the datasets of participating data publishers, which solves our problem of nancing datasets in the WoD.
Acknowledgments: This work was partially supported by the Swiss National Science Foundation under grant #153598.