[Wikidata-bugs] [Maniphest] [Changed Subscribers] T89594: Use the arbitrary access to Wikidata feature on Commons (tracking)

2015-02-19 Thread Jheald
Jheald added a subscriber: Jheald. TASK DETAIL https://phabricator.wikimedia.org/T89594 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

[Wikidata-bugs] [Maniphest] [Commented On] T89599: Template:Institution to LUA and use Wikidata

2015-02-19 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. It's not in Lua, but some work towards pushing data from wikidata through the existing Institution template can be found at https://www.wikidata.org/wiki/Template:Institution/wrapper with some test-cases at https://www.wikidata.org/wiki

[Wikidata-bugs] [Maniphest] [Updated] T87686: Categories are metadata

2015-02-26 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. I've bent Lydia's ear a couple of times in the past on this, once in Amsterdam and once in Paris on the way back from the boat reception. Categories have developed for a reason. There's a real value in having groupings of content

[Wikidata-bugs] [Maniphest] [Updated] T116298: SPARQL endpoint should gracefully handle cycles and loops in transitive properties

2015-10-25 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. Transitive properties aren't necessary a-cyclic -- for example, consider https://phabricator.wikimedia.org/P460 "said to be the same as", which is transitive, currently used to link given names together, if they are

[Wikidata-bugs] [Maniphest] [Edited] T118793: item labels not updating cleanly on Wikidata Sparql service

2015-11-16 Thread Jheald
Jheald edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T118793 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, StudiesWorld, Jheald, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana

[Wikidata-bugs] [Maniphest] [Created] T118793: item labels not updating cleanly on Wikidata Sparql service

2015-11-16 Thread Jheald
Jheald created this task. Jheald added a subscriber: Jheald. Jheald added projects: Wikidata, Wikidata-Query-Service. Herald added subscribers: StudiesWorld, Aklapper. Herald added a project: Discovery. TASK DESCRIPTION It seems that when a label is changed, the value isn't always updated

[Wikidata-bugs] [Maniphest] [Edited] T118793: item labels not updating cleanly on Wikidata Sparql service

2015-11-16 Thread Jheald
Jheald edited the task description. Jheald set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T118793 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, StudiesWorld, Jheald, jkroll, Smalyshev, Wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T100235: Query optimizer pessimises queries

2015-10-02 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. Some more Blazegraph query optimizer issues presented at https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization and https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/suggestions#Query_optimizer_issues

[Wikidata-bugs] [Maniphest] [Commented On] T89853: Determine whether (and how) SPARQL queries can return tree structures

2015-10-02 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. Not quite clear what the original poster is asking for. It's pretty straightforward to output a list of child nodes and parent nodes, which is enough to define a tree. Here <http://demo.seco.tkk.fi/visu/#/?sparqlEndpoint=https:

[Wikidata-bugs] [Maniphest] [Commented On] T120196: Query text shifted to the right in WDQS query editor

2015-12-03 Thread Jheald
Jheald added a comment. Exactly: when one clicks a link to a specific query. TASK DETAIL https://phabricator.wikimedia.org/T120196 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jonas, Lydia_Pintscher, Aklapper, StudiesWorld, Jheald

[Wikidata-bugs] [Maniphest] [Created] T120196: Query text shifted to the right in WDQS query editor

2015-12-03 Thread Jheald
Jheald created this task. Jheald added a subscriber: Jheald. Jheald added a project: Wikidata-Query-Service. Herald added subscribers: StudiesWorld, Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION When a query is opened in the WDQS query editor, often the query text

[Wikidata-bugs] [Maniphest] [Created] T120198: More efficient SPARQL queries for sitelinks

2015-12-03 Thread Jheald
Jheald created this task. Jheald added a subscriber: Jheald. Jheald added a project: Wikidata-Query-Service. Herald added subscribers: StudiesWorld, Steinsplitter, Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION SPARQL queries involving sitelinks are very slow

[Wikidata-bugs] [Maniphest] [Edited] T120642: WDQS "IndexOutOfBoundsException"

2015-12-07 Thread Jheald
Jheald edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T120642 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, StudiesWorld, Jheald, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana

[Wikidata-bugs] [Maniphest] [Created] T120642: WDQS "IndexOutOfBoundsException"

