Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove TimEx, TimeStep, GeoPhraseID #651

Open
bethard opened this issue Aug 22, 2019 · 1 comment
Open

Remove TimEx, TimeStep, GeoPhraseID #651

bethard opened this issue Aug 22, 2019 · 1 comment

Comments

@bethard
Copy link
Contributor

bethard commented Aug 22, 2019

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.

@kwalcock
Copy link
Member

FWIW I agree and will try to sort out the JSON-LD stuff soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants