Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Duckling – Open-source datetime expression parsing

duckling-lib.org

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Show HN: Duckling – Open-source datetime expression parsing

#31

Post by aleem »

One suggestion from a use-case standpoint.

On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable.

Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better.

EDIT:

Another issue I ran into is that it correctly parses:

"tomorrow evening at 6"

but fails with:

"see you tomorrow evening at 6"

It would be nice to pass it the entire sentence since that's how most people will intend to use it.

Re: Show HN: Duckling – Open-source datetime expression parsing

#32

Post by samdb »

infogulch wrote: post #29
radnor wrote: post #22

Earlier quoted context omitted.

20 to 3 in the afternoon = 2:40 PM

Oooh, "twenty minutes until three". I typically use until or shorten it to 'till . But I've seen/heard to as well.

'To' is the most common version in British English.

Re: Show HN: Duckling – Open-source datetime expression parsing

#33

Post by munificent »

AbsoluteDestiny wrote: post #28
teh_klev wrote: post #26

Unfortunately it doesn't parse a Scottish colloquial expression such as "the next again day at 4pm". Which means in two days time at 4pm :)

Likewise it doesn't know what a fortnight is.

Hell, I don't know what a fortnight is either!

Re: Show HN: Duckling – Open-source datetime expression parsing

#34

Post by blandinw »

krammer wrote: post #30

Wow, we've tried to solve this problem inhouse and our results are much worse than this. One question, how hard is to detect that kind of expresions inside a random text? Like gmail does for suggesting a calendar appoinment within an email.

Even though the demo website expects the whole input to be a time expression, Duckling actually detects substrings inside a larger block of text.

We've mostly used it on short sentences, but it should work on larger inputs, like articles. I'd recommend splitting very large inputs into sentences though.

Re: Show HN: Duckling – Open-source datetime expression parsing

#36

Post by blandinw »

aleem wrote: post #31

One suggestion from a use-case standpoint. On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable. Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better. EDIT: Another…

cf. my answer to another comment. Even though the demo website expects the whole input to be a time expression, Duckling -- used as a library -- actually detects substrings inside a larger block of text.

EDIT regarding 6pm vs 6am, applications will have control over the assumptions made by the system. See https://news.ycombinator.com/item?id=8397113

Re: Show HN: Duckling – Open-source datetime expression parsing

#37

Post by infogulch »

aleem wrote: post #31

One suggestion from a use-case standpoint. On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable. Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better. EDIT: Another…

I think the best way to handle ambiguities like this is to present the user with an unambiguous result that highlights the choice that it made, but then to also provide a list of possible ambiguities to the application itself so it knows what the most likely corrections would be.

From the Limitations section:

> ... we only display the closest upcoming time, if any, or the closest past time otherwise. It can result in surprising outcomes, like “one year after Christmas” will be actually analyzed as “one year after last Christmas”

So this could be the interaction:

> User: "one year after Christmas"

> Computer: "OK, one year after last Christmas" // putting emphasis on what could be ambiguous

> User: "no, after next Christmas" // the application expected that next vs last could be ambiguous, so this is understood correctly

Re: Show HN: Duckling – Open-source datetime expression parsing

#38

Post by trab »

I have been frantically researching for a temporal tagging library that can be used on an Android application with no good results.

I have looked at SUTime, HeidelTime, natty and some others. I am trying to parse (among others) expressions of the type "the first week of the previous month", "The last week of September". The only library that can parse this type of query is SUTime.

Can you comment on why you implemented a home grown solution instead of using SUTime or some other library readily available. Have you measured the performance of Duckling vs the state of the art in temporal tagging ?

Duckling seems very well made with good docs but unfortunately for me will be hard to make work on Android.

Re: Show HN: Duckling – Open-source datetime expression parsing

#39

Post by ar7hur »

infogulch wrote: post #37
aleem wrote: post #31

One suggestion from a use-case standpoint. On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable. Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better. EDIT: Another…

I think the best way to handle ambiguities like this is to present the user with an unambiguous result that highlights the choice that it made, but then to also provide a list of possible ambiguities to the application itself so it knows what the most likely corrections would be. From the Limitations section: > ... we only display the closest upcoming time, if any, or the closest past time otherwise. It can result in…

Absolutely. We are working on something called "assumptions" where Duckling informs you about what assumptions it made to produce the result (like: time was ambiguous, I chose PM), and then you can change these and get a new result. Coming soon.

Re: Show HN: Duckling – Open-source datetime expression parsing

#40

Post by blandinw »

infogulch wrote: post #37
aleem wrote: post #31

One suggestion from a use-case standpoint. On iOS, "tomorrow at 6" is parsed as 6PM instead of 6AM. This makes sense because usually people really mean 6PM. This is context dependent--in chat logs etc this is desirable. Semantically speaking, the Duckling library does the right thing by parsing it at 6AM, but if the goal is ultimately to parse human expressions, then the iOS approach is probably better. EDIT: Another…

I think the best way to handle ambiguities like this is to present the user with an unambiguous result that highlights the choice that it made, but then to also provide a list of possible ambiguities to the application itself so it knows what the most likely corrections would be. From the Limitations section: > ... we only display the closest upcoming time, if any, or the closest past time otherwise. It can result in…

You're spot on. The next version of Duckling will return the list of assumptions made, as well as a list of alternate results. Applications will also be able to give assumptions as input (past vs. future, etc.).
Post reply on HN