2015-12-07 Thread Jheald
Jheald created this task. Jheald added a subscriber: Jheald. Jheald added a project: Wikidata-Query-Service. Herald added subscribers: StudiesWorld, Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION Just seen this error for the first time. Have we recently changed

[Wikidata-bugs] [Maniphest] [Edited] T120642: WDQS "IndexOutOfBoundsException"

2015-12-07 Thread Jheald
Jheald edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T120642 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, StudiesWorld, Jheald, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana

[Wikidata-bugs] [Maniphest] [Edited] T120642: WDQS "IndexOutOfBoundsException"

2015-12-07 Thread Jheald
Jheald edited the task description. Jheald set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T120642 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, StudiesWorld, Jheald, jkroll, Smalyshev, Wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T120642: WDQS "IndexOutOfBoundsException" in path query with MINUS

2015-12-07 Thread Jheald
Jheald changed the title from "WDQS "IndexOutOfBoundsException"" to "WDQS "IndexOutOfBoundsException" in path query with MINUS". TASK DETAIL https://phabricator.wikimedia.org/T120642 EMAIL PREFERENCES https://phabricator.wikimedia.org/setting

[Wikidata-bugs] [Maniphest] [Commented On] T118960: unescape escaped | from example queries

2015-12-04 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. I don't understand the problem. The query displays correctly on the page, and loads and executes correctly in the query editor. TASK DETAIL https://phabricator.wikimedia.org/T118960 EMAIL PREFERENCES https

[Wikidata-bugs] [Maniphest] [Commented On] T119332: Change entity prefix

2015-12-05 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. Multichill doesn't say exactly where the change needs to be made, but I presume he's talking about the "exploring linked data <https://github.com/wikimedia/wikidata-query-rdf/blob/master/docs/exploring-linked-data.md>"

[Wikidata-bugs] [Maniphest] [Commented On] T118960: unescape escaped | from example queries

2015-12-05 Thread Jheald
Jheald added a comment. Yes I know that. But if the text displays fine on the page (which it does), and transfers fine to the query editor (which it does), then what is the probem with having `{{!}}` in the source wikitext ? TASK DETAIL https://phabricator.wikimedia.org/T118960 EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T118960: unescape escaped | from example queries

2015-12-05 Thread Jheald
Jheald added a comment. Sorry, I understand now. The problem is specifically when the example query is loaded using the drop-down menu on the query-editor page, (rather than by following a link on the wiki page.) //That// is when the wikitext un-escaping is being missed. TASK DETAIL https

[Wikidata-bugs] [Maniphest] [Updated] T120166: Semantically define arity of statement -> reference relations

2015-12-03 Thread Jheald
Jheald added a comment. For example, here is a query <http://tinyurl.com/pql8ew7> to give break down the number of films by the number of values of cast member (https://phabricator.wikimedia.org/P161) that we have for them: PREFIX wikibase: <http://wikiba.se/ontology#> PREF

[Wikidata-bugs] [Maniphest] [Commented On] T120166: Semantically define arity of statement -> reference relations

2015-12-03 Thread Jheald
Jheald added a comment. ... and the number of films with //no// cast member listed (query <http://tinyurl.com/jjgotdd>): PREFIX wikibase: <http://wikiba.se/ontology#> PREFIX wd: <http://www.wikidata.org/entity/> PREFIX wdt: <http://www.wikidata.org/prop/direct/&

[Wikidata-bugs] [Maniphest] [Commented On] T120166: Semantically define arity of statement -> reference relations

2015-12-03 Thread Jheald
Jheald added a comment. I am not sure why we would want to list out all the statements. Surely we just want to count them ? The query below <http://tinyurl.com/pwqsmww> runs in 8.4 seconds PREFIX wikibase: <http://wikiba.se/ontology#> PREFIX wd: <http://www.wikidata.org/ent

[Wikidata-bugs] [Maniphest] [Updated] T120198: More efficient SPARQL queries for sitelinks

2015-12-03 Thread Jheald
Jheald added a comment. I think you underline exactly my point. The size of the two final solution sets is very similar. Per the query above, there are currently 345,221 category-items with a https://phabricator.wikimedia.org/P373; whereas according to Autolist (CLAIM[31:4167836] AND LINK

[Wikidata-bugs] [Maniphest] [Created] T120323: Outdated labels sometimes being shown for the objects of properties on Wikidata pages

