Tuesday, February 21, 2012

Workflow and the Mechanical Turk

I'm reasonably sure I've made this decision before, but I'm making it again: workflow will be in core Decl.

I've been thinking of a Blogger-based task manager (finding tasks defined in Blogger posts). To consider those native tasks, we again need the concept of a map. The result would be something like:
  • Define an API (Blogger) and a filter on it (getting all tasks defined in the blog headers).
  • Map those tasks onto a workflow structure by defining how changes to one view of the data changes the other.
  • Work with the workflow tools built into the language.
What those tools will end up being is somewhat vague, of course, but essentially workflow will let us define when the system checks for changes to tasks, and what it will do when there are changes found. Any data source can then be mapped onto workflow tasks and treated as human interaction.

Case in point: here's an article comparing oDesk and Mechanical Turk. Imagine if we mapped both oDesk and MTurk onto a common API, then represented the whole thing as a parallel workflow with job queues farmed out to oDesk and MTurk. Fast, scalable tasks would go to the Turk, while longer-term relationships with trained workers could be modeled on oDesk. Quality control for MTurk might be built into the API, or it might be explicitly represented in a workflow module - that's obviously an open question, but hopefully it makes you think about the possibilities inherent in giving your programs human intelligence, quasi built into the language.

No comments:

Post a Comment