How to interpret vague date input in a search query

This is a follow-up to this question Would an "around" search token make any sense?

If someone is performing a search by date would having an "around" this date feature be useful, and if so, how you would interpret their input. For example what date range would you include in the results if someone specified "around march" as their date query.

EDIT:

The answers so far from @sacohe and @PatomaS have been perfectly sensible, but not quite what I'm looking for, so let me constrain the problem a bit more.

Imagine the dates are mentioned in a witness report for some criminal incident. The report says "It happened around March". The witness the statement was taken from is no longer available, for reasons which I'll let people's fertile imaginations come up with!

Now, we want an algorithm to correlate that "date phrase" with other data in a database of incidents which have known dates. How do we convert that search date into a something we can use in a concrete query. Of course, you may find no matches and have to widen the search, but what would be your best interpretation for your first attempt?

Would you handle the phrases "around 12th March", "around March", "before Christmas" (or other religious/cultural holiday of your choosing) differently? Would the width of the date range be different for each?

4 Answers

One thing to consider is the how far in the past the target date or period is. For instance "around last Tuesday" would have a tighter focus than "around Christmas of 2010". Maybe call this report latency.

I'm an OO programmer so I tend to think in terms of objects. So I'd define a class (or data structure) that represents a range of dates, each date with a likelihood value. Let's call this class VaguePeriod and it's values could be stored in a DB. For simplicity say a likelihood can be from 1 to 100. So the phrase "before last Tuesday" would translate into a VaguePeriod where

• last Tuesday - 1 -> (likelihood=50)
• last Tuesday - 2 -> (likelihood=45)
• last Tuesday - 3 -> (likelihood=40)

etc.

The report latency would determine how this VaguePeriod is constructed, if it's short (recent) the VaguePeriod would be tighter, if it's a long time ago it would be looser, a wider range of lower likelihoods.

So now the hard part is to translate natural language phrases into a VaguePeriod structure, and writing the search algorithm to search using VaguePeriods. Of course the search results wouldn't be boolean, it too would return likelihood values.

• I love the idea of a VaguePeriod object, good name for it! I'd not considered the time between now and the target date as a cause for increased vagueness, but it makes perfect sense, as does fuzzy reporting. Oct 22, 2012 at 0:04

"Around" would be practical for dates searches, but the problem with it is that the perception of how far before and after "around" covers would be different for each person. What I would recommend is a set of options for date searches that specify "within 1 week", "within 1 month", and other logical ranges. Or, if space permits, you could provide a text field for a number and a drop-down for hours, days, weeks, months, years, etc. so they can input "within 4 days" or "within 2 weeks".

• yes, it's exactly that perception of how far around the date that I'm interested in. +1 for a perfectly sensible answer, just not quite the one I'm looking for! Oct 20, 2012 at 17:06

As long as the period is specified to the user, any around would be a good option.

Of course, the best would be to have a few fixed options like 1 week, 2 weeks, 1 month, etc, and one open to the user, in the likes of an input field to write a number and a select for periods, so he can combine things like 1 day, 1 week, 1 month, etc.

Is not exactly what you ask, but I'll consider this as a twofold option, let's say that you can't add the open option in the search area, but you include the fixed ones, the user most probably will choose something, it may not be the period he is thinking, but will choose something, and in the worst case, you will use a default period, then in the results, where you have much more space, you can add a better option for doing a new search. You should also mention in the results the period used, even if the user selected that period.

UPDATE Yes, I'll handle different phrases different, for instance, if you live in a place where Christmas is a frenzy of shopping, that usually starts soon, so the around may be a bit wider than the around of a minor holiday or event related only to the person involved.

I'll try to make the algorithm to consider the smallest period the person mentioned, for instance, if the persons said last week, my search period will be something like that week, plus 3 days before that and half, rounded down the difference of days between last week and today. If the person mentions around march, I'll consider that period with a plus of a week up and down; and so forth for each period mentioned.

Also, if you live in a place with seasons, including that into consideration for the algorithm is important since the reference for the month could have been made because it was still cold, or still dark, or already hot, etc. So for instance, if the person mentions around march, and we consider that march is already not too cold, not snowing, etc, I'll have my algorithm checking march plus a few days before and at least a week after, but even if the results are off, in the second expansion of the period, I wouldn't go too far back, I'll increase more the period forward.

Also, it's very important to consider the use of slang, for instance I know people that use the day before yesterday (just one word in spanish), and by that they mean from 3 or 4 days ago to up to 6 months. So if there is something like that where you are building the algorithm, you should be very careful.

• +1 for a perfectly sensible answer, but not quite what I'm looking for. I've added a bit to the question to constrain the problem a bit more. Oct 20, 2012 at 17:14
• had never considered seasons, that's a good point, as is the slang issue. Oct 22, 2012 at 18:10

Thinking of the sort of dates which people might use an "around" feature with, you have too issues. Ambiguity, for example 12 March - no year has been specified, and precision March 2012 (it's only accurate to the month).

Ambiguity is dealt with by the context of the search. If it's someone planning then clearly it's next March, if it's recording something that's happened the it kinda has to be last March! The other case would be where you're talking about a specific year in a related part of the interface - in which case you might choose to interpret it as talking about the same year. The simplest way to think about this is can you work out which year is meant, and if so how do you know. The interface may be able to use a similar strategy (unless you're relying on external information).

As for precision it's more complex. People will often not remember dates precisely but they may remember the order in which events occurred in some cases. So rather than just offering "around" offering "before" and "after" can also be useful. This is going to be especially accurate if the thing you're searching for has some personal significance to the person searching. If they are likely to think things like "that was before I went on vacation, so that must have been early July" then the order of events could be a useful clue. If on the other hand the search they're performing is about an order for something that was made by their office, they they are much less likely to have any relevant personal memory to relate it to.

You could expect that "around 12 March 2012" could indicate that the date should be within a few days of the 12th. Contrast that to "around March 2012" where you'd are more likely to interpret that as being any time between from Feb to April. But this could also be affected by what other search terms you allow. For example, if the only modifier you allow is "around" then you might decide to interpret that as being a week either way. But if you also allowed people to say "early March" or "mid-March" then since those have a natural range of about two weeks you might decide that "around 12 March" is suggesting a tighter range - say only 2-3 days either side, because a specific date has been mentioned. If the user was only confident to the nearest week why didn't they just say "mid-March" instead.

Of course all that assumes your user is aware of how complex and natural language-like you're permitting.