mkroetzsch added a subscriber: Lydia_Pintscher. mkroetzsch added a comment.
Yes, the discussion on SPARQL has converged surprisingly quickly to the view that XSD 1.1 is both normative and intended in SPARQL 1.1 (by the way, I can only recommend this list if you have SPARQL questions, or the analogous list for RDF -- people are usually very quick and helpful in answering queries, esp. if you say why you need it ;-). Your findings about Virtuoso and BlazeGraph show that it might be hard to find a conforming processor right now. However, I would still hope that it can be done, since the transformation of the values is quite easy after all. In fact, I think that neither of these projects is very likely to have customers who have cared about BCE years so far ;-). Technically, it should be not too hard: even if you use an XSD 1.0 library in most places, you could surely find an XSD 1.1 library to use with date functions, or you could transform dates internally before passing them to the XSD 1.0 operator functions. If such transformation is not efficient enough, one could also convert all input to XSD 1.0 dates on loading (or before) and then merely translate dates in queries and results accordingly (should not be a big performance issue since these datasets are rather small). However, I think it should be easy to take the few affected XPath functions from another library or to implement them directly. Julian day calculation is a very simple algorithm (https://en.wikipedia.org/wiki/Julian_day#Calculation), and this is all you need for date comparisons, calendar conversion, and time intervals. One way or the other, implementations will most likely have to do some custom extensions of internal date handling, unless the standard XSD libraries can cope with the age of the universe. Data publication is another issue. It's clear that we need to use XSD 1.1 when we publish RDF online, since this is what the current RDF specification requires. Applications that find our data on the web cannot know what we discussed and there is no way of telling them. They can only assume that we are using the current standard. For JSON and Wikidata internally, the main reference is probably ISO 8601 not XSD (I don't actually know what JSON says here, but usually it says nothing about things other than primitive Javascript types). I'd find it hard to explain why we would choose to deviate from that. Year 0000 has been legal in ISO for many years before Wikidata was even started. @Lydia_Pintscher recently triggered an action to review the dates stored internally in Wikidata, so this issue should probably be part of it (esp. since all BCE dates that are exact to the year should use Julian calendar). As you said, we already have year 0000 in values, and it is likely that we have other negative year numbers entered by the same bots (assuming ISO semantics). So we need to change many dates one or the other way in any case. I think most technical consumers will appreciate if we stick to ISO since it is easier to do calculations with. Moreover, now that every standard has agreed to use the same format, time is working for those who go with it. TASK DETAIL https://phabricator.wikimedia.org/T94064 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Lydia_Pintscher, Denny, Manybubbles, daniel, mkroetzsch, Smalyshev, JanZerebecki, Aklapper, jkroll, Wikidata-bugs, Jdouglas, aude, GWicke _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
