Smalyshev added a comment. > Dates without years should not be allowed by the time datatype
That's fine but they are already there, so I'm not sure how we can say "should not be allowed" there. We have to do something when we encounter them. What is something? > The additional proposal to revert to the "dates are just strings" view for > deep values ignores the original design and documentation, and dismisses the > recommendations that Denny and I have been making via email. It does not dismiss anything. Given current state of the data (invalid dates, zero dates, etc.) I do not see how we can faithfully represent the data in the deep value as anything else. If you have better idea, please propose. If/when we get guarantee that the date in the source value is valid representable Gregorian date, we can type it as xsd:dateTime, but before that I don't see how we can do that. > suggest to freeze the RDF-time encoding discussions now until we have > established a joint understanding Establishing understanding is fine, but the code which produces RDF has to produce something when it encounters time value. We can not just have all the work wait until undefined time where we reach an understanding. So what should this code produce now? > As soon as we export dates to RDF, we are defining their meaning indirectly > via the RDF semantics, and this bug report is not the right place for doing > this. We can open another task if needed, though I don't see why this one is particularly unsuitable. In any case, I am not proposing anything that has to be enshrined as forever standard, and we are not releasing the dump as even internal standard, let alone something we promise never to change publicly. But we need to have something so that we could have it working and use it for query engine work. > We have to await their report and suggestions before deciding what to do in > RDF. I don't think halting all work on query engine until we reach full consensus on this point is realistic. I don't also think that data not including dates is really worth any use, even in beta status. So that means we have to export data somehow. Even if we know that we may change it before we get out of beta status. The question is what that representation would be. I proposed what I see as a good solution given the status of affairs //now//. If that's not good, fine, I'm completely open to hearing other proposals. 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 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
