AvengerPenguin

Ah, that's quite a neat idea really. I do think you're going to have to stick to a fixed syntax here though. People are already familiar with the standards of "Re: and Fw:" on the Internet, so it's not that far-fetched for people to learn "Todo:", "Followup:" and "Remind:".

My overall suggestion would be to go with that (you could even tell users to press the "forward" button then replace "fw" with one of three commands). Then you can go with my suggestion of normalising caps, punctuation and even stemming to the first few letters to as to make it as forgiving as possible. e.g., FOL would even match a typo like Fololw-up ;-)

That way, it could expect all subject lines in the form:

  Command: Text @ Date

with date being optional perhaps. A standard regex or even just a split() would be fine here. If there's an error at any point, a standard help bounce would be good (think the --help text you get when you misuse a UNIX command).

I really don't think it's unreasonable to expect users to get the command bit right, so the problem really is reduced to getting the date bit parsed correctly for which I've seen two suggestions here already.

p.s. One possible future thing could be to make extensions for things like Thunderbird that actually gives a "Todo", "Remind" and "Follow-up" buttons alongside the "Reply" and "Forward" buttons ;-)

Also remember that some ways are impossible to tell apart. 12/10/2008, for example, is 12th October for us in the UK, but 10th December for Americans. There's simply no way to guess at which it is without some context or the user saying which.

What that shows is that while NLP can make systems seem quite intelligent, it's really not a replacement for the user putting some thought into it too. Forms work nicely as they can force input into certain formats. I like NLP, so I always think systems could at least meet a human half way on this.

However, even if we were talking face to face, there's some social expectation you'll try to make some sense (i.e. speak in English). You wouldn't just speak Spanish to me if I hadn't indicated I could speak Spanish. AI-like systems are meant to be intelligent, not psychic -- a point often forgotten by some people.

A dialogue system would help uncertainties since it could ask for clarification (which, frankly, is all we humans do if something's not clear when talking to each other), but if you're talking over email, you really want to get it right the first time as it's not the fastest system.

Again, off the top of my head: I'd say you could make it clear that the subject of the email has to be one of "reminder", "followup" or "todo"... then do some aggressive normalisation on the subject lines that come in (grab a Porter Stemmer or even just take the first 3/4 letters maybe) then force to upper or lower and then check against a massive list of synonyms. Then you simply have to bounce with a help notice if someone really still managed to enter something stupid.

Examples: Subject: Reminder -> REMINDER -> REM -> matches rule for "REM/EVE/HOL" (Reminder, event, holiday) Subject: event -> EVENT -> EVE -> matches rule for "REM/EVE/HOL" Subject: follow-up -> FOLLOW-UP -> FOL -> matches rule for "FOL/REV" (follow-up, review)

That sort of idea. It accounts for RaNDom CapITAlisation, uncertain hyphen-usage and plurals. Make those match rules long enough and you might get error rate pretty low indeed.

I know you've probably already gone over this, but does it really need to be email? Is that the best interface? Is it worth taking a step back (going outside the box, as they say) and working out the most efficient method?

Despite all my obvious love for NLP and grammars, I would actually like to echo markessien's point here.

I agree that NLP might not be the best approach here, especially if you're having to learn all of it from scratch (I'm no expert but I learnt enough basics so that I could look into any aspect in more depth when it comes to it).

My first suggestion would be to take a step back and think about what the system is and what is the easiest, fastest and most intuitive way to input dates. Brainstorm this and you will come up with good ideas like those above.

I like the autocomplete idea and also there's no reason not to use some syntax like "Dentist @ 2pm", i.e. using @ to separate title from date. It's sufficient to indicate to the machine which is text and which is date info, but close enough to natural speech as well (also the @ is a very recognisable character now).

One thing to note is that Google Calendar accepts expressions such as "Dentist at 2pm"; perhaps you can try that and see how you like how that works?

"Remind" might solve the date side of it, but you'll still need to parse it out. I've thought about a similar thing before and the approach I was looking to take was using something like: http://www.nltk.org/ to create grammar trees (read up on how grammars/parsers work at least on Wikipedia) for an acceptable subset of English.

You might notice things like a time is always after "at", a date "on" and a relative date "in". Ideas for rules:

  Event -> Title When
  Title -> <anything>
  When -> TimeSpecifier When
  TimeSpecifier -> "at" Time
  TimeSpecifier -> "in" RelativeTime
  TimeSpecifier -> "on" Date
  ...

Then you use semantics stuff to get the parser to return some expression that you can use, say a Python call: event(title=<title>, at=<time>, on=<date>).

Just some things to think about and if you don't know grammars, then read up until you understand the example I gave at least. I just wrote it off the top of my head too, so I'm sure someone might find a mistake with it :-)

p.s. If you're as weird as me, you might even consider Prolog for parsing ;-)

The old unix reminder system, "remind", is what I use as the core of my calendar system. It's very good at parsing dates in different formats and is based on text files with lines such as "REM <date string> MSG <text relevant to event>".

The reason I like it is the fact systems such as your idea there could possibly be built on top of it. Say you parsed out any portion you saw as a date string and put that at the front, it might be smart enough to handle several date string formats.