DrDubWiki

Printable version | Disclaimers | Privacy policy

Farmer Text Support

From DrDubWiki

In rural areas cell phones are the only access to technology available. This project targets allowing communities to share knowledge through the use of SMS and recorded voice messages. Moreover, it also allows for governmental organizations and NGOs to contribute and track problems in the field.

Contents

Scenario

A person has a question "Can I plant pineapples alongside mangos?", she sends it via SMS to the Farmer Text Support (FTS) server. The FTS then either matches the question to an existing question/answer pair on its database (using techniques for Information Retrieval on Question/Answer archives, an active field of research, see this paper (Retrieval Models for Question and Answer Archives, PDF) or even this patent (Method for retrieving answers from an information retrieval system). If no suitable recorded answer is found, the question is broadcasted to other subscribers via SMS. The subscribers can decide to answer it by calling the FTS and leaving a recorded message, which is added to the DB. The original person asking the question gets the recorded answer and ranks it.

Acknowledgements

The Farmer Text Support was inspired by a presentation given by Helani Galpaya at the first Random Hacks of Kindness Montreal. (Please note that neither Ms. Galpaya nor RHOK endorce this project which is highly experimental at this point.)

En Español

En algunas zonas rurales los teléfonos celulares son el único medio de acceso tecnológico disponible. En este proyecto se busca incentivar el compartir conocimientos dentro de una comunidad por medio de mensajes de texto y grabaciones de mensajes por voz. Como beneficio colateral, habilita también a organizos públicos y no-gubernamentales a ayudar a resolver e identificar problemas en regiones remotas.

Ejemplo: Una persona tiene una pregunta "Puedo plantar mangos junto a los ananás?" y la envía entonces como mensaje de texto al número del proyecto. El sistema busca si la pregunta es similar a una pregunta anterior y de ser asi le llama al teléfono celular y le permite escuchar la respuesta grabada. Si no hay ninguna pregunta similar, el sistema envía a personas puntuales la pregunta vía mensaje de texto. Estas personas pueden por su parte llamar por teléfono y grabar la respuesta. Finalmente, cuando un usuario escucha una respuesta grabada puede decir si satisface su inquietud original o no.

Architecture

GitHub repository: https://github.com/DrDub/farmer_text_support

Component System

Each component is a separate Web server, to allow for implementations of different components in different languages.

They only know about the main controller, which routes all the calls.

The main controller implements all the interfaces.

Major components

  • [Main] Main controller: dispatches to each component and keeps track of unresolved questions. One of the two components that generate events.
  • [User] User repository: records user question history, user contact info (phone number), credits and reputation.
  • [Question] Question Repository: Responsible of maintaining question information.
  • [PBX] SMS and phone gateway: send, receive, track and parse SMS, handles user phone calls, issues phone calls and tracks quality feedbacks.
  • [Answer] Helps find answers by modeling the expertise of each user.

API

  • [Main] Main controller: dispatches to each component and keeps track of unresolved questions
    • Subcomponents
      • Dispatcher
      • Answer tracker
    • API
      • All the other components plus
      • POST register/:component_type (access_url) -> []
  • [Question] Question Repository: Responsible of maintaining question information
    • Subcomponents
      • Question IR component
      • Multimedia storage component
      • Answer reputation tracking
      • Question duplicate tracker
    • API
      • POST question/new (question_text) -> question_id (might be a repeat)
      • GET question/:qid/answer () -> list of answer_id or [] or UNKNOWN_ID
      • GET answer/:aid/sound -> sound _file
      • GET answer/:aid/question -> question_id
      • POST answer/:qid/new (sound_file) -> answer_id
      • POST answer/:aid/status (accepted_yes_no) -> []
  • [User] User repository: records user question history, user contact info (phone number), credits and reputation
    • Subcomponents
      • User contacts
      • User question and answer tracker
      • User reputation tracker
    • API
      • GET user/:uid -> (phone_number)
      • GET user/search/by_contact (phone_number) -> user_id or []
      • GET user/search/by_question (question_id) -> user_id or []
      • POST user/new (phone_number) -> user_id (might be a repeat)
      • POST user/:uid/question/new (question_id) -> []
      • POST user/:uid/answer/new (answer_id) -> []
      • GET user/:uid/answer/:aid/status -> 0, 1, PENDING, UNKNOWN_ID
      • POST user/:uid/answer/:aid/status (accepted_yes_no) -> []
  • [PBX] SMS and phone gateway: send, receive, track and parse SMS, handles user phone calls, issues phone calls and tracks quality feedbacks
    • Subcomponents
      • SMS generator
      • SMS parser
      • SMS router
      • Phone caller (answer sender and general messages)
      • Phone answerer (get question id through touchpad, then reads question aloud, then records answer, reads it back and stores it)
    • API
      • POST pbx/sms/send (user_id, message_type, message_data) -> []
      • POST pbx/phone/call (user_id, message_type, message_data) -> accepted_yes_no or []
        • [USER] GET user/:uid to obtain phone
        • calls, if call fails, returns []
        • reads audio, asks whether the answer is accepted
        • returns 1 if accepted, 0 if not
      • receives SMS
        • [USER] POST user/new, if needed
        • Parse the message
        • [Question] POST question/new, if needed
        • Only message_type so far is 'relay_answer' with message data as a JSON string with one field 'sound_file' with value the local path to a sound file.
      • Receives phone call
        • At this time, only answers are accepted
        • [USER] GET user/search/by_contact
        • [USER] POST user/new, if needed
        • key in question ID
        • [QUESTION] GET question/:id/answers, check for UNKNOWN_ID
        • repeat key in on error
        • (optional) TTS the question to confirm
        • Record the answer
        • (optional) replay the answer for confirmation
        • [QUESTION] POST answer/:qid/new with sound file
  • [Answer] Helps find answers by modeling the expertise of each user.
    • Subcomponents
      • Expert chooser
      • (Internet scout)
      • (Email scout)
    • API
      • POST expert/who (question_id) -> user_id or []
      • POST expert/new_user (user_id) -> []
      • POST expert/new_question (question_id, question_text) -> []
      • POST expert/new_answer (user_id, answer_id) -> []
      • POST expert/new_answer_status (user_id, answer_id, accepted_yes_no) -> []

Event Flow

PBX -> SMS -> {? new user} -> {? new question} -> mark user as needing an answer for question

PBX -> Phone Call -> {? new user} -> get and validate question -> record answer

Main -> Heartbeat -> for unanswered questions, look for experts and bugs them


Startupified Blastoff Hackathon

Minimal demo:

  • SMS with a question
  • Other receives SMS question
  • Other calls with answer
  • Receive call with the recorded message

2nd level demo:

  • Show pre-populated DB
  • SMS with question
  • Get answer right away
  • SMS with unusual question
  • Other receives SMS question, etc

Twitter Integration

https://support.twitter.com/articles/14226


Find

Browse
Main page
Recent changes
Edit
View source
Editing help
This page
Discuss this page
New section
Printable version
Context
Page history
What links here
Related changes
My pages
Log in / create account
Special pages
New pages
File list
Statistics
More...