2015-12-03 Thread Jheald
Jheald created this task. Jheald added a subscriber: Jheald. Jheald added a project: Wikidata. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION Example: [[ https://www.wikidata.org/wiki/Q15633582 | Q15633582 ]] ("MediaWiki site"): For property P408 ("

[Wikidata-bugs] [Maniphest] [Commented On] T103102: [Story] Take in other projects sidebar out of beta features

2015-12-21 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. It's good to see this going forwards at last. But what is the progress with two long-standing requests ? - Moving the standard "wikidata item" link into this group, to make it easier to find ? - Attempting by default to incl

[Wikidata-bugs] [Maniphest] [Updated] T118793: item labels not updating cleanly on Wikidata Sparql service

2015-11-19 Thread Jheald
Jheald added a comment. Also now sometimes seeing this for Commons category (https://phabricator.wikimedia.org/P373) eg this query <http://tinyurl.com/nznutty>, for Q7981506 <https://www.wikidata.org/wiki/Q7981506>: PREFIX wd: <http://www.wikidata.org/entity/>

[Wikidata-bugs] [Maniphest] [Commented On] T123565: [EPIC] Support geo-coordinate search for WDQS

2016-01-20 Thread Jheald
Jheald added a subscriber: Jheald. Jheald added a comment. So queries won't have to be written like this any more ? :-) https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries#Working_with_co-ordinates - and eg. counting may be possible within a bigger radius ? TASK DETAIL

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T125822: [Epic] Basic first prototype for structured data support for Commons

2016-02-16 Thread Jheald
Jheald added a subscriber: Jheald. TASK DETAIL https://phabricator.wikimedia.org/T125822 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, El_Grafo, Tobi_WMDE_SW, Ricordisamoa, JeanFred, Bene, Aklapper, Steinsplitter, Izno, Wikidata

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T125824: [Task] Create a new media info entity type

2016-02-16 Thread Jheald
Jheald added a subscriber: Jheald. TASK DETAIL https://phabricator.wikimedia.org/T125824 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Ricordisamoa, Bene, Lydia_Pintscher, Steinsplitter, Aklapper, Izno, Wikidata-bugs, aude

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T125826: [Task] Decide on structure of entity ID for media info entity type

2016-02-16 Thread Jheald
Jheald added a subscriber: Jheald. TASK DETAIL https://phabricator.wikimedia.org/T125826 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, daniel, thiemowmde, Ricordisamoa, Bene, Lydia_Pintscher, Steinsplitter, Aklapper, Izno

[Wikidata-bugs] [Maniphest] [Commented On] T94989: [Story] Other projects sidebar should have ability to include commons category links

2016-03-01 Thread Jheald
Jheald added a comment. A couple of wrinkles to examine, reported at Commons Village Pump: https://commons.wikimedia.org/wiki/Commons:Village_pump#WP_sidebars_now_link_to_Commons_categories 1. Commons categories can show spurious sidebar links to themselves. (Presumably this might

[Wikidata-bugs] [Maniphest] [Commented On] T158648: WDQS: Strange query behaviour with curly brackets

2017-02-21 Thread Jheald
Jheald added a comment. And this query can take 20 seconds or even crash: SELECT ?number WHERE { VALUES ?number { 1 2 3 4 } . { FILTER ( ?number IN (1 , 2 )) } }TASK DETAILhttps://phabricator.wikimedia.org/T158648EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel

[Wikidata-bugs] [Maniphest] [Created] T158648: WDQS: Strange query behaviour with curly brackets

2017-02-21 Thread Jheald
Jheald created this task.Jheald added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONThis query returns 1 : SELECT ?number WHERE { VALUES ?number { 1 } . FILTER ( ?number IN (1 , 2

[Wikidata-bugs] [Maniphest] [Commented On] T158648: WDQS: Strange query behaviour with curly brackets

2017-02-21 Thread Jheald
Jheald added a comment. Presumably what's happening here is that BlazeGraph thinks it can execute a bracketed block { ... } as a self-standing sub-query, independent of what has gone before. I don't know what the standard mandates for this. But it makes it quite hard if you want to write UNION

[Wikidata-bugs] [Maniphest] [Commented On] T158648: WDQS: Strange query behaviour with curly brackets

2017-02-22 Thread Jheald
Jheald added a comment. You're right. I see that now. https://www.w3.org/TR/sparql11-query/#scopeFilters Sorry for having misunderstood the spec.TASK DETAILhttps://phabricator.wikimedia.org/T158648EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JhealdCc

[Wikidata-bugs] [Maniphest] [Updated] T158955: Add a SPARQL layer around existing live SQL databases

2017-02-24 Thread Jheald
Jheald added a comment. See also T157676 "Provide access to category information from WDQS SPARQL"TASK DETAILhttps://phabricator.wikimedia.org/T158955EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JhealdCc: Lydia_Pintscher, Jheald, Pigsonthewing

[Wikidata-bugs] [Maniphest] [Updated] T158955: Add a SPARQL layer around existing live SQL databases

2017-02-24 Thread Jheald
Jheald added projects: Wikidata-Query-Service, Wikidata.Herald added a project: Discovery. TASK DETAILhttps://phabricator.wikimedia.org/T158955EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JhealdCc: Lydia_Pintscher, Jheald, Pigsonthewing, Aklapper, EBjune

[Wikidata-bugs] [Maniphest] [Updated] T158955: Add a SPARQL layer around existing live SQL databases

2017-02-24 Thread Jheald
Jheald added a comment. and T148245 "Explore making WDQS access mediawiki API"TASK DETAILhttps://phabricator.wikimedia.org/T158955EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JhealdCc: Lydia_Pintscher, Jheald, Pigsonthewing, Aklapper, EBjune, mer

[Wikidata-bugs] [Maniphest] [Commented On] T116298: SPARQL endpoint should gracefully handle cycles and loops in transitive properties

2017-02-11 Thread Jheald
Jheald added a comment. Bump. Some further interesting examples in this thread on Project Chat of searches of this form that work and others that don't. A search for all buildings in the county of Bedfordshire with Grade I heritage status works; but a search for all churches in the county

[Wikidata-bugs] [Maniphest] [Commented On] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-02-12 Thread Jheald
Jheald added a comment. For comparison, in September 2015 there were 376,524 references using P:854, and a query to search them could complete in 3.7 seconds -- it was used as an example on the query optimisation page. Such a query now times out. It should be possible for such a search

[Wikidata-bugs] [Maniphest] [Commented On] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-02-14 Thread Jheald
Jheald added a comment. Hi Smalyshev, thanks for taking the time to get back to me. The LDF suggestion is a good one -- I was thinking of looking in to it for investigating Commons sitelinks and P373s, both of which are now getting close to the borderline of what a query can cope with without

[Wikidata-bugs] [Maniphest] [Created] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-02-10 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONThe Wikidata property P854 (reference URL) is currently being used 2,305,909 times. Even just to produce this count takes WDQS

[Wikidata-bugs] [Maniphest] [Commented On] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-02-10 Thread Jheald
Jheald added a comment. For completeness, the P:854 can also be used as a qualifier, principally on property P1343 "described by source", though the number of uses is much much smaller. This usage can be searched, eg this query works: SELECT ?item ?itemLabel ?refURL WHERE { ?item ?

[Wikidata-bugs] [Maniphest] [Commented On] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-02-10 Thread Jheald
Jheald added a comment. Some queries: Count of the number of uses of the property -- takes over 10 seconds SELECT (COUNT(?ref) AS ?count) WHERE { ?ref pr:P854 ?refURL . } Attempt to extract some references to Le Figaro website -- fails -- though it does seem to try to be creating a JSON list

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-02-14 Thread Jheald
Jheald added a comment. The other (simplest) approach would just be to link to the Commons file page, https://commons.wikimedia.org/wiki/File:KingsCollegeChapelWest.jpg but personally I do quite like the MediaViewer (though some people don't) https://commons.wikimedia.org/wiki

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-02-14 Thread Jheald
Jheald added a comment. With regard to external identifiers and to the P:373 Commons category and property values, it strikes me that what we really need in the triplestore is a special datatype -- in a similar way to the way we have a special datatype for Commons media. It would seem that what

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-02-14 Thread Jheald
Jheald added a comment. The standard URLs for the MediaViewer appear to be the wiki page it was launched from, then #/media/ and then the name of the file to display, so https://en.wikipedia.org/wiki/Cambridge#/media/File:KingsCollegeChapelWest.jpg https://commons.wikimedia.org/wiki

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-02-14 Thread Jheald
Jheald added a comment. The gallery view is nice!! I don't know how I missed it - I thought I had tried it, and it just went to the same place as the file link. As for the file link, presumably it was chosen because something like is the IRI that used to represent the image in RDF exports

[Wikidata-bugs] [Maniphest] [Created] T157993: Making WDQS onscreen output more Commons friendly

2017-02-13 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata, Structured-Multimedia-Data.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONI recently created a Commons template, "Category contains", to store a SPARQL-based spe

[Wikidata-bugs] [Maniphest] [Created] T157676: Provide access to category information from WDQS SPARQL

2017-02-09 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONThe WDQS SPARQL service is fantastic; but it is a shame that it seems to be in such a separate silo from the category information

[Wikidata-bugs] [Maniphest] [Created] T157798: Provide access to image sizes from WDQS SPARQL

2017-02-10 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata, Structured-Multimedia-Data.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONA user has posted in Wikidata Project Chat that it would be useful to be able to access the sizes

[Wikidata-bugs] [Maniphest] [Commented On] T157798: Provide access to image sizes from WDQS SPARQL

2017-02-10 Thread Jheald
Jheald added a comment. (Got the diff wrong, but the next paragraph shows why Alexmar983 would find this useful).TASK DETAILhttps://phabricator.wikimedia.org/T157798EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JhealdCc: Aklapper, Jheald, EBjune, Acer

[Wikidata-bugs] [Maniphest] [Commented On] T157182: Duplicate language codes in labeling service cause unexpected result

2017-02-28 Thread Jheald
Jheald added a comment. +1 on this. I had hoped to internationalise a templated query, by adding {{int:lang}} to the list of language codes. However, the query appears to prioritise languages by when they appear last in the list, rather than when they appear first.TASK DETAILhttps

[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

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-02-27 Thread Jheald
Jheald added a comment. It would also be useful for the GUI to show Wikipedia sitelinks as links rather than full URLs. The shorter form is especially valuable when one is trying to include a lot of columns in a table report, without losing the grid structure (which happens if there are too many

[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

[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] [Updated] T159160: Take account of date precision when displaying dates in WDQS GUI

2017-02-27 Thread Jheald
Jheald added a comment. Re: my previous comment, nodes that can store both a string and a URL would appear to be necessary to enable T121274 "Provide an RDF mapping for external identifiers" -- even though there are no such value nodes at the moment.TASK DETAILhttps://phabricator.wik

[Wikidata-bugs] [Maniphest] [Created] T161342: Some data not uploaded to WDQS ?

2017-03-24 Thread Jheald
Jheald created this task.Jheald added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONI uploaded coordinates (P625) for Maldon (Q26272025) an hour and a half ago (diff). But when I use WDQS to ASK whether it has

[Wikidata-bugs] [Maniphest] [Commented On] T161342: Some data not uploaded to WDQS ?

2017-03-24 Thread Jheald
Jheald added a comment. Ouch. That sounds quite nasty. The only thing I can think of from the user side that was perhaps slightly different about this set of edits was they were made with QuickStatements while I already had a different QuickStatements run open and going in another window (a big

[Wikidata-bugs] [Maniphest] [Commented On] T161342: Some data not uploaded to WDQS ?

2017-03-24 Thread Jheald
Jheald added a comment. Thanks for your speedy diagnosis. I've gone through and reverted and then un-reverted the ten edits by hand, so they are now fine. Hope you can get a bit more rigour instilled into the recentchanges logging.TASK DETAILhttps://phabricator.wikimedia.org/T161342EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T157811: Wikidata reference URIs have become too many to search with WDQS SPARQL

2017-03-24 Thread Jheald
Jheald added a comment. So you're saying, in effect, I should think of the strings being stored as a great big hash table rather than a B-tree, so there's nothing there that can help even STRSTARTS. And of course I know very little about the internals of BlazeGraph, whereas you've actually

[Wikidata-bugs] [Maniphest] [Commented On] T161259: moving/copying statements to other items

2017-04-04 Thread Jheald
Jheald added a comment. +1 on the need for this. As WD statements become ever more extended, accumulating qualifiers, references, rankings etc, it becomes more and more of a pain to execute if/when a statement has to be moved from one item to a different item. At the moment it requires

[Wikidata-bugs] [Maniphest] [Created] T162161: UI request for simple ways to quickly make wikidata statements more narrow or more broad

2017-04-04 Thread Jheald
Jheald created this task.Jheald added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONThe UI for categorisation on Commons has a very nice feature that next to categories there is a down-arrow link, that when clicked presents sub-categories of the current category

[Wikidata-bugs] [Maniphest] [Commented On] T161543: Enable geoshape datatype on Wikidata

2017-04-03 Thread Jheald
Jheald added a comment. To make this really useful, it would be valuable for a WDQS query to be able to display such shapes in the map view of query results. (And, also, to be able to display shapes obtained from external sources, such as OpenStreetMap or UK Ordnance Survey, which it would

[Wikidata-bugs] [Maniphest] [Created] T162266: Changes to Wikidata formatter URLs (P1630) are slow to propagate to the website

2017-04-05 Thread Jheald
Jheald created this task.Jheald added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONI changed the formatter URL property (P 1630) for Wikidata property P 3118 over two weeks ago (diff). But the change has still not propagated to items which have not been edited since

[Wikidata-bugs] [Maniphest] [Commented On] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()

2017-03-13 Thread Jheald
Jheald added a comment. As an aside (which should maybe be in a separate ticket) what I really wanted to do was to plot the values on a map. But there seems to be no way to cast variables to a geo:wktLiteral. I tried the following (full query in query editor): BIND(CONCAT("Point(",st

[Wikidata-bugs] [Maniphest] [Created] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONIt would be good to be able to cast calculated variables to type geo:wktLiteral in WDQS SPARQL queries, to allow calculated co

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

2017-03-13 Thread Jheald
Jheald added a comment. As one possible hack that could be a way forward on this, I see that the Blazegraph GeoSpatial extension (description on BlazeGraph wiki) allows custom compound data-types to be defined -- which do not necessarily need to include a geospatial element. One could therefore

[Wikidata-bugs] [Maniphest] [Updated] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald added a comment. Example case: I wanted to be able to look at the geographic distribution of property P3616 by grouping into one-degree-by-one-degree squares, and plotting on a map, colour-coded by the number of instances. (query that doesn't work) The grouping into one-degree-by-one

[Wikidata-bugs] [Maniphest] [Commented On] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()

2017-03-13 Thread Jheald
Jheald added a comment. Just to add: another case where it could be useful to be able to cast calculated co-ordinates back to a geo:wktLiteral would be to allow AVG() co-ordinates to be calculated and plotted, in cases where SAMPLE() is not sufficient.TASK DETAILhttps://phabricator.wikimedia.org

[Wikidata-bugs] [Maniphest] [Commented On] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald added a comment. Another case where it could be useful to be able to cast calculated co-ordinates back to a geo:wktLiteral would be to allow AVG() co-ordinates to be calculated and plotted, in cases where SAMPLE() is not sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T160335EMAIL

[Wikidata-bugs] [Maniphest] [Edited] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald edited the task description. (Show Details) EDIT DETAILSIt would be good to be able to cast calculated variables to type `geo:wktLiteral` in WDQS SPARQL queries, to allow calculated co-ordinates to be included as well as retrieved ones to be included in map views of WDQS output, etcTASK

[Wikidata-bugs] [Maniphest] [Commented On] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald added a comment. Another case where it could be useful to be able to cast calculated co-ordinates back to a geo:wktLiteral would be to allow AVG() co-ordinates to be calculated and plotted, in cases where SAMPLE() is not sufficient.TASK DETAILhttps://phabricator.wikimedia.org/T160335EMAIL

[Wikidata-bugs] [Maniphest] [Created] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()

2017-03-13 Thread Jheald
Jheald created this task.Jheald added projects: Wikidata-Query-Service, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONIf I write a query with columns X, Y, COUNT(), the WDQS scatterplot display mode appears to utterly garble these values.TASK

[Wikidata-bugs] [Maniphest] [Commented On] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()

2017-03-13 Thread Jheald
Jheald added a comment. Example query (view in query editor): SELECT ?int_lon ?int_lat (COUNT(?item) AS ?count) WHERE { ?item wdt:P3616 []. ?item p:P625/psv:P625 ?coords . ?coords wikibase:geoLatitude ?lat . ?coords wikibase:geoLongitude ?long . BIND

[Wikidata-bugs] [Maniphest] [Commented On] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()

2017-03-13 Thread Jheald
Jheald added a comment. Indeed, I still get the same behaviour even if I dispense with the third column entirely, and SELECT just the first two (query) -- so the issue may not involve the counts at all.TASK DETAILhttps://phabricator.wikimedia.org/T160325EMAIL PREFERENCEShttps

[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

[Wikidata-bugs] [Maniphest] [Commented On] T160335: Provide way to cast variables to type geo:wktLiteral in WDQS queries

2017-03-13 Thread Jheald
Jheald added a comment. Perfect. I would never ever have found that. That was exactly what was was needed to make the query work. (results). As for AVG(), no, I think it is not defined over geo:wktLiteral. But so long as one can extract the latitudes and longitudes, AVG() those separately

[Wikidata-bugs] [Maniphest] [Commented On] T157993: Making WDQS onscreen output more Commons friendly

2017-03-01 Thread Jheald
Jheald added a comment. Thanks for this Jonas, but given there is already the nice viewer on the page (which I didn't know about when I wrote the bug, because until then I'd only right-clicked on it), perhaps on consideration a better link is just the simple Commons file page, ie 'https

[Wikidata-bugs] [Maniphest] [Commented On] T89552: Implement International Image Interoperability Framework (IIIF) prototype service on Wikimedia labs

2017-09-18 Thread Jheald
Jheald added a comment. @dschwen Any idea why the IIIF-based detail viewer is working for the images on this page of Shonagon's: Vierge entre les vierges, but not this one: Galerie de vues de la Rome antique ? Opening up the html source for the latter and trying to click on one

[Wikidata-bugs] [Maniphest] [Commented On] T89552: Implement International Image Interoperability Framework (IIIF) prototype service on Wikimedia labs

2017-09-18 Thread Jheald
Jheald added a comment. That looks so great now. Thank you! (And @Shonagon ). Any idea whether this is a problem that would be likely to recur, if the image-detail syntax was put into more high-volume use? (ie can image detail use be treated as stable and reliable (or made so), without needing

[Wikidata-bugs] [Maniphest] [Commented On] T169858: Add support for “instance or subclass of” relation

2017-08-21 Thread Jheald
Jheald added a comment. It would be good to make this work. Another case worth noting is P39 "position held": Position held (P39) can take a value that is either a particular position, eg Mayor of London (Q38931), i.e. a specific instance of (P31) of position (Q4164871); or a gen

[Wikidata-bugs] [Maniphest] [Created] T174930: Problem with federated SPARQL query using UK Ordnance Survey open data -- bad prefix URL being sent ?

2017-09-04 Thread Jheald
Jheald created this task.Jheald added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONI am having a problem with a federated SPARQL query http://tinyurl.com/yad8uzt3 that invokes the UK Ordnance Survey sparql service

[Wikidata-bugs] [Maniphest] [Commented On] T180113: Support the creation and use of volunteer tools that help to convert information in Commons categories to structured data

2017-11-21 Thread Jheald
Jheald added a comment. Hi Magnus, I am intrigued by the idea of the categorisation information being directly accessible in the file's wikibase page; and I presume the template hack to add a category statement on the File page would also keep the SQL tables up to date, which so many tools

[Wikidata-bugs] [Maniphest] [Commented On] T173346: Implement IIIF support on Wikimedia Commons in relation with Structured Data on Commons

2018-08-13 Thread Jheald
Jheald added a comment. A heads-up that "Wikipedia and IIIF" is the proposed subject for the IIIF community call this week -- see https://groups.google.com/forum/?hl=en#!topic/iiif-discuss/wy2uRl_ukJ0 The IIIF community call is a one-hour conference call on Zoom (people can

[Wikidata-bugs] [Maniphest] [Commented On] T173346: Implement IIIF support on Wikimedia Commons in relation with Structured Data on Commons

2018-08-14 Thread Jheald
Jheald added a comment. Thanks @SandraF_WMF . I've started putting together some links at :c:User:Jheald/IIIF_180815 that I or Andy Mabbett could talk through, to give an idea of what sort of IIIF interaction is possible at the moment. Would it be possible for you to take up from that, and add

[Wikidata-bugs] [Maniphest] [Commented On] T199119: Research relationships between items in wikidata

2018-07-14 Thread Jheald
Jheald added a comment. I'd say don't give up too easily. This is probably as good an approach as any. If the issues are structural, bots will fall prey to them in just the same way, just more slowly and more haphazardly. But it probably is going to need a fair number of iterations to slowly

[Wikidata-bugs] [Maniphest] [Updated] T191633: Implement searching of 'depicts' on commons

2018-07-14 Thread Jheald
Jheald added a comment. I have now found T198261 and T199119, which investigate how some of the drawbacks above with the simple string-matching approach might be addressed.TASK DETAILhttps://phabricator.wikimedia.org/T191633EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel

[Wikidata-bugs] [Maniphest] [Updated] T194401: Investigate storing commons data in BlazeGraph

2018-07-14 Thread Jheald
Jheald added a comment. Well of course you're going to copy all the CommonsData statements to Blazegraph. The community will have a fit if you don't make provision for them to run their own SPARQL queries against the data. See T141602 . But see also some of the issues noted on T191633#4425281

[Wikidata-bugs] [Maniphest] [Commented On] T185946: Design UI/UX for Commons File page revamp (SDoC)

2018-07-14 Thread Jheald
Jheald added a comment. Don't you think you should maybe talk to the community about this first ? My expectation is that a very substantial part of the community would prefer a presentation very similar to what we have at the moment, with information primarily presented via the image

[Wikidata-bugs] [Maniphest] [Updated] T191633: Implement searching of 'depicts' on commons

2018-07-14 Thread Jheald
Jheald added a comment. The attached subtickets are an interesting read. They all seem to be based on taking the Q-number value of "depicts", storing it as a string in the text-search index, and then doing an indexed string-match for it. Of course first baby-steps are

[Wikidata-bugs] [Maniphest] [Commented On] T191633: Implement searching of 'depicts' on commons

2018-07-16 Thread Jheald
Jheald added a comment. Interesting slide-show. But the fundamental problem -- as some of the attached tickets start to appreciate -- is that the key information that determines whether an image fits the specification being looked for is not going to be stored in statements just

[Wikidata-bugs] [Maniphest] [Commented On] T191633: Implement searching of 'depicts' on commons

2018-07-14 Thread Jheald
Jheald added a comment. Another example, where such image searches may depend quite sensitively on query construction or query optimisation: Category:Grade I listed buildings in Bedfordshire. One of the aims for faceted search is to be able to match (or even replace) the capabilities of Commons

[Wikidata-bugs] [Maniphest] [Commented On] T181062: Adapt QuickStatements2 to be able to work with structured data on Commons as well

2018-03-02 Thread Jheald
Jheald added a comment. One sidelight on this. QS2 is great (invaluable!) for adding new statements, but not so good for modifying existing statements, especially if they are currently heavily qualified or referenced -- at the moment, the entire statement complete with all qualifiers

[Wikidata-bugs] [Maniphest] [Commented On] T89552: Implement International Image Interoperability Framework (IIIF) prototype service on Wikimedia labs

2018-03-02 Thread Jheald
Jheald added a comment. IIIF image extracts seem to be broken again: see eg the 'Virgin amongst the virgins' test page at Crotos pinging @dschwenTASK DETAILhttps://phabricator.wikimedia.org/T89552EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Multichill

[Wikidata-bugs] [Maniphest] [Commented On] T194401: Investigate storing commons data in BlazeGraph

2018-10-12 Thread Jheald
Jheald added a comment. That's nice. I didn't know that service included Commons. But to be useful for people trying to sync CommonsData on files with their category information, the category membership per file would be needed; as would near-live updates; and inclusion in the production CDQS

[Wikidata-bugs] [Maniphest] [Commented On] T177475: Create a map-on-the-fly feature for people and objects for Wikidata items

2018-10-15 Thread Jheald
Jheald added a comment. Very nice! It's interesting that the sort-order in the subquery is preserved by the GROUP_CONCAT. (So eg this query works: http://tinyurl.com/yafz8zvn) I'm not sure that the SPARQL standard guarantees this, indeed I thought I could remember @Lucas_Werkmeister_WMDE

  1   2   3   >