Open a new thread for discussion of calendar models in general. On Wed, Jul 1, 2015 at 4:49 PM, Markus Krötzsch <[email protected]> wrote: > On 01.07.2015 16:00, Pierpaolo Bernardi wrote: >> >> On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch >> <[email protected]> wrote: >>> >>> Dear Pierpaolo, >>> >>> This thread was only about Julian and Gregorian calendar dates. If and >>> how >>> other calendar models should be supported in some future is another >>> (potentially big) discussion. As you said, there are many issues there. >>> Let's first make sure that we handle the "easy" 99.9% of cases correctly >>> before discussing any more complicated options. >> >> >> Lydia Pintscher in the starting email explained that there's a model >> for calendars, and unfortunately this model could be (and has been) >> interpreted in two ways (AFAIU). >> >> My intention was to point out that one of the two interpretations is >> not sound. This leaves the other one as the only viable one. > > > To clarify: the problem that Lydia discussed has occurred on another (more > technical) level. It is not about the question whether there are further > calendar models that are incompatible to Julian and Gregorian, but about the > two calendar models that are captured by what Wikidata calls the "date" > type. This type does not support dates that cannot be converted into one > another. This is the usual trade-off you have when building a data-based > system: you have to restrict the possible formats to ensure that the > resulting data is still usable. For example, we could capture many more > complex things and nuances of reality in free text, but then we would not > have Wikidata but Wikipedia ;-) > > What is colloquially called a calendar date can be anywhere between clearly > defined time point to a rough suggestion of a relative time frame. Wikidata > already makes a lot of commitments towards a less strict notion of "date", > many of which are not fully supported and correctly used now (timezones, > "before" and "after" -- even the meaning of "precision" is all but clear). > Many of these features have been implemented as a response to user queries > for making date entry even more general, to cover even more corner cases. > For data consumers, this makes the data much harder to use. It creates a > cost for everyone. So far, there is only the cost, and not the benefit (or > is anybody using "before" and "after"? Yet I have to deal with it when > reading data!). Let's first make use of what we have (this includes proper > UI support for timezone annotation and precision windows), before discussing > even more complex notions of calendar and time. > > But don't worry: there will surely be more calendar models that can be > supported properly, in a specified and clear way. However, it is definitely > not planned that all possible calendar models will at some time be > implemented. A basic design goal of the "date" type in Wikidata is that > dates remain compatible on the day level. Calendars that are too far away > from this should use own properties (maybe of type string, maybe of another > special date type). One can then give approximate Gregorian/Julian dates in > addition by using the standard date properties of Wikidata (these > approximate dates would then not capture the exact moment, but the best > possible approximation). In this way, one can get the best of both worlds: > exact date information in native calendar models and maximal compatibility > with major time-based applications (such as Histropedia) and query services > (all time-related query functions in SPARQL databases are based on Gregorian > dates). > > Regards, > > Markus > > >> >> Cheers >> P. >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
