Closed GoogleCodeExporter closed 9 years ago
I saw in resources file, that's because for TempEval-3 you shouldn't put X at
ends but for TIMEX3 you have to?
In this case, an option in the configuration file to choose TIMEX3 or TempEval
format would be nice.
Original comment by damien.p...@gmail.com
on 4 Feb 2014 at 4:25
Hi Damien,
Thanks for your mail. We actually made these changes because we want the
annotations to be more close to the TimeML TIMEX3 annotation standard. The
values are defined in the following way:
- decade expressions: three-digit numbers (e.g., "197" for "1970s")
- century expressions: two-digit numbers
- millennium expressions: one-digit numbers
- values for expressions referring to years such as "200 (AD)" and "20 (AD)",
are to be annotated as "0200" and "0020", respectively
- values for expressions referring to years such as "200 BC" and "20 BC", are
to be annotated as "BC0200" and "BC0020", respectively.
Currently, we are working on a new version supporting the extraction and
normalization of historic temporal expressions (e.g., BC date expressions). For
this, it is quite important that we now stick to the annotation standard more
closely.
Now, after the explanation of the semantics of the values: Do you think you can
use the value normalization as it is now?
Please keep us in the loop.
Thank you and best regards,
Jannik
Original comment by jannik.s...@gmail.com
on 4 Feb 2014 at 4:38
Hi Jannik,
thanks for your quick answer.
I see. So a year can only be written on 4 digits, so no confusion possible if
the decade is on 3 digits.
Yes thanks for your detailed explanation, I changed my application to follow
these rules and it works well.
I think you can add this to the manual it's quite useful!
Best regards
Damien
Original comment by damien.p...@gmail.com
on 4 Feb 2014 at 4:59
Original comment by jannik.s...@gmail.com
on 4 Apr 2014 at 12:26
Original issue reported on code.google.com by
damien.p...@gmail.com
on 4 Feb 2014 at 4:19