IKANGAI Solutions. e.u.

Mobile Business Solutions

Posts Tagged ‘Crowdsourcing’

Time and Tweetflows

December 19th, 2012 by Martin No Comments

Time is a fascinating thing. It seems very easy to grasp as a concept for everybody, but when you ask a physicist, things become surprisingly complicated. In computer science, time is often ignored (with the exception of real time systems) when programmers implement software. When events need synchronization of some sort, programmers resort to constructs that use abstractions. For example, if you want to synchronize two distributed processes, you could use logical constructs like semaphores to do this. This is actually much easier than trying to accomplish the same with time based synchronization. Time based synchronization requires that distributed processes have their local clocks in synchronized: only then (and with some clock synchronization algorithms) it is possible to achieve time based synchronization.
Generally speaking, abstracting from time is a good idea and helps programs to be clean, understandable and efficient.
With Tweetflows, I came across an interesting issue concerning time: complex Tweetflows consisting of several commands that are connected with each other need to be published in the reverse order on the timeline of the users. The reason is that on the timeline of the user the newest entry is always on top, because the timeline represents events that go into the past. Computer scientists refer to this kind of structure as a stack, or LIFO queue.
This has the nice side effect that I’m able to integrate dependencies between Tweetflow commands very easily: each Tweetflow command has a unique URL (like Tweets) after it was published. For example the URL

https://twitter.com/ikangai/status/280707058456735744

refers to the Tweetflow command

SR download.qlauncher http://itunes.apple.com/app/id381663352?mt=8/#123456

Thus, after a Tweetflow command is published, we can use its URL in subsequent Tweetflow commands. However, this only works, if Tweetflow commands are published in the reverse order on the timeline of the user. Let me illustrate this with a simple example. We want to ask a user to do three things. First the user should download an App. Then, the user should take a screenshot of the App and upload the screenshot to a web site. Translated into a Tweetflow (without the reference to other Tweetflow commands) this looks like this:

SR download.qlauncher http://itunes.apple.com/app/id381663352?mt=8 SR make.screenshot qlauncher SR upload.screenshot http://www.ikangai.com
When you publish this in the order of the steps (download app, make screenshot, upload picture) on the timeline of a user the result would look like this:

SR upload.screenshot http://www.ikangai.com SR make.screenshot qlauncher SR download.qlauncher http://itunes.apple.com/app/id381663352?mt=8

Thus, we need to publish this in the reverse order to make it understandable for people and to have a meaningful structure. Now, if we include the references the to next Tweetflow command (remember: Tweetflow commands are published in the reverse order and therefore can be referenced) we get this:

SR download.qlauncher http://itunes.apple.com/app/id381663352?mt=8/#.281297742746251264 SR make.screenshot qlauncher #.281297672684584960 SR upload.screenshot http://www.ikangai.com
The number after the hashmark is the reference to the next Tweetflow command and is the control structure of the Tweetflow commands. The reference depends on how the social network handles its data: with Twitter the reference number is part of the URL that points to the Tweet:

https://twitter.com/ikangai/status/281297786471841792

As always in computer science, completing one thing is never enough . Now that we have managed the publication of Tweetflows we still need to look at the execution of Tweetflows and the effects on the timelines of users with respect dynamic changes in Tweetflows, constructs like splits or joins and the management of conditional execution of Tweetflow commands.

your ikangai science team

SAC – Paper Notification

October 16th, 2011 by Martin No Comments

Our paper was accepted at the SAC 2012 as a poster paper. It is not what we hoped for, but considering that the paper is the first tangible scientific result of our work with students (Martin Perebner, Matthias Neumayr), we believe that is a good result. Overall, our presentation had some weakness in terms of the general quality of the paper (e.g., grammar mistakes and typos – ? @johannes2112 proofread.paper) and problems in concerning its technical maturity. We will improve on this and produce an improved version of our paper for the conference.

Since we try to follow an open scientific paper writing process, we would like to share the comments of our reviewers who we thank for their input:

Title: Mobile ad hoc Workflows with Twitter

Authors: Martin Treiber, Daniel Schall, Schahram Dustdar and Christian Scherling
============================================================================
REVIEWER #1
============================================================================

—————————————————————————
Reviewer’s Scores
—————————————————————————

