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