Manybubbles added a comment. In https://phabricator.wikimedia.org/T88717#1037925, @Beebs.systap wrote:
> From Bryan Thompson. > > The native xsd:dateTime support is based on an int64 value. It does support > negative int64 values, which is what a date before the epoch is translated > into. When using the xsd:dateTime inlining, what happens is that dates are > not entered into the dictionary. They appear as inline values within the > statement indices instead. This avoids a dictionary lookup for date > materialization. It also lets us use the OSP index for key-range scans on > xsd:dateTIme values. > > If you need to go beyond an int64 value, then the graph database can also > inline xsd:integer values (BigInteger). This would allow general cosmology > dates. > > One limitation of this approach (which is completely optional and which can > be disabled using AbstractTripleStore.Options.INLINE_DATE_TIMES) is that the > dateTime is converted to a point value - the timezone information needs to be > normalized. This would also be true of any custom inlining scheme developed > for xsd:integer rather than xsd:long. The general problem is that > xsd:dateTime specifies two dimensions (a point in time and a timezone) and > allows the timezone to be optional. Oops. There is no way to translate that > into a single point, which is what you need to be able to compare values in > an index, do key-range scans, etc. > > You have some options. You can disable dateTime inlining. This will > preserve all information. You can store both the non-inline version (with > timezone information) and the inline version (by using different predicates). > This would preserve the opportunity for key range scans on date while also > preserving timezone information. And if necessary you could use an > alternative inlining scheme for dates in the extreme past or future. > > Bryan Thanks! I imagine we'll think of somethiing. Our data types actually have a bunch of data: https://www.wikidata.org/wiki/Special:ListDatatypes Our dateTimes actually have precision and, optionally, error bounds. Quantities are pretty similar. It might make sense for us to develop something to allow those to be inlined. Right now the Wikidata Toolkit dumps them as several triples (one for value, one for precision, one for positive error and one for negative error). Any chance of a link to how to use geo stuff? http://www.blazegraph.com/whitepapers/bigdata_geospatial.pdf is nice but I'd be more interested in something that goes into the kind of depth your wiki goes into on other subjects. If you don't have an article (I couldn't find one by searching) then I'm happy to read code if you want to point me to a file. Also, I can't edit the wiki. I found a spelling mistake and was trying to help! TASK DETAIL https://phabricator.wikimedia.org/T88717 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, Manybubbles Cc: Jdouglas, Beebs.systap, Aklapper, Manybubbles, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, daniel, JanZerebecki _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