Technical Content and Accuracy: 2
Significance of the Work: 5
Appropriate Title, Introduction, and Conclusion: 3
Overall Organization: 2
Appropriateness for SAC: 6
Style and Clarity of the Paper: 3
Originality of Content: 5
OVERALL RECOMMENDATION: 2

—————————————————————————
Comments
—————————————————————————

The choice of scenario is interesting and convincing, however personally I am a
skeptical of its potential for uptake, as I believe that radio comm will
continue to dominate events organization for some time to come — one factor
that must be considered is the skillset needed for users to take advantage of
this technology. Indeed, what is certainly missing from the paper is a
usability test of this idea in the field.

More fundamentally, it is not clear who does what and when — this is directly
related to my previous        comment. For example, in Listing 4, it is not clear to
me who executes each of these commands. Surely, some human is involved in
taking pictures and videos? so you inherently have humans as workflow actors.
But this does not emerge from your presentation.
It seems to me there are at least three roles: workflow designer, workflow
executor (whoever launches the workflow), and apparently, humans in the loop
who execute some of the actions. It would be good to clearly identify in your
scenario when each of these actions happen (I find it hard to imagine that a
field worker would sit down and assemble a workflow during operations, for
example).

Also, the authors seem to forget to clarify the relationship between a workflow
model and Twitter. Oddly, this is not explained at all and it’s referred to
quite casually for the first time in sec. 3. It still is not clear to me why
the architecture relies on twitter messaging.
is this about exchanging pre-formatted tweets between colleagues? and without
the flexibility of writing your own tweet, it seems.

more detailed comments:

sec 3.        there are many inaccuracies that make the presentation less than
satisfactory.

- what justifies your specific choice of process model? (i.e. no nesting)
- there are odd circularities in some of the definitions, for instance
“Likewise, the ad-hoc and per- sonal characteristics of Tweetflows need to be
addressed by a lightweight workflow language that we call Tweetflows.”

- there are also semantic inaccuracies: “unstructured activities” is not the
same as “a set activities that can be executed in any order”. You seem to refer
to independent activities.
- Similarly: “after an activity is completed, the result serves as input for
the next activity and triggers its execution.”        is not a transitionCondition
that activities can have: it seems inevitable as it’s part of the core process
model.

- “The object describes the type of input.” what “object”? mapping the types
to what?

Related work.
I am not convinced that crowdsourcing is close enough to this work to even
be considered related.

============================================================================
REVIEWER #2
============================================================================

—————————————————————————
Reviewer’s Scores
—————————————————————————

Technical Content and Accuracy: 2
Significance of the Work: 5
Appropriate Title, Introduction, and Conclusion: 4
Overall Organization: 4
Appropriateness for SAC: 7
Style and Clarity of the Paper: 3
Originality of Content: 5
OVERALL RECOMMENDATION: 3

—————————————————————————
Comments
—————————————————————————

Very interesting paper and approach, I quite like the concept explained in that
paper.

Unfortunately, it probably lacks some maturity. I think I would have
appreciated some more detail on how users get to interact with the system in
practice. Some hints are provided but it’s not enough. The use of a personas
and stories approach would have been welcome to give more clarity. Also, the
workflow example would have been a good opportunity for that work, presenting a
small scenario of how people would go through the workflow.

============================================================================
REVIEWER #3
============================================================================

—————————————————————————
Reviewer’s Scores
—————————————————————————

Technical Content and Accuracy: 4
Significance of the Work: 5
Appropriate Title, Introduction, and Conclusion: 3
Overall Organization: 2
Appropriateness for SAC: 5
Style and Clarity of the Paper: 2
Originality of Content: 5
OVERALL RECOMMENDATION: 2

—————————————————————————
Comments
—————————————————————————

General comments
- Too many grammar and spelling errors; more diligent proof reading required b4
submission to a conference or symposium (e.g. third paragraph of introduction:
“to” missing; many more)
- precise definition of “ad hoc workflow and “service workflow” missing (don’t
assume reader to come from BPM community)
- the festival example is intuitive but not presented in a technically deep
enough fashion (what are the exact requirements by stakeholder and what are the
technical design issues that make existing technology like production workflows
inappropriate?); consider using a recognized SE method like OOAD or agile
practices to present the case study accurately
- it did not get clear to me what your contribution is – is it the Tweetflow
language? or did Tweetflow exist already and you use/extend it for mobile
context?
- crowd sourcing kinds of falls out of the blue in Section 3; proper
introduction needed
- Section 3 remains on a rather abstract level, the language is only introduced
via a listing and a table; this makes your novel concepts hard to grasp and
assess; I would recommend to look at leading text books and popular tutorials
for general purpose languages to get a feel for inspiration how to introduce a
language (formal definition of concrete syntax can then go to appendix)
- language introduction in Section 3 contains a lot of comparisons e.g. with
BPEL; this makes the text hard to follow. I would recommend a refactoring so
that the BPEL comparisons are co-located in one section (design principles:
high cohesion in one section, low coupling between sections)

Detailed comments
- Title has the word Twitter, introduction does not mention Twitter at all
- Abstract: which established SOA principles do you leverage? please be precise
- Introduction, 2nd paragraph (p): very shallow arguments against WS-*
(complexity is only perceived, as many production references using WS-* show;
REST has hidden complexities and re-assigns middleware and tool design issues
back to the programmer)
- capitalization of headings and sub-heading is inconsistent e.g. in section
2.2 (Lightweight Workflow Model vs. Ad hoc creation…)
- it did not get clear to me in 2.2 why the BPEL features are not needed/used
for ad hoc coordination; not having BPEL compatible interfaces on mobile
devices is not an argument as one could write adapters, and there is work
around BPEL+REST
- absence of GPS on laptops is not an argument either, see e.g. USB GPS devices
and Web cams (general point: be careful with weak arguments, and claims w/o
evidence)
- don’t assume reader to be familiar with specific concepts such as the Amazon
Mechanical Turk; do you really need the analogy? if yes, please provide brief
introduction and positioning
- Figure 2 appears before Figure 1
- paper ends rather suddenly with a very short section on future work there are
no conclusions and there is no summary

your ikangai science team

SOA principles in mobile Apps

March 17th, 2011 by Martin No Comments

We are currently putting the finishing touches on another paper which we plan to submit to the SOCA journal. One of our main contributions in this paper is the application of SOA (Service Oriented Architecture) principles to existing mobile infrastructures. In particular, we argue that mobile Apps can be considered as Services, App Stores play the same role as Service Registries and the Service Binding process can be applied to Apps. However, there are some details that need additional thought as we apply SOA principles in the mobile domain. First and foremost, the user plays an active role in such environments. It is the user who actively controls the execution of Apps and acts as a gateway to the Service, or the App, respectively. Consequently, the user is potentially a bottleneck if we require appropriate response times and Service throughput. To cope with the problem, we do not consider single users that provide a Service, but a crowd of users that provider a Service. Conceptually, this Service/App network acts as a logical Service provider which consists of a crowd of actual Service instances.
You can find more details a technical report of the Technical University Vienna here (soon available).

your ikangai science team

Student Workshop on Crowd Sourcing

February 22nd, 2011 by Martin No Comments

We have started to work on a concept for a workshop on crowd sourcing. Our goal is to make a two-part workshop for students who are working on projects (internships, Bachelor Thesis, Diploma Thesis) related to crowd sourcing. Part one of the workshop will introduce the theoretical background on crowd sourcing and discuss existing scientific work. The theoretical part will take place at the Distributed Systems Group and is scheduled for one day. During this day, students will have the opportunity to get an overview of the current scientific state of the art in crowd sourcing. During this workshop day, there will be two or three research presentations, followed by discussions and brainstorming sessions. The brainstorming is aimed to give students the opportunity to explain their projects to others, and to discuss challenges with other students.
The second part – the coding week – will take place at a different location (we are thinking of the Ulbinghof Farm in Carinthia in Untergreuth near lake Faakersee) and last one week (five working days). During this week, students can work intensively on their projects and implement the concepts and ideas that were discussed during the theoretical part of the crowd sourcing workshop. The kickoff for the coding week will be about ten days after the theoretical workshop – this gives all participants enough time to think of theoretical background and its implications for their own projects.
A major benefit for students will be that they can cover about a third of the work for an internship (Praktikum) – just by participating in this workshop. The participation is free of charge for students. Students will stay at self-catering apartments during the coding week and the travel expenses will be covered. The location (Ulbinghof) allows for spare time activities like hiking, (mountain-)biking or swimming. The only thing that is left is to find a concrete date for the workshop so that the students can participate.
The bad news is that we, i.e. ikangai, need funding. We are looking for sponsors and will also invest some of our own money in this workshop.

