You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The classes TimEx, TimeStep, and GeoPhraseID pre-date the conversion of times and locations to true Eidos Mention objects, and so appear to be almost entirely redundant with what is stored on the "Time" and "Location" TextBoundMentions.
I wonder if we can get rid of them or at least dramatically simplify them. The only thing that a "Time" mention needs beyond the usual TextBoundMention stuff is an org.clulab.timenorm.scate.TimeExpression object. The only thing that a "Location" mention needs beyond the usual TextBoundMention stuff is a GeoNames ID which we currently store as an integer (not sure why an integer instead of a String, but that's an issue for another day). In short, I think it should be possible to simplify the attachment classes for these two mention types to something like:
class Time(val time: org.clulab.timenorm.scate.TimeExpression)
class Location(val geoNamesID: Int)
I looked at this a bit, but I don't understand the JSON-LD serialization stuff well enough to understand what it needs where. I'm guessing that in deserialization we would want to create new TextBoundMention objects for Times and Locations instead of just creating Attachments.
Beyond the simplification of code, this would also expose more types of time expressions (e.g., frequencies like "daily") that Eidos is currently discarding because it can't force them into the weird TimEx/TimeStep API.
The text was updated successfully, but these errors were encountered:
The classes TimEx, TimeStep, and GeoPhraseID pre-date the conversion of times and locations to true Eidos Mention objects, and so appear to be almost entirely redundant with what is stored on the "Time" and "Location" TextBoundMentions.
I wonder if we can get rid of them or at least dramatically simplify them. The only thing that a "Time" mention needs beyond the usual TextBoundMention stuff is an
org.clulab.timenorm.scate.TimeExpression
object. The only thing that a "Location" mention needs beyond the usual TextBoundMention stuff is a GeoNames ID which we currently store as an integer (not sure why an integer instead of a String, but that's an issue for another day). In short, I think it should be possible to simplify the attachment classes for these two mention types to something like:I looked at this a bit, but I don't understand the JSON-LD serialization stuff well enough to understand what it needs where. I'm guessing that in deserialization we would want to create new TextBoundMention objects for Times and Locations instead of just creating Attachments.
Beyond the simplification of code, this would also expose more types of time expressions (e.g., frequencies like "daily") that Eidos is currently discarding because it can't force them into the weird TimEx/TimeStep API.
The text was updated successfully, but these errors were encountered: