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

documentation on is_approximate and is_uncertain #31

Closed
rettinghaus opened this issue Sep 13, 2018 · 6 comments
Closed

documentation on is_approximate and is_uncertain #31

rettinghaus opened this issue Sep 13, 2018 · 6 comments

Comments

@rettinghaus
Copy link
Contributor

for a date of classes UncertainOrApproximate and PartialUncertainOrApproximate return 'false' on
is_approximate and is_uncertain.
I guess that this is a bug, but couldn't find documentation on that.

@azaroth42
Copy link

Just ran into this as well.

@ColeDCrawford ColeDCrawford mentioned this issue May 28, 2024
5 tasks
@ColeDCrawford
Copy link
Contributor

@aweakley there is an easy fix for UncertainOrApproximate and Unspecified, but want to check on the intended behavior. Right now we have three different properties - is_uncertain, is_approximate, and is_approximate_and_uncertain. is_uncertain and is_approximate are False if is_approximate_and_uncertain is True - we're treating these as mutually exclusive. Does that make sense?

After setting the properties in UncertainOrApproximate and Unspecified based on ua:

>>> from edtf import parse_edtf, text_to_edtf
>>> e = parse_edtf("1666%")
>>> e.is_uncertain
False
>>> e.is_approximate
False
>>> e.is_uncertain_and_approximate
True
>>> f = parse_edtf("1666~")
>>> f.is_approximate
True

For PartialUncertainOrApproximate, we have uncertainty/approximation at sublevels, but not currently at top level properties:

>>> parse_edtf("2004-06~-11")
PartialUncertainOrApproximate: '2004-06~-11'
>>> e = parse_edtf("2004-06~-11")
>>> e.is_approximate
False
>>> e.year_month_ua
UA: '~'
>>> e.year_ua
False

I think it makes sense to have is_approximate, is_uncertain, and is_uncertain_and_approximate available here too. The question is whether those resolve to True if any part of the date is approximate / uncertain? I think they must, because otherwise fully qualified (qualification on the far right) would just parse as L1 UncertainOrApproximate.

@ColeDCrawford
Copy link
Contributor

Any thoughts on this one @aweakley ?

@aweakley
Copy link
Member

aweakley commented Jun 3, 2024

Sorry. Yes I agree, I think if any part of the date is approximate or uncertain then the appropriate one should resolve to True.

we're treating these as mutually exclusive. Does that make sense?

I think it does, because each alternative has different implications for our output.

@ColeDCrawford
Copy link
Contributor

ColeDCrawford commented Jun 5, 2024

Great. Should Intervals also have these properties? Right now they do (since they inherit from EDTFObject) but they are not useful as they don't return actual results (just False):

>>> from edtf import parse_edtf
>>> e = parse_edtf("2004-06-~01/2004-06-~20")
>>> e
Level2Interval: '2004-06-~01/2004-06-~20'
>>> e.is_approximate
False
>>> e.is_uncertain
False
>>> e.is_uncertain_and_approximate
False
>>> f = parse_edtf("1984~/2004-06")
>>> f
Level1Interval: '1984~/2004-06'
>>> f.is_approximate
False
>>> f.is_uncertain_and_approximate
False
>>> f.is_uncertain
False

I think we should probably set those properties based on whether either of the interval sections has .is_approximate, etc?

@aweakley
Copy link
Member

This is resolved in #56

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

4 participants