Make dates available for SPARQL

[mzeinstra]

I don't see this as an open ticket yet.

We discussed that the MVP would be to expose the lowest date of an EDTF value to SPARQL in Wikibase. Given possibilities this could be the highest and lowest values.

This is to make the current operators on dates available in SPARQL.

[JeroenDeDauw]

2021-02-12 status: high priority

[JeroenDeDauw]

@mzeinstra what to do for seasons? Start month? End month? Middle month? Both start and end month?

[mzeinstra]

Just out of the top of my head. Wouldn’t last day and first day of the season not work?

…

On Sun, 14 Mar 2021 at 01:19, Jeroen De Dauw ***@***.***> wrote: @mzeinstra <https://github.com/mzeinstra> what to do for seasons? Start month? End month? Middle month? Both start and end month? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABK54J7DWKLBOVD47XHHOJTTDP6J7ANCNFSM4XO5KB2Q> .

[JeroenDeDauw]

Implementation wise we can make it all happen. Usecase wise the first and last day for seasons works for some cases but not for others. Some examples where it does not work:

• Showing a timeline of when people where born (in case of a season they would show twice)
• Finding all conferences that happened more than once in 2020 (Spring 2020 shows up twice)

I also suspect that using start and end month is better than using the days. The dates also come with precision, and month precision is closer to season than day precision.

If we go with multiple values (ie start and end month), then perhaps it might even make sense to include all months part of the season?

[JeroenDeDauw]

Another example of a use case that gets messed up, this time applicable to intervals, when using start and end time:

Imagine having interval 1900-1999 (20th century). If you do a query finding times between 1890 and 1910, you will find the item via the starting time. But if you query for all times between 1910 and 1930, you will not find the item at all. It is not clear to me how to solve that, and it might not be possible without adding features to Blazegraph. And I can imagine, that for the people running the queries, it might be best if intervals (and possibly seasons and sets) are skipped. It is possible we make queries less usable for them by including these. Hard to tell.

[mzeinstra]

I agree on adding the months in a season, that seems to be the best way forward.

For intervals we could add all years in a sequence, but that might not be the best solution in this. Your proposal is to not expose intervals at all?

I assume we will also expose the 'raw' EDTF string as well?

[JeroenDeDauw]

Your proposal is to not expose intervals at all?

Yes. That could be added without all the guessing once a concrete usecase materializes, which might well be never.

I assume we will also expose the 'raw' EDTF string as well?

At the moment not. The EDTF is being translated into standard Wikibase time values, so we get maximum compatibility with tools. I am not sure what the implications of also exposing it in RDF as a string are, and am worried that having some values for P123 be a date and some be a string is a big no-no. So this would need some investigation, which will either take a lot longer than the technical work itself, or uncover the need for a bunch of extra technical work.

[mzeinstra]

I agree, that is a good start within the limited time.

I am afraid that not exposing the EDTS-as-string might also close the route of exporting EDTF data from the platform. Would that be true, or would it only be for the Sparql?

[JeroenDeDauw]

I was just talking about SPARQL and RDF. The standard MediaWiki and Wikibase export mechanisms contain the string version. Example of entity JSON with some EDTF strings in it via the web API: http://edtf.wikibase.wiki/w/api.php?action=wbgetentities&ids=P1

So not having the string in SPARQL or RDF does not create an export issue. Indeed, the RDF does not contain the entirety of the native Wikibase time values.

[mzeinstra]

Ah ok, than that use case doesn't exists anymore thanks.

[JeroenDeDauw]

Implementation should be done. Now we will test if the SPARQL queries actually work.

Example time-based query on Wikidata: https://query.wikidata.org/#SELECT%20%3Fitem%20%3FitemLabel%20%3Fdate_of_birth%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ146.%0A%20%20%20%20%20%20%20%20%3Fitem%20wdt%3AP569%20%3Fdate_of_birth.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20FILTER%28%28%3Fdate_of_birth%20%3E%20%222015-01-01%22%5E%5Exsd%3AdateTime%29%20%26%26%20%28%3Fdate_of_birth%20%3C%20%222021-06-01%22%5E%5Exsd%3AdateTime%29%29%0A%7D%0AORDER%20BY%20DESC%28%3Fdate_of_birth%29

SELECT ?item ?itemLabel ?date_of_birth WHERE {
  ?item wdt:P31 wd:Q146.
        ?item wdt:P569 ?date_of_birth.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  FILTER((?date_of_birth > "2015-01-01"^^xsd:dateTime) && (?date_of_birth < "2021-06-01"^^xsd:dateTime))
}
ORDER BY DESC(?date_of_birth)

[JeroenDeDauw]

Working as expected \o/