Open a new thread for discussion of calendar models in general.
On Wed, Jul 1, 2015 at 4:49 PM, Markus Krötzsch
<markus(a)semantic-mediawiki.org> wrote:
On 01.07.2015 16:00, Pierpaolo Bernardi wrote:
On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch
<markus(a)semantic-mediawiki.org> 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
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata