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

Time expressions (proposal) #54

Open
omriabnd opened this issue Jan 11, 2019 · 9 comments
Open

Time expressions (proposal) #54

omriabnd opened this issue Jan 11, 2019 · 9 comments
Assignees
Labels

Comments

@omriabnd
Copy link
Member

Ideally I'd like to ideally make all definite time expressions unanalyzalbe. So dates, days of the week, time of the day etc. The reason is that they have their own unique syntax, which I don't want to model (it's not part of the foundational layer and frankly it's not that interesting).
The problem is with cases like: the 3rd and 5th of November, where the time expression syntax interacts with the other types of syntax. I think in these cases, we can still say it's unanalyzable, even though it isn't, just so we won't get into this thorny bush.
What do you think?

@nschneid
Copy link
Collaborator

It seems like a slippery slope to start using unanalyzable for a) instances of fully productive patterns, and b) fully compositional phrases that use normal syntax but happen to convey a date/time ("this Tuesday at 4 late in the afternoon"—is "afternoon" part of a time expression, or just a descriptor? should the date and time be considered 1 unit or two? etc.).

Maybe the principle of the foundational layer is that it covers the abstract semantics of what IS expressed as predicate-argument or modifier-center relations, and expressions where we cannot designate a semantic head should have multiple centers:

arrive_P [on_R November_C 5_C , 2019_C]_T
arrive on the 5th of November in 2019 — normal elaborator/relator structures
[St. Louis UNA]_C , MO_C , USA_C
10_C [Main Street UNA]_C [Apt_C 207_E]_C

There's a question of what sorts of grouping to use: I put "Apt 207" as C-E because it's the 207th apartment/the apartment numbered 207, so "apartment" is arguably the semantic head. But when different parts of a "locator" expression provide a location at different scales, as with date/month/year, street/house number/apartment number, and city/state/country, it's harder to say that any of these components is the head of the others.

@omriabnd
Copy link
Member Author

Good point. I agree with your analysis.

Dotan, what do you think?

@dotdv
Copy link
Collaborator

dotdv commented Jan 15, 2019

Yes, OK.

@dotdv
Copy link
Collaborator

dotdv commented Jan 15, 2019

arrive_P [on_R November_C 5_C , 2019_C]_T
arrive on the 5th of November in 2019 — normal elaborator/relator structures

If we mark "November 5, 2019" with multiple Cs then we should mark the second expression similarly, no?: the 5th_C [of November]_C [in 2019]_C

@nschneid
Copy link
Collaborator

If we mark "November 5, 2019" with multiple Cs then we should mark the second expression similarly, no?: the 5th_C [of November]_C [in 2019]_C

The second one has clear syntactic structure, whereas the first one lacks a clear head. My understanding is that the foundational layer targets the meaning relations associated with compositional syntax. Ideally there would also be another layer with temporal annotation to indicate that these are paraphrases.

@omriabnd
Copy link
Member Author

I think this makes sense.

@omriabnd
Copy link
Member Author

omriabnd commented Jan 18, 2019 via email

@dotdv
Copy link
Collaborator

dotdv commented Jan 20, 2019

Yes, sure.
So do you think it should be:
He arrived [[on_R the_F 5th_C [of November]_E]_C [in 2019]_C]_T
or maybe:
on_R the_F 5th_C [of_R November_C [in 2019]_E]_E (maybe in this way the relations between the day month and year are better reflected)

@nschneid
Copy link
Collaborator

The first way. (IMO "of November" and "in 2019" both attach to "the 5th". If the month is known from context, you could say "on the 5th in 2019".)

However, if it were "the 5th of November of 2019", then "of 2019" would elaborate November.

@nschneid nschneid added the v2.1 label Dec 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants