[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-03-13 Thread Jheald
Jheald added a comment. Hi Smalyshev, thanks for the comment; but if I can come back on your two objections: (i) If the only thing to cast to the bespoke type was a SERVICE (or indeed a function), then there would be no items of the bespoke type in the triplestore, so it would have no implications

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-03-13 Thread Smalyshev
Smalyshev added a comment. I am wary of (ab)using geospatial types as freeform containers for something that is not geospatial data. Geospatial data is indexed in a special way, and I'm not sure putting other data there is a good thing. Also, it will require custom RDF types which other tools will

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Smalyshev
Smalyshev added a comment. OTOH, wdv: node content may be looked up via LDF, which is much cheaper than SPARQL... Still not sure about performance impact though, it still would require a HTTP roundtrip.TASK DETAILhttps://phabricator.wikimedia.org/T159160EMAIL PREFERENCEShttps://phabricator.wikimedi

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Smalyshev
Smalyshev added a comment. why it's not possible (in theory at least) for the GUI to spot the wdv prefix, then look up the 8f6e57348b9035361151ee05475253ef in a lookup-table There's no lookup table. The GUI could make a SPARQL query each time it encounters a wdv: node, but I think that'd be a bit

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Jheald
Jheald added a comment. So something like p:P569/psv:P569 returns a URI, something like wdv:8f6e57348b9035361151ee05475253ef I'm still not sure why it's not possible (in theory at least) for the GUI to spot the wdv prefix, then look up the 8f6e57348b9035361151ee05475253ef in a lookup-table, to tra

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Smalyshev
Smalyshev added a comment. RDF is not really good with compound types... Maybe there's some trick, but usually value is just (string,URI) tuple, with URI being the type. For dates, there are standard URIs for some precisions, but we don't have тоо much flexibility there. I need to think more about

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Jheald
Jheald added a comment. So is there no way to create any kind of compound type that the GUI can interpret appropriately? -eg date + precision, here -or url + linktext, on other ticketsTASK DETAILhttps://phabricator.wikimedia.org/T159160EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Smalyshev
Smalyshev added a comment. So if instead one wrote a query to return a wikibase:Time, wikibase:Time is a type on a node. A node by itself does not have any value, it's just an URI. So the GUI can't use it. You can write a query that returns date values associated with that node, but I'm not sure i

[Wikidata-bugs] [Maniphest] [Commented On] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Jheald
Jheald added a comment. So if instead one wrote a query to return a wikibase:Time, -eg by using p:P569/psv:P569 instead of wdt:P569 could it be possible for the GUI to pick that up and return an appropriately precisioned time?TASK DETAILhttps://phabricator.wikimedia.org/T159160EMAIL PREFERENCEShttp