The idea of Tweetflows is to use Twitter as a primary communication means. Tweets are used to invoke (mobile) services and to coordinate crowd-sourced activities that are required to fulfill a certain task. There are some challenges concerning the syntax of the Tweetflow language, due to the limitations of Twitter. First of all, messages cannot be longer than 140 characters. And second of all, messages need to be human- and machine-readable. The former requires a concise and compact syntax, the latter requires a tradeoff decision between expressivity and readability for humans.

1. Requesting a Service on Twitter

The generic syntax to request a service on Twitter consists of the qualifier (SR=service request), an optional user/service provider, the name of the operation, the name of the service, input data and an optional conditional expression:

SR @user{0,1} operation.service inputdata [condition]{0,1}

From the perspective of the service requester, a rough translation of the syntax into a human-readable sentence is the command ” ‘Service provider’ (=user) do (=operation) ‘something’ (=service) with this data (=inputdata) if the condition is true (=condition)”. It will be shown in the examples later-on that a clear separation of service and operation is not always possible and depends on the level of abstraction that is taken and how services are actually modeled. For example, a (hypothetical) service which provides basic mathematical functions like add or square-root can expose its methods either as

math.add
math.square-root

or

number.add
number.square-root

Both naming schemes can be used. The consequence for Tweets is the human readability of service request Tweets:

SR @ikangai add.number num1=2&num2=3 is “closer” to an understandable sentence to humans than SR @ikangai add.math num1=2&num2=3.

However, naming resources and services is a common problem and can be found in virtually all areas of computer science. The discussion of this aspect is out of the scope of this work and we refer the interested reader to articles about DNS or service discovery.

In our approach, Tweets are constructed according to simple English sentences with a subject, followed by a verb and an object (SVO):

Example. SR @johannes2112 proofread.blogentry http://www.ikangai.com/blog

The sample Tweet asks the user @johannes2112, i.e., the provider of the ‘blogentry service’, to proofread the latest blog entry of the ikangai blog.

In the example, a subject (@johannes2112) does (proofread) something (blogentry) with input data (http://www.ikangai.com/blog). Thus, a Tweet is understandable for humans and is at the same time easy to parse because of its standardized structure. It is worth noting that this structure can also be found in RDF triples. We will discuss the consequences in a later section/blog post. We further distinguish between the access to services and the access to resources on the web. We limit the available operations to ‘get’, ‘post’, ‘put’, ‘delete’ in the case of web resources.

Example. SR @johannes2112 get.webpage http://www.ikangai.com/qcard.html
Requests the user @johannes2112 to access the webpage http://www.ikangai.com/qcard.html

2. Service Inputs and Service Outputs

Providing the input for a service has already been shown in the examples above. Basically, input for a service is referenced as an external resource. However, alternatively, the input for a service can also be directly embedded in the Tweet.

Example. SR @joahnnes2112 select.date date1=Monday&date2=Tuesday&date3=Thursday
In the example, the user @joahnnes2112 has to make a selection between three days which are embedded in the Tweet. The parameters are encoded in HTTP request syntax with key-value pairs.

If a service is completed, the service provider tweets the result according the following syntax:

SF @requester didOperation.service outputdata{0,1}

Example. SF @ikangai didProofread.blogentry http://bitl.ly/as212
The sample Tweet reads as “ikangai (=requester), I (=sender of Tweet) did proofread (=didOperation) the blog entry (=service/resource) and the result can be accessed at http://bitl.ly/as212(=outputdata)”. Again, we follow the conventions of the English language and use a syntax readable to humans.

As in the case with service requests, the output of service invocations can also be directly embedded into Tweets. We use a HTTP syntax with key-value pairs that represent the result of a service invocation.

Example. SF @ikangai didSelect.date date=Monday
The service provider posts this Tweet as answer to the Tweet that asks for a selection of a date.

The third alternative is is to make use of an implicit service output variable. This variable contains the result of the last execution of an operation and can be accessed directly by using this syntax:

@user operation.service

Example. @johannes2112 proofread.blogentry
The user, i.e., the service provider @johannes2112, is requested to return the result of the last blog entry service proofread operation. However, special considerations are required for the treatment of implicit service output variables. Most importantly, the service provider needs to specify if the result of a service should be accessible to other users. Unless not stated otherwise, service output variables are available to service requesters. The lifetime of the variables is set by the service provider. The service provider is free to apply any policy that appears necessary; for instance, service output variables may have lifetime of “one access”, i.e., they can be accessed only once.

3. Conditions for the Execution of Services

The execution of services can be coupled to certain conditions, like location, expertise, costs or other quality constraints like response time. The syntax is straightforward:

[name comparator value]

“name” specifies the name of the attribute whose value should be evaluated against some other value. We use a set of basic comparators like “< ",">“, “==”, “!=”.

Example. SR @johannes2112 proofread.blogentry http://www.ikangai.com/blog [importance == High]
Sends a service request to the the user @johannes2112 and sets the deadline to “Monday”. This requires mutual agreement on the meaning of this constraint. A possibility is simply to ask the requester to what “importance” and “High” translates to in terms of time. Again, this discussion is beyond the scope of this work. Interested readers can find material on service level agreements.

your ikangai science team

Tags: Crowdsourcing, Syntax, Tweetflows, Workflow