daniel added a comment. @mkroetzsch I think I see your point about "another breaking change" now: If a dataset used to contain objects using URIs based on http://acme.test/onto1, and that changes to http://acme.test/onto2, the same query against the dataset would return objects with completely different URIs, probably unrecognizable for the consuming system. If the URI would have stayed http://acme.test/onto1, the consumer would get URIs it understands, though the objects may look a little different.
My worry is about systems that interpret RDF URIs directly while ingesting the data. Let's say the triple store knows the XSD data types, and uses that knowledge for efficient indexing. How does such a system know how to interpret negative year numbers in xsd:date? There is *no* way for it to tell which interpretation is intended. And when ingesting xsd:date values from different sources that use different versions of xsd would lead to incorrect query results (xsd:date values that refer to the same date would not be equal, because they use a different convention for BCE years). I find that quite scary, and I still do not understand why that well-informed group of experts went that way, instead of introducing new data types that explicitly use the astronomical numbering. To me, silently producing wrong results in 1% of the cases may be quite a bit //worse// than breaking compatibility. It depends on the use case, I suppose. TASK DETAIL https://phabricator.wikimedia.org/T93207 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: daniel Cc: adrianheine, Manybubbles, Smalyshev, mkroetzsch, Denny, Lydia_Pintscher, Aklapper, daniel, Wikidata-bugs, aude, Krenair, Dzahn _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
