One comment of the reviewers of the SOCA paper made us think about a very basic issue when invoking human provided services. The issue concerns the communication means that is used to communicate with the human behind the service interface. In particular, we noted that efforts are directed towards the software side of the service: it was considered important to provide a service (interface) that is software compatible. Examples for this approach include WS Human Task or Human Provided Services (HPS) which allow the integration of humans into existing (BPEL) workflows. This leads to a conceptual architecture of three layers:

1. Layer: The software interface (e.g., WSDL, WADL)
2. Layer: Human Computer Interface (e.g., Shell, eMail, GUIs, Web Forms, Software Tools)
3. Layer: Human (e.g., Delegation, Support, Relations between people, Social Networks)

However, both, HPS and WS-Human Task, do not address the interaction between humans and software: they are primarily concerned with seamlessly including human activities and make these as software service available. Therefore, they basically cover layer 1 and a small subset of layer 2 of the conceptual architecture.

We propose the concept of a Human Assisted Service Environment (HASE) that encompasses all three layers. In particular, HASE provides mechanisms to support humans in providing Services in with a standardized (software) interface on layer 1, human readable service interactions (layer 2) and the ability to address the “social aspects” of service provision like delegating a task or asking for assistance (layer 3).

These three issues are addressed by Tweetflows that is the foundation of HASE. At layer 1, Tweetflows are used to describe the interface of the Service with a simple, human and software readable description. Tweetflows have a simple syntax that is closely related to natural language and include meta information that is structured so that is can be interpreted by software parsers.

At layer 2 Tweetflows are used to handle the interaction with the human that provided the service (in combination with other software tools). Tweetflows support the need for asynchronous, decoupled communication: humans do not necessarily provide a service right away. For example, the review of a scientific paper is a service that takes several weeks to complete. Such a request is typically never executed synchronously; the reviewer organizes these tasks in (priority) queues and executes them later.
Therefore, we introduce the concept of a social tuple space where service requests are temporarily stored and made accessible in the social network of the service provider. Thus, the service provide (i.e., the human) is able to handle service requests asynchronously.
In addition, with Tweetflows we include the ability to mix software tools that require human intervention; the software that intercepts the Tweetflow command can provide a part of the overall service and the human asserts the quality and finishes it. For example, the review service could include a software spell checker that is automatically executed when a corresponding service request arrives.

At layer 3, Tweetflows are used in the social network of the human. On layer 3, we can observe similarities to crowdsourcing. However, the main difference is the focus on the social network of the service provider. Unlike crowdsourcing platforms like Amazon Mechanical Turk (AMT), there are no marketplaces that are used to discover services. Furthermore, service providers are “known” – they are connected as friends with the service requester and also have visible connections among each other.
With Tweetflows, we are able to implement the village paradigm: like in villages, where people know each other and their services, the social network of a human service provider consists of people that know each other.

your ikangai science team