Smalyshev added a comment. > The user interface, in defiance of the data model, would store a date entered > as 1 BCE as -1. But an entry made with the API would not necessarily have > done so
It'd be a problem if API client doesn't follow what people entering data into Wikidata follow. But since in both PHP and Java 1 BCE is -1, this is a natural way for internal representation, so since I have to assume one of these options, I assume this one. > I don't think people would want to take the approach that "15 November 1582 > Gregorian" and "November 1582 Gregorian" are entirely different kinds of > things that cannot be compared, That's effectively what it is. We could make some effort to make it a bit easier (like saying "wink-wink, November 1582 is actually 1 November when comparing to dates") but then you can't demand both rigor and convenience. If you compare the two, I don't see how you can define the comparison (in terms of more/less/equal) that would be unique and make sense. > If I make a query asking for everyone born between March and December 1582 > Gregorian, should the query ignore a guy born on 15 November 1582 Gregorian It won't, unless you specifically write query that way. Dates and precisions are stored separately, and most people would query against dates directly (it also would be much faster, probably). Which means, people expect ISO date representation of each date that makes sense for such queries. However, if you try to compare "November 1582 Gregorian" and "November 1582 Julian", you can't really expect any defined result. Of course, the actual store will return //some// result - right now with this patch it would say they are equal, even though they are not actually same stretches of time. > Handling queries on dates that include precision expressions requires some > careful thought and a lot of arithmetic. Unfortunately, implementing this in a real indexed database would be quite a challenge. Currently I'm pretty sure Blazegraph doesn't support anything like that OOTB and it's not likely any other triple store would support such thing OOTB. It can be done, but that's not a concern for this ticket - the concern for this ticket is to figure out the way to export the data into RDF that would make sense at least for the majority of the prospective use cases. TASK DETAIL https://phabricator.wikimedia.org/T99795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: gerritbot, Liuxinyu970226, Jc3s5h, Smalyshev, Aklapper, daniel, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, JanZerebecki, Malyacko, P.Copp _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