your ikangai science team

Tweetflows – A lightweight, crowd-sourced workflow language on Twitter

February 14th, 2011 by Martin 1 Comment

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

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

Crowdlearning with Students

December 21st, 2010 by Martin No Comments

Inspired by an article that investigated crowdsourcing in the context of proofreading and shortening of (scientific) texts, I have been thinking on how to integrate the idea of crowdsourcing into the teaching of my group. We have already implemented an agile method: regular SCORE project meetings, in which students give a short summary of their project-related activities. During the meetings, students start to discuss with each and get interested in the work of other students. At the same time, students write about their progress and post these reports on the dsg blog. However, there are sometimes ambiguous descriptions in the blog posts as well as grammar mistakes. These are typically corrected by the supervisor. In order to strengthen the work among students and help them to learn from each other, we propose the application of crowdsourcing principles to help students correct each other’s blog entries. In order to support the communication, we intend to use Twitter as a communication medium between students.

The proofreading process works as follows: upon completing a blog entry, the author (student1) tweets it and asks the followers (the other students) to proofread the blog entry and post corrections:

[sourcecode autolinks="false" light="true"]SR #document.proofread <url> [3..5] [/sourcecode]

The url points to the document that requires proofreading. The expression in the square brackets denotes that a minimum of three independent proofreading services are required. If a student decides to make corrections, s/he announces it thus:

[sourcecode autolinks="false" light="true"]SC @student1 #document.proofread <url> [/sourcecode]

If this response (made by student 2) is accepted by the originator of the request, then an acknowledge tweet is posted:

[sourcecode autolinks="false" light="true"]AC @student2 #document.proofread <url>[/sourcecode]

When the corrections are completed, the corrected document is created as a text resource and the link to the corrected text is tweeted:

[sourcecode autolinks="false" light="true"]SF @student1 #document.proofread <url>[/sourcecode]

The correction itself can have many different formats, we suggest to use simple text-based format as shown below:

Pinciples of Oriented Architecture are well adopt for realizing complex distributed Service-based applications (SBA). In this paper, study the applicability of SOA principles for mobile domain with respect to existing infrastructures like App and Apps on mobile devices.
We present both an approach and a middleware platform for the discovery and the invocation of mobile services and show how social aspects of the user can be utilized in such a set- ting.

==correction==
Principles of Service Oriented Architectures are well adopted for realizing complex distributed Service-based applications (SBA). In this paper, we study the applicability of SOA principles for the mobile domain with respect to existing infrastructures like App Stores and
Apps on mobile devices. We present both, an approach and a middleware platform for the discovery and the invocation of mobile services and show how social aspects of the user can be utilized in such a setting.
==correction==

If parts of the text are unclear, an explanation can be requested. If the text is longer than a tweet, an external document can be created, containing the part of the text that needs clarifications or additional explanations:

[sourcecode autolinks="false" light="true"]SR @student1 #document.explain.SBA? <url>[/sourcecode]

The explanation is tweeted as follows (again, it the explanation is longer than a tweet, an external document is created) :

[sourcecode autolinks="false" light="true"]SF @student2 #document.SBA.explained <url>[/sourcecode]

If no further clarification is required and the explanation is accepted, then the following tweet is posted:

[sourcecode autolinks="false" light="true"]AC @student1 #document.SBA.explained <url>[/sourcecode]

The same principles can be applied for all other text-related modifications. For example, if links are missing in parts of the text, this is posted like this:

[sourcecode autolinks="false" light="true"]SR @student1 #document.add.Link? <url>[/sourcecode]

If a link is added, this is tweeted as follows:

[sourcecode autolinks="false" light="true"]SF @student2 #document.Link.Added <url>[/sourcecode]

If the request is accepted, but no link is added (but on a later time), this is posted like this:

[sourcecode autolinks="false" light="true"]AC @student2 #document.Link.Added <url>[/sourcecode]

The basic interaction scheme follows a simply request/reply pattern: [sourcecode autolinks="false" light="true"]SR <servicename>"."<verb in present tense>"."<object>"?"[/sourcecode] is used for requests – the corresponding response is AC/SF [sourcecode autolinks="false" light="true"]<servicename>"."<object>"."<verb in past tense>[/sourcecode]. This interaction scheme matches the command message pattern and is a well adopted enterprise integration pattern.

Your ikangai science team