[Wikidata-bugs] [Maniphest] T327029: WDQS GUI should not remember column sort orderings from previous queries or previous runs
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T327029 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Nikki, Aklapper, Jheald, AWesterinen, MPhamWMF, CBogen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, Mahir256, EBjune, merbst, Salgo60, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T327029: WDQS GUI should not remember column sort orderings from previous queries or previous runs
Jheald created this task. Jheald added a project: Wikidata Query UI. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **Steps to replicate the issue** (include links if applicable): - Run a SPARQL query that includes an ORDER BY clause to explicitly order its results, eg https://w.wiki/6DJj - Use the GUI to change the order, by clicking one of the `^``v` buttons on one of the columns - Re-run the SPARQL query (even in a different window) **What happens?**: - The re-run query returns rows in the order last set using the GUI, not the order specified in the query **What should have happened instead?**: - The re-run query should return results as specified by the ORDER BY clause in the query **Software version** (skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): I am seeing this on Chrome version 109.0.5414.74 on Windows 10. Seems to be a recent reversion -- I wasn't aware of it before January 11. I raised it at WD:RAQ <https://www.wikidata.org/w/index.php?title=Wikidata:Request_a_query=1812197117#ordering_within_a_GROUP_CONCAT> and also on the wikidata Telegram channel; in both forums other users also report seeing this. - UI may also be remembering which page of a multi-page result set one had browsed to. Can be very annoying, if one is trying to debug a complex query, or share an intricate search order -- and finding oneself unexpectedly on a later page of results can make things even more confusing. First principle of least surprise is the GUI should return results in the order they have been asked for. - The behaviour persists even if it is several days since the query last ran; and also even if minor changes are made to the query text, eg by adding spaces -- so can't be a url caching issue. TASK DETAIL https://phabricator.wikimedia.org/T327029 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, AWesterinen, MPhamWMF, CBogen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, Mahir256, EBjune, merbst, Salgo60, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T181319: Support external tabular datasets in WDQS
Jheald added a comment. The OSM Sophox service, which is based on WDQS, has or had a `SERVICE wikibase:tabular` which appears to have providing this capability, see https://wiki.openstreetmap.org/wiki/Sophox#External_Data_Sources so there may be code already in existence that could be merged, or at least used as a basis TASK DETAIL https://phabricator.wikimedia.org/T181319 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Zache, Vojtech.dostal, Abbe98, Ainali, Manuel, Lectrician1, Inductiveload, Theklan, Justin0x2004, johanricher, So9q, Moebeus, CamelCaseNick, Librarian_lena, Gnoeee, John_Cummings, mxn, Base, Ferdinand0101, Mahir256, Bugreporter, Daniel_Mietchen, NavinoEvans, Pasleim, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Astuthiodit_1, AWesterinen, bking, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, ET4Eva, Dinadineke, Nandana, Namenlos314, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, JakeTheDeveloper, QZanden, EBjune, merbst, LawExplorer, Avner, StuartPrior, Silverfish, Reasno, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, Volker_E, SBisson, mys_721tx, Jane023, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, TheDJ, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T150937: table view on Wikidata Query Service -- allow link text for urls
Jheald added subscribers: LucasWerkmeister, Nikki, Jheald. Jheald added a comment. This came up a couple of days ago in discussion again on the wikidata Telegram channel, with several people wishing it was possible, since "displaying the whole url often breaks the table layout". @LucasWerkmeister noted that a couple of other tickets have discussed making aspects of the table view more configurable, viz T223736#5503032 <https://phabricator.wikimedia.org/T223736#5503032> and T227702#5498545 <https://phabricator.wikimedia.org/T227702#5498545> @Nikki suggested that the whenever there was a pair of columns `?variable` and `?variableText`, then if `?variable` was a url and `?variableText` was text, the UI could present them in a single column with the latter as link text. This was well-received, and welcomed as a proposal that seemed sensible and intuitive. TASK DETAIL https://phabricator.wikimedia.org/T150937 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Nikki, LucasWerkmeister, gerritbot, Aklapper, Esc3300, Astuthiodit_1, AWesterinen, bking, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, ET4Eva, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T312781: Cirrus search appears not to be indexing reference URLs from wikidata
Jheald added a comment. Part of the expectation of an RDF-based system is that it should be easy to retrieve URLs of a particular form. It's not appropriate to think or expect the community will index by hand things that directly lend themselves to be indexed by machine - such as fragments of URLs, in particular domains. There's simply no way that trying to index the domains of these URLs in a community-driven way would be as accurate or as comprehensive as automatic indexing -- and it would be pure makework. This is what computers are for. There is too much of a mountain of work to do or to fix on wikidata that actually requires human judgment, to imagine the community is going to waste its time and divert resources to indexing URLs or extracting domain parts when this is so straightforward and done so much better automatically. Blazegraph (like most triplestores) actually comes with the option to turn on full-text indexing for URLs. But this was not done, because, we were told, full-text indexing would be done so much more efficiently by Cirrus, which was already activated. Now it turns out, that was only actually true in certain areas. It's not unreasonable to want to be able to ask how material from a particular source is being used -- and SPARQL should be a perfect tool for doing such analyses. Being able to retrieve references with URLs of a particular type by full text indexing would be best. But if that is not going to be possible, can I suggest at least adding extra triples to the triplestore for the domain part of URLs -- so at least it would be possible to pull out the URLs from a particular domain quickly (and almost instantaneously to count them. That at least would open the door to making more complicated requirements possible. TASK DETAIL https://phabricator.wikimedia.org/T312781 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: MPhamWMF, Lydia_Pintscher, Aklapper, Jheald, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
Jheald added a comment. A comment on the requirement Removing a redirect badge from a sitelink that points to a redirected page is disallowed It's quite important that it should be possible to promote the badge on a redirect, ie from sitelink to redirect (Q70893996) <https://www.wikidata.org/wiki/Q70893996> to intentional sitelink to redirect (Q70894304)) <https://www.wikidata.org/wiki/Q70894304>, to allow such a sitelink to be reviewed and noted to be okay. Demotions may also be needed. Such re-writing of badges should be possible by bots (eg using pywikibot), as well as for humans through the UI. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Michael, William_Cheselden, Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T246731: WDQS date handling produces errors for Julian dates
Jheald added a subscriber: Jc3s5h. Jheald added a comment. Also raised in that discussion was ticket: T207705 <https://phabricator.wikimedia.org/T207705> "Implement the Extended Date/Time Format Specification" (EDTF) EDTF (info <https://www.loc.gov/standards/datetime/>) is an extension to ISO 8601 (specifically, part of ISO 8601-2:2019), developed by the Library of Congress with other bibliographic institutions, which defines a format for serialising imprecise or complex dates into strings. It is now increasingly in use in the wild -- for example in the cataloguing data of GLAM institutions, especially library systems; in applications like Zotero <https://en.wikipedia.org/wiki/Zotero>; in communities such as the Citation Style Language <https://en.wikipedia.org/wiki/Citation_Style_Language> community; and elsewhere. On the face of it (as @Jc3s5h has repeatedly noted on that ticket), implementing EDTF doesn't necessarily help with the Julian/Gregorian policy. EDTF is an exension of `xsd:dateTime`, and like `xsd:dateTime` an `edtf:EDTF` date by both //construction// and //definition// represents a Gregorian date (or a more complex entity built from Gregorian dates). However, I suggest in this contribution <https://phabricator.wikimedia.org/T207705#8091791> to that ticket (Jul 20, 2022), there may be a way forward. As well as implementing dates with an rdf dataype `^^edtf:EDTF` , we could also instead give appropriate dates an alternate rdf datatype `^^wb:EDTF-J`. These dates would be almost identical to the `^^edtf:EDTF` dates -- in fact the string parts would be exactly identical, representing the same Gregorian day or same range of Gregorian days -- but the different `^^wb:EDTF-J` datatype would represent a request, that the wdqs onscreen rendering could pick up on, to translate the date to the corresponding date in the Julian calendar and display that if possible. (Similar to the meaning of `wikibase:timeCalendarModel` = Julian in a `wikibase:time` node; but the wdqs gui will not usually have access to that). It occurs to me that the same approach could be used for `xsd:dateTime` dates too, changing the RDF dump so that eg `wdt:P569` statements were written with an RDF type `^^wb:dateTime-J` if one wanted to attach a request that they should be rendered as their Julian equivalent. I think this might be slightly more involved to implement (though I could be wrong), as I think one would want to make sure that the `^^wb:dateTime-J` dates were treated by Blazegraph internally in the same way as `^^xsd:dateTime` dates (ie translated internally into milliseconds, and with functions like `day()` `month()` and `year()`. subtraction, `<`, and `>` all returning the same results. But I could be wrong, and with the magic of subclassing in Java it might all be possible without too much pain, so I think could be worth investigating. Otherwise, failing that, if we did implement `^^edtf:EDTF` and `^^wb:EDTF-J` as per T207705 <https://phabricator.wikimedia.org/T207705>, that could give a way to allow WDQS to correctly render and properly indicate Gregorian and Julian dates, at least for statements with triples with those datatypes. TASK DETAIL https://phabricator.wikimedia.org/T246731 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jc3s5h, Lydia_Pintscher, Epidosis, Manuel, Jheald, agray, Gehel, Toni_001, Lucas_Werkmeister_WMDE, Mahir256, Tagishsimon, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification
Jheald added a comment.
As noted by @GreenReaper above, the Wikibase_EDTF
<https://www.mediawiki.org/wiki/Extension:Wikibase_EDTF> wikibase extension
should now give a solid basis for building EDTF support on wikibase, allowing
EDTF strings to be input, validated, and rendered by the wikibase GUI, if we
want to add properties with an EDTF datatype to Wikibase.
A separate but related issue is what adaptations could or should be made to
WDQS to support EDTF. (And could this help with issue T159160
<https://phabricator.wikimedia.org/T159160> "Take account of date precision
when displaying dates in WDQS GUI").
Here are some possible steps towards adding EDTF awareness to WDQS:
1. Extend the GUI output code to recognise objects with rdf type
`^^http://id.loc.gov/datatypes/edtf/EDTF` (equivalent to `^^edtf:EDTF` for
short) as representing EDTF dates, and display columns of them in the output in
an appropriately readble way for human consumption ("humanization"). Some of
the internationalisation developed for the Commons Other date
<https://commons.wikimedia.org/wiki/Template:Other_date> template and
underlying Complex date
<https://commons.wikimedia.org/wiki/Module:Complex_date> Lua module, the
Wikibase EDTF <https://www.mediawiki.org/wiki/Extension:Wikibase_EDTF> project,
or other EDTF implementations
<https://www.loc.gov/standards/datetime/implementations.html> may help with
translations. The standard defines different levels of EDTF compliance; it
might be reasonable initially to support only a subset of the standard
initially. Functionality could be tested by building suitable strings in
SPARQL queries, using the `strdt()` function to cast them to type `edtf:EDTF`.
2. Once it is possible for the GUI to interpret and display EDTF dates, add
triples to the SPARQL triplestore and the RDF dump with new prefixes (perhaps
`wdtn:` and `psn:`) to give EDTF-valued dates, so `wd:Q692 wdtn:P569
[1564-04..1564-04-26]^^edtf:EDTF`. The ability to use these forms in queries
should substantially address the T159160
<https://phabricator.wikimedia.org/T159160> problem, without affecting existing
queries.
3. The new triples should not replace the existing `wdt:` and `ps:` triples,
nor existing `psv:` triples with their `wikibase:time`valued nodes, but exist
alongside them.
The EDTF format, even if normalised through eg the edtf.js
<https://github.com/inukshuk/edtf.js#unspecified-uncertain-and-approximate-dates>
javascript package used by Zotero, IMO contains too many ways to express
more-or-less the same thing, which counts against efficient indexing or
retrieval. Its ability to represent complex and approximate dates does not
lend itself to the kind of range-safe fast indexing
<https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization#Fixed_values_and_ranges>
that can be used to retrieve exact dates (represented internally by Blazegraph
as exact microseconds since a particular moment). Similarly, if one wants to
find dates with a year-precision or a month-precision, the existing
`wikibase:time`valued nodes express that information directly as RDF statements
which are all indexed, whereas to extract corresponding EDTF statements would
require much slower assembling of the whole dataset then filtering with string
operations and/or regexes. Even edtf shops are trying to find good ways to
model the format in RDF (example <https://periodo.github.io/edtf-ontology>).
Given that we already now have a quite developed model for complex dates as
statements, IMO it would not make sense to give it up (contra @Spinster?). Also
I suspect there are area where it achieves more nuance and exactness than the
current version of EDTF.
Instead I would suggest that we keep the existing data model on wikidata as
the primary way of representing complex dates. I would suggest that the only
EDTF valued-property we should would be a single `EDTF date stated as`. Input
should be allowed eg of the form `P571 inception = //somevalue//, qualifier:
EDTF date stated as = ...` Bots should then translate this into wikidata dates
and qualifiers, moving the `EDTF date stated as = ...` qualifier to the
reference when this is done. EDTF-valued `wdtn:` and `psn:` triples should be
constructed from the wikidata statement and its qualifiers, to be accessible
via SPARQL, LDF, rdf dumps, or an API request. This would allow data to be
edited and round-tripped back to institutions, and input to be compared with
output, while maintaining a single preferred unified model in wikidata for
representing complex dates.
4. At the present time, with our use of Blazegraph perhaps approaching
end-of-life, an aversion to implementing new services or functions specific to
that platform is understandable. However I believe an exception should be made
for a pa
[Wikidata-bugs] [Maniphest] T159160: Take account of date precision when displaying dates in WDQS GUI
Jheald added a comment. Over on T207705 <https://phabricator.wikimedia.org/T207705> "Implement the Extended Date/Time Format Specification" (contribution <https://phabricator.wikimedia.org/T207705#8091791>), I have suggested how I think we might substantially solve this ticket, realistically and achievably, by - (i) adding EDTF awareness to the wdqs output gui, and - (ii) adding an EDTF-valued form of triples to the RDF dump of date statements EDTF would also be a very useful output format for complex dates in its own right TASK DETAIL https://phabricator.wikimedia.org/T159160 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Epidosis, Manuel, ShiehJ, DD063520, Lucas_Werkmeister_WMDE, ChristianKl, agray, Smalyshev, Aklapper, Jheald, Astuthiodit_1, AWesterinen, bking, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, ET4Eva, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification
Jheald added a project: Wikidata data quality and trust. TASK DETAIL https://phabricator.wikimedia.org/T207705 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313171: When looking at an old revision of a Commons file page, it should render the old version of the wikitext (including templates) acting on the old version of the SDC
Jheald added a comment. Possibly related to: T187935 <https://phabricator.wikimedia.org/T187935> "Allow cross-slot access during HTML rendering" TASK DETAIL https://phabricator.wikimedia.org/T313171 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, toberto, GFontenelle_WMF, FRomeo_WMF, CBogen, Nintendofan885, JKSTNK, Lahi, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Tramullas, Acer, Salgo60, Silverfish, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313171: When looking at an old revision of a Commons file page, it should render the old version of the wikitext (including templates) acting on the old version of the SDC
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T313171 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, toberto, GFontenelle_WMF, FRomeo_WMF, CBogen, Nintendofan885, JKSTNK, Lahi, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Tramullas, Acer, Salgo60, Silverfish, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313171: When looking at an old revision of a Commons file page, it should render the old version of the wikitext (including templates) acting on the old version of the SDC
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T313171 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, toberto, GFontenelle_WMF, FRomeo_WMF, CBogen, Nintendofan885, JKSTNK, Lahi, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Tramullas, Acer, Salgo60, Silverfish, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313171: When looking at an old revision of a Commons file page, it should render the old version of the wikitext (including templates) acting on the old version of the SDC
Jheald renamed this task from "When looking at an old revision of a Commons file page, it should be render the old version of the wikitext (including templates) acting on the old version of the SDC" to "When looking at an old revision of a Commons file page, it should render the old version of the wikitext (including templates) acting on the old version of the SDC". TASK DETAIL https://phabricator.wikimedia.org/T313171 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, toberto, GFontenelle_WMF, FRomeo_WMF, CBogen, Nintendofan885, JKSTNK, Lahi, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Tramullas, Acer, Salgo60, Silverfish, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T313171: When looking at an old revision of a Commons file page, it should be render the old version of the wikitext (including templates) acting on the old version of the
Jheald created this task.
Jheald added projects: Structured Data Engineering, SDC General.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Structured-Data-Backlog.
TASK DESCRIPTION
As a user, when I look at an old revision of a file page on Commons, I want
to see a representation of the SDC as it was at the time of the old revision,
filtered through the templates that were in the wikitext at the time of the old
revision.
At the moment this is not happening.
For example here is a Commons file
<https://commons.wikimedia.org/wiki/File:Plaque_on_the_footbridge_over_the_River_Carron_in_Stonehave,_-_geograph.org.uk_-_2662954_(cropped).jpg>
with a description page that generated almost entirely from SDC by the
`{{Geograph from structured data}}` template. At the time of the first
revision
<https://commons.wikimedia.org/w/index.php?title=File:Plaque_on_the_footbridge_over_the_River_Carron_in_Stonehave,_-_geograph.org.uk_-_2662954_(cropped).jpg=674865135>
the file had no SDC statements; these were then added one by one (as confirmed
by the history
<https://commons.wikimedia.org/w/index.php?title=File:Plaque_on_the_footbridge_over_the_River_Carron_in_Stonehave,_-_geograph.org.uk_-_2662954_(cropped).jpg=history>).
However, when one looks at the the first revision
<https://commons.wikimedia.org/w/index.php?title=File:Plaque_on_the_footbridge_over_the_River_Carron_in_Stonehave,_-_geograph.org.uk_-_2662954_(cropped).jpg=674865135>,
the rendering that is presented does not reflect the SDC as it was at the time
of that first revision. Instead the template is rendered on the basis of the
SDC as it is //now//. This entirely fails to represent the the file
information as it was at the time of the revision selected.
An important aspect of a wiki is the ability to "roll back time", to see a
representation of a page as it was at the time of some revision in the past,
and to understand the effect of revisions made since.
It is understood that the representation of the past is only approximate (for
example templates are expanded as they are at the present, not as they were
then) -- but one still gets a fair impression of the state of the information
on the page as it was. But at the moment for file pages this is not possible.
At the moment one cannot choose a revision and see a representation (not even
an approximate one) of the SDC as it was at the time of that revision, as
filtered through the wikitext as it was at the time of the revision. Fixing
this is essential for the page-history to serve a useful purpose.
TASK DETAIL
https://phabricator.wikimedia.org/T313171
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jheald
Cc: Aklapper, Jheald, toberto, GFontenelle_WMF, FRomeo_WMF, CBogen,
Nintendofan885, JKSTNK, Lahi, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF,
Tramullas, Acer, Salgo60, Silverfish, Susannaanas, Fuzheado, Jane023,
Wikidata-bugs, Base, matthiasmullie, Daniel_Mietchen, Ricordisamoa, Wesalius,
Lydia_Pintscher, Raymond, Steinsplitter
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T262837: SDC statements should record entity usage for wikidata entities used in statements
Jheald added a comment. As noted at Data Quality only workshop last weekend, this lack of registration is also causes a problem for the community with the deletion discussion process on wikidata, as (unlike usage in wikidata statements), there is no warning given when an item being considered for deletion on wikidata is being referenced by SDC statements. This can (and increasingly has) lead to items being deleted on wikidata because nobody realised they were in use by and needed by Commons. TASK DETAIL https://phabricator.wikimedia.org/T262837 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Bencemac, Manuel, Multichill, Tacsipacsi, Jarekt, Lucas_Werkmeister_WMDE, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, GFontenelle_WMF, maantietaja, FRomeo_WMF, CBogen, ItamarWMDE, Nintendofan885, Akuckartz, Nandana, JKSTNK, Lahi, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T312781: Cirrus search appears not to be indexing reference URLs from wikidata
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T312781 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lydia_Pintscher, Aklapper, Jheald, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T312781: Cirrus search appears not to be indexing reference URLs from wikidata
Jheald added projects: Wikidata, Discovery-Search (Current work). TASK DETAIL https://phabricator.wikimedia.org/T312781 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T253771: WDQS gives dates that are two days ealier than reported on the item page and the API
Jheald added a comment. Not a very happy situation, though, if there is no way in WDQS to retrieve a Julian-format date that is what is entered on the wikidata item and would be universally used on sources. T246731 <https://phabricator.wikimedia.org/T246731> is open as a live bug asking for somw attention on this. TASK DETAIL https://phabricator.wikimedia.org/T253771 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Lucas_Werkmeister_WMDE, Dipsacus_fullonum, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T311139: Map popups in Wikidata query service UI have tiny font size
Jheald added a comment. Text used for the layers pop-up in the map view has also become tiny (ie the text from hovering over the layers button at the top right in a query like https://w.wiki/5L4s) TASK DETAIL https://phabricator.wikimedia.org/T311139 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Tagishsimon, Lucas_Werkmeister_WMDE, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
Jheald added a comment. It is also particularly annoying that at the moment one cannot even add the badge to an existing redirect sitelink, without the above error message and the edit being blocked. It would be really good to get this fixed. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
Jheald added a comment. Just to note that the proposed recommended user behaviour has not yet been implemented: - GIVEN an Item - AND a page on the client that is a redirect - WHEN adding the page as a sitelink to the Item - AND adding a redirect badge in the same edit - THEN the sitelink and associated badge are stored (even if the redirect target is already used in another Item) Instead the user is currently thrown the following warning message: - Could not save due to an error. - The save has failed. - Site link enwiki: is already used by item Q. . Perhaps the items should be merged. Ask at d:Wikidata:Interwiki conflicts if you believe that they should not be merged. After all this time, it would be really good to fix this. Can I also suggest a slight modification to the first case: that if the editor is trying to the above, but has not added the "intentional redirect" badge in the same edit, that they should be prompted to do so, when the edit is rejected. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T229460: Support standard MediaWiki API continuation in wbsearchentities module / wbsearch list/generator
Jheald added a comment. Thanks for that clarification, Lucas, that's useful. So yes, I can use the "search" API instead: https://w.wiki/5BsM and successfully retrieve far more entries (??? albeit very slowly -- query took almost 100 seconds, just for 500 returns); but then I cannot restrict the search to just the labels of items. (I can restrict the search to //titles// of pages -- but for wikidata the titles appear to be Q-numbers, so that doesn't help). So I still can't get the items I need. ((Note -- I now see that the specific issue of not being able to get continuations of MWAPI actually has its own bug, T229291 <https://phabricator.wikimedia.org/T229291>; but as Lucas notes there, this bug is the underlying issue)). ((2. I'm also wondering whether the general issue of not being able to get EntitySearch to do everything that standard search can (of which this bug is one aspect) is also the real issue underlying T235496 <https://phabricator.wikimedia.org/T235496> -- ie the lack of being able to do a "nearmatch" search in any kind of search for a wikidata label)) TASK DETAIL https://phabricator.wikimedia.org/T229460 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Addshore, gerritbot, SJu, Michael, DaBPunkt, edwardbetts, Smalyshev, Lucas_Werkmeister_WMDE, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T235496: EPIC: Adapt "did you mean suggestions" using the phrase suggester for wikibase
Jheald added a comment. Previously raised on-wiki at - https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2019/10#Search_is_very_poor_at_mis-spellings - https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2021/04#Search_is_very_intolerant_of_mis-spellings TASK DETAIL https://phabricator.wikimedia.org/T235496 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, dcausse, Aklapper, Astuthiodit_1, BeautifulBold, Suran38, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, Wilmanbeno, Peteosx1x, NavinRizwi, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, jayvdb, Mbch331, jeremyb ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T229460: Support standard MediaWiki API continuation in wbsearchentities module / wbsearch list/generator
Jheald added a comment. Am I right that there is currently no way to get continuation via MWAPI from SPARQL at all ? (cf MWAPI docs <https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual/MWAPI#Find_articles_in_Wikipedia>, Wikibase/API docs <https://www.mediawiki.org/wiki/Wikibase/API> , wbsearchentities docs <https://www.wikidata.org/w/api.php?action=help=wbsearchentities>) For example, here is a query to get items with labels containing the names of historic English counties: https://w.wiki/5BpN (with the intention of then restricting it to items for food or drink). There seems to be no way to get more than the first 50 returns per county ? TASK DETAIL https://phabricator.wikimedia.org/T229460 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Addshore, gerritbot, SJu, Michael, DaBPunkt, edwardbetts, Smalyshev, Lucas_Werkmeister_WMDE, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T306334: WDQS Map view doesn't distinguish layers with same label but different Qids
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T306334 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T199062: Strange behavior of wikidata query map visualization with layers
Jheald added a comment. Duplicate of T189423 <https://phabricator.wikimedia.org/T189423> TASK DETAIL https://phabricator.wikimedia.org/T199062 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, Zeroth, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T199062: Strange behavior of wikidata query map visualization with layers
Jheald added a comment. Yes: it seems that where there are multiple results with the same coordinates, in the same layer, only one is shown, the others are suppressed TASK DETAIL https://phabricator.wikimedia.org/T199062 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, Zeroth, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T306334: WDQS Map view doesn't distinguish layers with same label but different Qids
Jheald created this task. Jheald added a project: Wikidata Query UI. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Example query (drainage basins of Scottish rivers): https://w.wiki/54oh Opening the layers control, and toggling "River Dee" causes two different river basins to flash, even though they have different Qids (Q964949 ; Q7337328) in the ?layer column. TASK DETAIL https://phabricator.wikimedia.org/T306334 WORKBOARD https://phabricator.wikimedia.org/project/board/2901/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, MPhamWMF, CBogen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, Mahir256, EBjune, merbst, Salgo60, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T305858: When replacing Blazegraph, need to understand how the proprietary GAS Service is used, in order to replace it
Jheald added a comment. (Note: previous comment inadvertently saved when only 1/3 written, so it may be needed to check web version (if not here already) for full text). TASK DETAIL https://phabricator.wikimedia.org/T305858 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: AWesterinen, Jheald Cc: Lydia_Pintscher, Jheald, Mahir256, Lucas_Werkmeister_WMDE, Aklapper, MPhamWMF, AWesterinen, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T305858: When replacing Blazegraph, need to understand how the proprietary GAS Service is used, in order to replace it
Jheald added a comment.
One can find a few more examples of queries using the service by searching
the archives of the Request-a-Query page, like this
<https://www.wikidata.org/w/index.php?search=%22gas%3Aservice%22=Wikidata%3ARequest+a+query%2F=Special%3ASearch=advanced=1=1>,
and a few more if the search is widened to all wiki pages on wikidata (here
<https://www.wikidata.org/w/index.php?title=Special:Search=500=0=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=1=%22gas%3Aservice%22+inlanguage%3Aen={%22fields%22:{%22inlanguage%22:%22en%22}}>
-- limited to pages in English, to suppress translation duplicates).
I haven't completely looked through all the search returns exhaustively; but
all the ones I have looked at so far are essentially similar to the two railway
queries posted by Mahir -- either
(i) find all the nodes that can be reached using a particular choice of
properties from a particular starting point, with a count of how many hops they
are away; or alternatively return just the nodes that are on the shortest path
from A to some particular B.
BFS or the SSSP
TASK DETAIL
https://phabricator.wikimedia.org/T305858
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: AWesterinen, Jheald
Cc: Lydia_Pintscher, Jheald, Mahir256, Lucas_Werkmeister_WMDE, Aklapper,
MPhamWMF, AWesterinen, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja,
CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86,
GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper,
Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984,
Manybubbles, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T301163: Making the table view editable for logged in Wikimedia users
Jheald added a comment. This would be difficult to do within WDQS (and a distraction from the main purpose of WDQS ?) But there is a tool which does something quite like this: Wikidata TABernacle <https://www.wikidata.org/wiki/Wikidata:TABernacle> -- used particularly for labels and descriptions, but a column for any field can be requested TASK DETAIL https://phabricator.wikimedia.org/T301163 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Yug, Aklapper, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T294803: WDQS query returns dead links instead of SomeValue values
Jheald added a comment. We really ought to be doing better than this TASK DETAIL https://phabricator.wikimedia.org/T294803 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Bugreporter, Lucas_Werkmeister_WMDE, Jarekt, Aklapper, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T199241: If a MediaInfo items depicts something that has its own 'depicts' statements, add those to the search index too
Jheald added subscribers: CBogen, Jheald. Jheald added a comment. @CBogen Can you clarify the 'decline' here? If the object of a photo is something like a painting or an engraving or a sculpture, then the design for the data assumed up until now is that the information what that painting or sculpture or engraving shows will be in an item on wikidata for the object, and usually /not/ in the Commons SDC. So if we want a Commons search for cats to bring back not just snapshots of cats, but also paintings of cats, the assumption has been that that information from wikidata will have to get included into what is searched by Commons search too. If this is not now to be the case, that is a *major* change of direction, and needs to be actively presented to the Commons SDC community -- it's a much bigger deal, one that the SDC editing community needs to know and understand about; not something to be just quietly closed here without any reference. TASK DETAIL https://phabricator.wikimedia.org/T199241 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, CBogen, SandraF_WMF, gerritbot, Aklapper, Ramsey-WMF, Abit, Cparle, toberto, Invadibot, MPhamWMF, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: allow sitelinks to redirects if redirect badge is used
Jheald added a comment. On many wikipedias the template "wikidata redirect' is available : https://www.wikidata.org/wiki/Q16956589 TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, Jakob_WMDE, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, Gamaliel, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T278962: allow sitelinks to redirects if redirect badge is used
Jheald added a comment. Re not removing a badge : note that it may be important for a user or bot to be able to //change// a badge, in particular from 'sitelink to redirect' (Q70893996) to 'intentional sitelink to redirect' (Q70894304), if the user determines that the redirect is valuable. I'm not sure I'd lose too much sleep about users potentially removing badges, given that most redirects are currently unbadged, and quite possibly sitelinks to new redirects created by merges on wikipedias may not be badged. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, Jakob_WMDE, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, Gamaliel, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. Addshore's suggested way forward from 10 February seems very sensible. In particular, it would finally allow bots to add the badges to triage existing sitelinks-to-redirects, which currently they are not able to easily do. This at the very least should be facilitated. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: MSGJ, Jakob_WMDE, WMDE-leszek, Samantha_Alipio_WMDE, Addshore, Simon_Villeneuve, ChristianKl, seav, kaldari, Eugene, Naseweis520, DemonDays64, DannyS712, Ladsgroup, Gamaliel, Fuzheado, ItamarWMDE, JAnD, Hsarrazin, deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, Invadibot, maantietaja, Alter-paule, Hazizibinmahdi, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T160325: [Bug] WDQS scatterplot behaves strangely when third column is a COUNT()
Jheald added a comment. Probably an effect of T168341 <https://phabricator.wikimedia.org/T168341> , if the count values were not unique TASK DETAIL https://phabricator.wikimedia.org/T160325 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jonas, Aklapper, Jheald, MPhamWMF, maantietaja, CBogen, Akuckartz, ET4Eva, Nandana, Namenlos314, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, FloNight, Xmlizer, abian, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T168341: Chart views sometimes combine multiple numeric results into one
Jheald added a comment. I just got bitten by this, as described here at WD:RAQ <https://www.wikidata.org/w/index.php?title=Wikidata:Request_a_query=1382623305#Scatterplot_query>. I was plotting a scatter-plot for the difference in coordinates between two different sources https://w.wiki/36Kk , and got a rogue point that was completely out of scale compared to everything else. It turned out that a lot of my items had the label "Manor Farmhouse", and the plot had added the value for all such items together. This is not behaviour that I would ever have expected, nor that I desired. It's a definite trap for the unwary -- and even for the wary, it's quite an unexpected burden to have to //ensure// that all the labels are different -- in so many queries, multiple values may slip past, introducing subtle undermining errors into the query output. This is a bug, not a feature, and it ought to be sorted out. I would also heartily support action on T185476 <https://phabricator.wikimedia.org/T185476> to allow more flexibility in the way WDQS columns are used as output. It is absurd that only one column can be chosen to describe the points (unlike eg the map display-mode, where multiple columns can be displayed), and it is also really really unhelpful that even that single column cannot be a URL or an item link. This is very poor, and essentially cripples the usefulness of the charts that can be output. TASK DETAIL https://phabricator.wikimedia.org/T168341 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, WikidataFacts, Fnielsen, MPhamWMF, maantietaja, CBogen, Akuckartz, ET4Eva, Nandana, Namenlos314, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, merbst, LawExplorer, Salgo60, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, abian, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275286: SDC: Suppress usual UI display of a property when its number of statements is very large
Jheald added a comment. A couple of follow-up things. 1. There are now specific Wikiproject pages for the upload, at https://www.wikidata.org/wiki/Wikidata:WP_EMEW/Map_uploads -- please forgive for being rough and ready, the whole EMEW wikiproject is only ten days old 2. Bert Spaan (IIIF maps SIG co-chair, https://www.allmaps.org , ex-NYPL, came to Wikimania Stockholm) is on a 'get to know' zoom call *today* (1pm London / 2pm NL) with the project and GIS co-leads from Viae Regiae. If there is anybody working on WMF-GLAM-IIIF that this would be useful to, to attend as an observer, please email me for the link -- jpm.heald (at) gmail.com Bert will be talking about what is possible using map-IIIF (ie the software he's developed: http://www.allmaps.org which could be a very useful replacement for the frankly horrible present version of Commons MapWarper), what VR should be looking to export to fit the map IIIF toolchain, and what they can import from map-IIIF manifests. TASK DETAIL https://phabricator.wikimedia.org/T275286 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Ainali, PKM, Spinster, LucasWerkmeister, SandraF_WMF, David_Haskiya_WMSE, FRomeo_WMF, GFontenelle_WMF, Aklapper, Jheald, CBogen, Nintendofan885, Akuckartz, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T275286: SDC: Suppress usual UI display of a property when its number of statements is very large
Jheald added subscribers: GFontenelle_WMF, FRomeo_WMF, David_Haskiya_WMSE,
SandraF_WMF, Lucas_Werkmeister_WMDE, LucasWerkmeister, Spinster.
Jheald added a comment.
A bit more about the use-case. Early next month the external Viae Regiae
<https://viaeregiae.org/> project, with which Wikidata:WikiProject Early Modern
England and Wales
<https://www.wikidata.org/wiki/Wikidata:WikiProject_Early_Modern_England_and_Wales>
is closely co-operating, will start a mass participation effort to transcribe
all of the places and placenames on several series of 16th and 17th century
maps, like this 1576 Saxton map of Essex
<https://commons.wikimedia.org/wiki/File:Essexiae_Comitat%27_Nova_vera_ac_abfoluta_defcription_Ano_Dni_1576_Christophorus_Saxton_defcripfit_RMG_L8560-001.jpg>
on Commons. (They will actually be using a higher-resolution copy, which we
will be uploading).
As can be seen from the map, the number of places on it is very large; the
process may generate of the order of 1000 located places per map, which we
should like to record as Commons SDC, using either `P180` "depicts" or some
similar property, with qualifier `P2677` "relative position within image".
The wikibase software should handle this number of statements per file-item.
But the SDC user interface will not, Attempting to display 1000 depicts
statements would make the SDC information page essentially unusable, if it did
not crash altogether. The solution suggested is therefore to suppress display
of statements when the number of statements for a particular property becomes
very large, and suggest the user interact with them in some other way.
Use of SDC to display annotation information for images has been a core
use-case for SDC from the start. T214405
<https://phabricator.wikimedia.org/T214405> ("Designing for structured image
annotations") links some of the other tickets that have been raised for
annotation in the past. The present ticket is not a duplicate of T214405
<https://phabricator.wikimedia.org/T214405> (on which work has currently been
frozen), nor does it depend on it, but it probably is a blocker for it.
Uploading media files with a very large number of annotations will be a
valuable stress-test for Commons wikibase, in particular per-page performance
under such conditions. It will be extremely useful to be able to see how well
the UI and supporting software can handle the editing of other statements on
the file, when such a very large number of statements (albeit undisplayed) are
already present on an item.
The ability of SDC to usefully handle annotations, sometimes very large
numbers of annotations, is of critical importance to the GLAM sector's interest
in the project. At the suggestion of @SandraF_WMF (now a civilian again as
@Spinster), who previously carried out scoping work in this area, I am
therefore copying in @FRomeo_WMF and @GFontenelle_WMF to this ticket.
Even though work on T214405 <https://phabricator.wikimedia.org/T214405> is
currently frozen, the presence of images with very high number of annotations
will be a useful resource for the further development and refinement of
user-created tools in this area.
In particular @Lucas_Werkmeister_WMDE (in his private capacity as
@LucasWerkmeister) has developed a tool as described at
https://www.wikidata.org/wiki/User:Lucas_Werkmeister/Wikidata_Image_Positions
to examine and edit/create statements with such `P2677` "relative position
within image" qualifiers (visual example
<https://wd-image-positions.toolforge.org/item/Q1231009>), and also to export
them into working IIIF manifests, to allow them to be viewed (and ingested for
further editing) in external viewers such as Mirador (click on the 'speech
bubble' icon at the top left of the image to visually display the annotations
<https://iiif.si.edu/mirador/?manifest=https://wd-image-positions.toolforge.org/iiif/Q1231009/P18/manifest.json>).
In future the tool may also be able to work similarly with annotations
attached to non-rectangular polygons using ` P8276 ` "region within image"
(value syntax open to modification, for most flexible reusability).
The presence of these images on Commons, with high amounts of annotation
information, will therefore be a useful test for developing our ability to read
infomation in, find good ways to represent it as SDC, and then round-trip it
out again as IIIF. This is the essence of T173346
<https://phabricator.wikimedia.org/T173346> and a fundamental technology
path-finder for T261621 <https://phabricator.wikimedia.org/T261621> (Copying in
@David_Haskiya_WMSE)
To be able to check the well-functioning of SDC in such cases, when very
large amounts of SDC content of one particular kind may be present, it would be
very very desirable that the SDC UI tab continues to
[Wikidata-bugs] [Maniphest] T275286: SDC: Suppress usual UI display of a property when its number of statements is very large
Jheald created this task. Jheald added a project: SDC General. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION Certain use-cases may generate //very// large numbers of statements for a particular property -- for example, content annotation of certain old maps As a user, if the number of statements for a property is very large, I would like the UI **not** to display the statements, but instead to advise me to try to view and edit them some other way TASK DETAIL https://phabricator.wikimedia.org/T275286 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, GFontenelle_WMF, FRomeo_WMF, CBogen, Nintendofan885, Akuckartz, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T252259: Refine Commons Template:Map with Lua modules to populate the template with Wikidata
Jheald added a comment. A couple of days ago I have switched Tempate:Map <https://commons.wikimedia.org/wiki/Template:Map> to use the lua Module:Map <https://commons.wikimedia.org/wiki/Module:Map> rather than wikitext. Thanks to everyone on this thread who put so much work in to get Module:Map to this stage! The old version is available as Template:Map.old <https://commons.wikimedia.org/wiki/Template:Map.old>, so you can go to your favourite maps and switch back and forth between the two, just to make sure everything all still works. There are a few cosmetic changes, in particular for some of the fields the source for their labels and internationalisations has been changed (eg to use labels drawn from wikidata); but with luck overall functionality should be pretty much the same. If there are any problems, do report them on the template talk page <https://commons.wikimedia.org/wiki/Template_talk:Map#Switching_to_Module:Map_back-end> or here. So far there doesn't seem to be an army there with pitchforks and flaming torches, so I am hoping there haven't been too many bumps. TASK DETAIL https://phabricator.wikimedia.org/T252259 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Marsupium, Verdy_p, mxn, Chippyy, Yupik, Abbe98, TiagoLubiana, Jarekt, Aklapper, Susannaanas, Librarian_lena, Liuxinyu970226, Muchiri124, CBogen, Akuckartz, Nandana, lucamauri, Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, LawExplorer, StuartPrior, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Volker_E, Ixocactus, SBisson, Wong128hk, Jane023, Wikidata-bugs, aude, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331, Keegan ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T173346: Implement IIIF support on Wikimedia Commons in relation with Structured Data on Commons
Jheald added a comment. Long-term subscribers to this ticket will be excited to see T261621 <https://phabricator.wikimedia.org/T261621> **Support the addition of the IIIF API for Wikimedia projects regarding content partnerships** created two weeks ago and this announcement that's just appeared on the IIIF community's IIIF-discuss list ( https://groups.google.com/g/iiif-discuss/c/r9yf2GnaF1U ) : > Hi all -- > > I'm writing to share some exciting news: the Wikimedia Foundation is scoping an implementation of IIIF on Wikimedia Commons! > > They will be hosting two meetings to discuss the project and allow GLAM professionals to share their experiences of IIIF. We encourage IIIF community members to join to contribute use cases. > > - September 21, 2020, 3:30-4:30pm UTC > - September 22, 2020, 11:30am-12:30pm UTC > > Links to the Zoom meeting URLs and more details can be found here: > https://iiif.io/news/2020/09/14/wikimedia-IIIF-meeting/ TASK DETAIL https://phabricator.wikimedia.org/T173346 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Abbe98, Glenrobson, Alicia_Fagerving_WMSE, David_Haskiya_WMSE, Regisrob, Astinson, EvanProdromou, Jdforrester-WMF, Pigsonthewing, Dodeeric, Jheald, Puik, Susannaanas, Fuzheado, Keegan, Ainali, Ramsey-WMF, Swiss-National-Library, BeatEstermann, YULdigitalpreservation, brion, Sadads, Abit, SandraF_WMF, Aklapper, CBogen, Akuckartz, Antti.Kekki, darthmon_wmde, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Cparle, Anooprao, GoranSMilovanovic, Chicocvenancio, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Nikerabbit, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T173346: Implement IIIF support on Wikimedia Commons in relation with Structured Data on Commons
Jheald added a parent task: T261621: ☂Support the addition of the IIIF API for Wikimedia projects regarding content partnerships. TASK DETAIL https://phabricator.wikimedia.org/T173346 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Abbe98, Glenrobson, Alicia_Fagerving_WMSE, David_Haskiya_WMSE, Regisrob, Astinson, EvanProdromou, Jdforrester-WMF, Pigsonthewing, Dodeeric, Jheald, Puik, Susannaanas, Fuzheado, Keegan, Ainali, Ramsey-WMF, Swiss-National-Library, BeatEstermann, YULdigitalpreservation, brion, Sadads, Abit, SandraF_WMF, Aklapper, CBogen, Akuckartz, Antti.Kekki, darthmon_wmde, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Cparle, Anooprao, GoranSMilovanovic, Chicocvenancio, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Nikerabbit, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T172175: Make RDF base URIs of media files (geo shapes, tabular data) configurable
Jheald added a project: Commons-Datasets. TASK DETAIL https://phabricator.wikimedia.org/T172175 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: gerritbot, Ladsgroup, PokestarFan, Smalyshev, Jonas, Lokal_Profil, daniel, Aklapper, Lydia_Pintscher, WMDE-leszek, Akuckartz, darthmon_wmde, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Silverfish, debt, Reasno, _jensen, rosalieper, Scott_WUaS, Jheald, mys_721tx, Wikidata-bugs, Base, aude, jayvdb, zhuyifei1999, Yurik, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T230759: Create a service to query Common-hosted tabular data
Jheald added a project: Commons-Datasets. TASK DETAIL https://phabricator.wikimedia.org/T230759 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: mxn, Aklapper, Bugreporter, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Silverfish, debt, Reasno, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, Jheald, mys_721tx, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Yurik, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258625: Querying WCQS should allow me to use prefixes for MediaInfo items
Jheald added a comment. The answer is, we ought to remove them from the RDF dump too, as discussed at T258474 <https://phabricator.wikimedia.org/T258474> It is confusing and distracting to add a whole lot of prefixes that we do not use, and have no intention of using; and distracts from the reality, that SDC introduces very *few* new prefixes, beyond what are already used on WD. TASK DETAIL https://phabricator.wikimedia.org/T258625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Zbyszko, Jheald Cc: Jheald, dcausse, Aklapper, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258474: RDF dumps for Structured Data on Commons are broken
Jheald added a comment. @dcausse It *does* hurt a person who is trying to make sense of the dump, because they will see all these unfamiliar prefixes declared that they may then assume there will be corresponding kinds of predicates or objects that they have to make sense of. Better to remove all the ones that we do not use, to make clearer the specific sdc ones that we do use. TASK DETAIL https://phabricator.wikimedia.org/T258474 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: dcausse, Jheald Cc: Jheald, Aklapper, dcausse, Addshore, Zbyszko, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Pablo-WMDE, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258474: RDF dumps for Structured Data on Commons are broken
Jheald added a comment. Ticket description should be re-written. SDC doesn't have its own properties, so prefixes like `sdcp`, `sdcps` etc are not appropriate and should not appear. (cf discussion at T258625 <https://phabricator.wikimedia.org/T258625>) TASK DETAIL https://phabricator.wikimedia.org/T258474 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: dcausse, Jheald Cc: Jheald, Aklapper, dcausse, Addshore, Zbyszko, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Pablo-WMDE, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258895: Wikimedia Commons Query Service should use Wikimedia url shortener instead of tinyurl
Jheald added a comment. In some ways it's quite nice that WCQS uses tinyurl rather than the w.wiki shortener -- at least it means there is not such a limit on how long the query can be. (T220703 <https://phabricator.wikimedia.org/T220703>). Perhaps we could revert WDQS to use `tinyurl` again, too ? TASK DETAIL https://phabricator.wikimedia.org/T258895 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Lucas_Werkmeister_WMDE, Nintendofan885, Ladsgroup, Aklapper, Gehel, Multichill, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Jonas, Xmlizer, Ixocactus, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, El_Grafo, Dinoguy1000, Manybubbles, Steinsplitter, Mbch331, Rxy, Keegan ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T251497: Adapt munging process for SDoC
Jheald added a comment.
It would be helpful if at least one of the `rdf:type` statements were
retained, as they make it easy to select a subset of M-IDs for a query to work
on
SELECT ...
WITH {
SELECT ?file WHERE {
?file a schema:MediaObject
} LIMIT 5000
} AS %files
...
TASK DETAIL
https://phabricator.wikimedia.org/T251497
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jheald
Cc: Jheald, dcausse, Aklapper, Gehel, Alter-paule, Beast1978, CBogen, Un1tY,
Akuckartz, Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana,
Namenlos314, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan,
Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst,
LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas,
Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258625: Querying WCQS should allow me to use prefixes for MediaInfo items
Jheald added a comment. Most of the above prefixes will be unnecessary, unless we propose to create any new properties local to Commons not defined on Wikidata. If not then `sdcref`, `sdcv`, `sdct`, `sdctn` etc etc will all be unneeded. TASK DETAIL https://phabricator.wikimedia.org/T258625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, dcausse, Aklapper, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258627: Autocompletion for MediaInfo items on WMCS
Jheald added a comment. Given that mediainfo items are just of the form `sdc:M12345`, is much meaningful autocompletion for these actually possible? (Autocompletion for Commons filenames might be a nice touch, though I doubt these would often be specified as literals in queries, as the M-IDs are so much shorter). TASK DETAIL https://phabricator.wikimedia.org/T258627 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, dcausse, Aklapper, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T256617: Make link to entity/concept URI visible in left side menu for all Commons files
Jheald added a comment. It also might be worth making the M-ID number prominently visible on the structured data tab of the filepage, given that this is where the information related to that ID is shown. TASK DETAIL https://phabricator.wikimedia.org/T256617 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, FRomeo_WMF, Spinster, CBogen, Akuckartz, darthmon_wmde, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, JeanFred, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258776: Add Structured Data on Commons M-ID to Wikidata dumps
Jheald added a comment. @Lucas_Werkmeister_WMDE : //I think it would be more feasible to add the Special:FilePath URL to the WikibaseMediaInfo RDF, and combine WDQS and WCQS that way// this has been suggested at T258769 <https://phabricator.wikimedia.org/T258769> TASK DETAIL https://phabricator.wikimedia.org/T258776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lucas_Werkmeister_WMDE, Jheald, Aklapper, Tpt, CBogen, Akuckartz, darthmon_wmde, Nandana, JKSTNK, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258776: Add Structured Data on Commons M-ID to Wikidata dumps
Jheald added a comment. PS. It's also stupidly hard to find the M-ID from a WikiCommons file page at the moment. This would be a good thing to display in the "structured data" tab there, I think. TASK DETAIL https://phabricator.wikimedia.org/T258776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lucas_Werkmeister_WMDE, Jheald, Aklapper, Tpt, CBogen, Akuckartz, darthmon_wmde, Nandana, JKSTNK, Namenlos314, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258776: Add Structured Data on Commons M-ID to Wikidata dumps
Jheald added a comment. I think you meant wd:Q123 wdtn:P18 sdoc:M6919529 in that second line ? TASK DETAIL https://phabricator.wikimedia.org/T258776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, Tpt, CBogen, Akuckartz, darthmon_wmde, Nandana, JKSTNK, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258769: ImageGrid for WCQS
Jheald added a comment. IMO the best solution here would be to add triples of the form sdc:M1234567 ?relation <http://commons.wikimedia.org/wiki/Special:FilePath/Name.jpg> to the database, as well as (or instead of??) the present sdc:M1234567 schema:contentUrl <https://upload.wikimedia.org/wikipedia/commons/5/5b/Name.jpg> The URLs of the first form correspond to the form of the values of Wikidata properties like "image" (`P18`) and the rest, and are what the ImageGrid view looks for to find images in the output. So adding triples of the first form would immediately solve the ImageGrid problem. It would also solve a second issue, viz. that at the moment it is not possible in a query to take the values from wikidata properties like "image" (`P18`) and the rest, and add their Commons info from WCQS, because it is not easily possible at present to relate the URLs of the first form to the M-IDs `M1234567` which are required to connect them to their Commons info. Similarly, if one has generated a list of M-IDs in WCQS, one has to do a workaround at the moment to generate URLs of the first form, if one wants to identify which out of those M-IDs might be the value-objects of wikidata statements Including triples of the form suggested, for some suitable predicate `?relation`, should not be a difficult patch to apply, and would solve both of these issues, as well as allowing ImageGrid view to work straight out of the box. TASK DETAIL https://phabricator.wikimedia.org/T258769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Husky, Rachmat04, Gehel, Aklapper, CBogen, Akuckartz, darthmon_wmde, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T221921: Provision search endpoint for SDC. Requirements from Product Team.
Jheald added a comment. Yes, there's a cost to you of providing a service based on current WDQS, that then has to be ripped out for a new version based on WDQS 2. But consider how little cost that change is for users (since what they interact with will be essentially unchanged - SPARQL for SPARQL, like for like), and consider how much they will be able to do with the endpoint in that time. There is so much that the community could move forwards on now, and this is such a blocker for us. TASK DETAIL https://phabricator.wikimedia.org/T221921 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Gamaliel, Keegan, Jane023, Spinster, Fuzheado, Jarekt, Husky, Tagishsimon, Multichill, Tnegrin, Abbe98, Marsupium, Tpt, Lucas_Werkmeister_WMDE, dcausse, EBernhardson, Jheald, Gehel, Abit, MarkTraceur, Cparle, Ramsey-WMF, Smalyshev, Aklapper, CBogen, darthmon_wmde, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, merbst, LawExplorer, Salgo60, Silverfish, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Jonas, Xmlizer, Susannaanas, Ixocactus, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, Base, matthiasmullie, aude, Tobias1984, El_Grafo, Dinoguy1000, Manybubbles, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T221921: Provision search endpoint for SDC. Requirements from Product Team.
Jheald added a comment. Engineering a completely new search facility for Commons Data rather than using SPARQL is a *stupid* *waste* *of* *time* *and* *resources*. Also it will be very challenging to come up with a solution that can handle trees, and qualifers, and combinations, as well extractin data from Wikidata -- the whole design of SDC rests on items that have their properties in Wikidata statements. Even the most basic search -- show me items with tags that match this *class* of items on Wikidata requires incorporating the information from Wikidata as to what items on Wikidata have that relation `?item wdt:P31 ?class` SPARQL gives you this for free, through federation. It's also a beautifully clear language. We have an outstanding UI for it, ready to go, out of the box. And it's what the entire community knows and uses on a daily basis, so there'd be no muddle between two systems. WDQS handles upwards of 5 million queries a day. In contrast CQS is going to be used by a handful of power users, that desperately need it to iteratively evolve and develop the data-modelling -- which doesn't happen at the moment, and has stalled the entire project, because at the moment we are completely blind, because we have no CQS. That's why need for CQS is *critical*, but even so it may only have a few tens of tens of users. The query-load problems WDQS faces *simply* *do* *not* *apply*. CQS is not a system for end-users. It's not what is going to power end-user applications. It does not face the same capacity issues. The updating bottleneck issue is *not* an prority issue for CQS. But CQS is *critically* needed for the community to be able to see what they are doing, to grow the data model, and to prototype the sort of cool searches and refinements to show off what the data is capable of. See also comments building up in thread at https://commons.wikimedia.org/wiki/Commons_talk:Structured_data#On_SPARQL Multichill calls it exactly right: //Not providing the promised SPARQL endpoint for Structured data on Commons is effectively pulling the plug on the whole thing. // Do none of you have a fucking clue about this project ? We needed CQS last year, not this year. It's *far* more important than anything in the GUI. It is an absolute critical priority. If you can't deliver, then hand the ticket back to WMDE and pay them to do it. TASK DETAIL https://phabricator.wikimedia.org/T221921 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Spinster, Fuzheado, Jarekt, Husky, Tagishsimon, Multichill, Tnegrin, Abbe98, Marsupium, Tpt, Lucas_Werkmeister_WMDE, dcausse, EBernhardson, Jheald, Gehel, Abit, MarkTraceur, Cparle, Ramsey-WMF, Smalyshev, Aklapper, Nuria, CBogen, darthmon_wmde, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, merbst, LawExplorer, Salgo60, Silverfish, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Jonas, Xmlizer, Susannaanas, Ixocactus, Wong128hk, Jane023, jkroll, Wikidata-bugs, Jdouglas, Base, matthiasmullie, aude, Tobias1984, El_Grafo, Dinoguy1000, Manybubbles, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Keegan ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. That's a bit of a problem, given what the badges are for... TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ItamarWMDE, Jheald Cc: Ladsgroup, Gamaliel, Fuzheado, ItamarWMDE, JAnD, Hsarrazin, deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. I tried to add an "intentional sitelink to redirect" badge on the English sitelink for asteroid 6765 Fibonacci <https://www.wikidata.org/wiki/Q568417>, but got "Could not save due to an error. The save has failed." Is there something else that needs to be enabled, and/or does it need special permissions to be able to add such badges? TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ItamarWMDE, Jheald Cc: Ladsgroup, Gamaliel, Fuzheado, ItamarWMDE, JAnD, Hsarrazin, deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T246238: Investigate common qualifiers for “unknown value” statement main snaks
Jheald added a comment. regarding editors : it looks like some works have multiple editors, none of which have Wikidata items. These ought to be given in separate statements distinguished by "series ordinal". But it may be that because the statements both have the same 'main value' (or, rather, they both have `somevalue` for the main value), the software used to add the statements may have coalesced them together. QuickStatements tends to do this, I think. Note that "some value" is a reasonable UI string to stand for "some value, but the value is not known". But "unknown value" is not a good UI string to indicate "some value, which is known, but hasn't been matched to a Wikidata item". TASK DETAIL https://phabricator.wikimedia.org/T246238 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JAllemandou, Jheald Cc: elukey, JAllemandou, Lea_Lacroix_WMDE, Gehel, Aklapper, dcausse, Igorkim78, Lucas_Werkmeister_WMDE, Jheald, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T246238: Investigate common qualifiers for “unknown value” statement main snaks
Jheald added a comment. - "named as" = name given to the subject of the statement - "stated as" = how the object of the statement was stated TASK DETAIL https://phabricator.wikimedia.org/T246238 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JAllemandou, Jheald Cc: elukey, JAllemandou, Lea_Lacroix_WMDE, Gehel, Aklapper, dcausse, Igorkim78, Lucas_Werkmeister_WMDE, Jheald, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T244341: Wikibase RDF dump: stop using blank nodes for encoding SomeValue and OWL constraints
Jheald added a comment. @Lucas_Werkmeister_WMDE The qualifier "stated as" (`p1932`) is currently used on 6.6 million statements. I couldn't get a query to complete to count how many of those statements have an object that's a blank node. My guess might be on the order of about 10,000 but that's just a number pulled out of the air, not based on anything. Could be a *lot* more, if this mechanism has been used eg for scientific papers with unmatched editors, publishers, etc. (Maybe it will be easier to count under a new approach?) The number of cases of “we know the value but can’t represent it” may soon be much bigger on Commons though, where the pattern is being used as part of an idiom for creators that don't have a Wikidata item, but are known -- including creators known only by their wiki user-names. The number of those cases -- eg self-taken pictures, self-made diagrams etc -- would probably go into the millions, once it's systematically applied. TASK DETAIL https://phabricator.wikimedia.org/T244341 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Daniel_Mietchen, mkroetzsch, Denny, Lucas_Werkmeister_WMDE, Aklapper, dcausse, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T244341: Wikibase RDF dump: stop using blank nodes for encoding unknown values and OWL constraints
Jheald added a comment. Example of a Listeria tracking page, counting how many blank nodes are being used this way for the properties used on a particular set of items (in this case: a particular set of books, where the publisher (known) may not yet have an item, or at least not yet a matched item): https://www.wikidata.org/wiki/Wikidata:WikiProject_BL19C/titles_stmts Yes, at the end of the day it's just using FILTER(isBlank(?stmt_value)) . and counting statements, so any of the routes above would work. But please let's call them "blank values" rather than "unknown values", with functions called `wikibase:isBlankValue()` or `wikibase:isSomeValue()` rather than `wikibase:isUnknownValue()`. Thanks! TASK DETAIL https://phabricator.wikimedia.org/T244341 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Daniel_Mietchen, mkroetzsch, Denny, Lucas_Werkmeister_WMDE, Aklapper, dcausse, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T244341: Wikibase RDF dump: stop using blank nodes for encoding unknown values and OWL constraints
Jheald added a comment. Please don't think or refer to the blank nodes as "unknown values". The term used by the wikibase software is "somevalue". The blank nodes are now most commonly used where the information *is* known, but does not have a wikidata item. This is represented by giving the statement the magic "somevalue" status, plus adding a `P1932` "stated as" qualifier to give the (known) information as a text string. The fact that the UI reports the value as "unknown" is already a menace, an undesirable misrepresentation of how the value is being used. Please don't compound this by letting the characters "unk" or "unknown" anywhere near the RDF data model and the sparql interface. TASK DETAIL https://phabricator.wikimedia.org/T244341 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Daniel_Mietchen, mkroetzsch, Denny, Lucas_Werkmeister_WMDE, Aklapper, dcausse, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T240093: On Commons create optional "skin" for displaying structured data which mimics Wikidata look
Jheald added a comment. Lead ticket for Vue migration for Wikidata would appear to be T157014 <https://phabricator.wikimedia.org/T157014> . After sustained activity in 2017, followed by a short spike in June-July 2018, it's not clear how much further progress has been made, or is currently anticipated on this. There is a mention that the Lexemes roll-out in 2018 included some Vue templates and widgets with PHP server-side rendering, which was going to be reviewed. There's also mention at the top of that ticket that: "State management and data/event propagation goes beyond of what OOUI can provide". If so, it's not clear why that wouldn't be a problem fo SDC too; or alternatively if it is not a problem for SDC, why it should be a problem for Wikibase. It does seem rather odd to have two different teams working on two different interfaces, with utterly different implementations, for what is essentially the same functionality against the same backend. From the outside it's hard to understand the fork as creating other thanextra work and extra delay now (cf T239172 <https://phabricator.wikimedia.org/T239172> "somevalue", T233036 <https://phabricator.wikimedia.org/T233036> (statements for most types of properties), deprecation, referencing, T230314 <https://phabricator.wikimedia.org/T230314> constraint checking, etc, etc etc); plus extra duplicated maintenance cost and implementation cost of any additional features gadgets and extensions going forward. TASK DETAIL https://phabricator.wikimedia.org/T240093 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Jdforrester-WMF, Alicia_Fagerving_WMSE, Pigsonthewing, Aklapper, Keegan, Marsupium, Jheald, Jarekt, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238751: Only generate maxlag from pooled query service servers.
Jheald added a comment. If `maxlag` is to be based on the maximum lag of the pooled servers, will there be active measures to monitor these, and take any really badly lagged server (ie significantly worse lagged than any of the others) out of the pool, and out of the maxlag calculation, to give it a chance to recover ? Otherwise I worry that our availability for upload could be crippled, whenever one of the servers gets into difficulties. TASK DETAIL https://phabricator.wikimedia.org/T238751 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, Jheald Cc: Jheald, Joe, Addshore, Aklapper, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, Iflorez, darthmon_wmde, alaa_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238229: WDQS is having high update lag for the last week
Jheald added a comment. One thing that seems odd (to an outsider like me who knows very little about the system) is that some servers seem to be performing so much worse than others. Is there a simple reason for this (eg an entire cluster having problems?), or does this suggest there may also be issues with load-balancing, of which servers pick up which queries? TASK DETAIL https://phabricator.wikimedia.org/T238229 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Fnielsen, Mahir256, Gehel, Aklapper, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T230314: Show constraint violations on SDC statements
Jheald added a subscriber: Lucas_Werkmeister_WMDE. Jheald added a comment. @Lucas_Werkmeister_WMDE How dependent is the wikibase constraint system on SPARQL ? Maarten was just suggesting that a functioning SPARQL service is required for //any// of the constraint checking to operate (and so this ticket would be completely blocked until CDQS is reliably up and running) Is that correct? Or are any of the simplest of the constraint checks (eg format constraints, one-of constraints, etc) available without SPARQL ? TASK DETAIL https://phabricator.wikimedia.org/T230314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lucas_Werkmeister_WMDE, Multichill, Jheald, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T230314: Show constraint violations on SDC statements
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T230314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Jheald, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T236611: Move "cool queries" on the Wikidata Query Service to a new second button
Jheald renamed this task from "Add a second button to the Query Service for "cool queries"" to " Move "cool queries" on the Wikidata Query Service to a new second button ". TASK DETAIL https://phabricator.wikimedia.org/T236611 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, LucasWerkmeister, Harmonia_Amanda, reosarevok, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T236611: Add a second button to the Query Service for "cool queries"
Jheald added a comment. I very strongly agree with this ticket. It needs to be as easy as possible for query-service users to find queries that illustrate "how do I do this?" A very long time ago, I created this page <https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries> of SPARQL query examples. Since that time, many introductions to SPARQL that are //far// better have been written. Also, the style of the example queries on that page is often not good (more meaningful variable names would be better, etc); some of the queries could be better written, or may no longer even work due to time-outs now that Wikidata is so much bigger; some of the pages aren't inline on the page, which they should be; some of the most important topics are missing; and, most seriously, too many of the queries are frankly dull - far more interesting (less maintenance orientated) examples could be chosen. So it's not a great page, and could be hugely improved (and extended -- eg more illustrative queries for using the API, doing federation, combining with category data, drawing on maps, etc, etc, etc) But I do think the // format // of the page is useful, presenting queries to illustrate SPARQL / WDQS feature by feature. Indeed I have a bookmark to it in my browser bar, and regularly go back to it, whenever I need to remember how to do something that's not in the every day. So I do think an updated new page in this form (perhaps expanding to a series of pages, for additional further advanced features) would be extremely useful; and, once created, would be something very helpful to make as accessible as possible. TASK DETAIL https://phabricator.wikimedia.org/T236611 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, Aklapper, LucasWerkmeister, Harmonia_Amanda, reosarevok, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T236612: (Duplicate) Show constraint violations on SDC statements
Jheald renamed this task from "Show constraint violations on SDC statements" to "(Duplicate) Show constraint violations on SDC statements". TASK DETAIL https://phabricator.wikimedia.org/T236612 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T230314: Show constraint violations on SDC statements
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T230314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Jheald, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T230314: Show constraint violations on SDC statements
Jheald added a comment. Example case to show why this is urgently needed: The property source of file (P7482) <https://www.wikidata.org/wiki/Property:P7482> is intended to show the broad nature of the origin of a file. In the property proposal discussion, it was agreed that this could be rolled out widely now for the simplest case, namely images we can reliably trust to be a user's own personal creation and own direct upload (eg a user's own photo of a monument they have taken and uploaded in the Wiki Loves Monuments campaign), but that for the moment uses in more complicated cases should be restricted until there has been more community discussion and sign-off, to make sure we know how we want to model such cases, before people start applying the property more widely. This is reflected in the following constraint specification on P7482 (see revision as of 2019-10-27 <https://www.wikidata.org/w/index.php?title=Property:P7482=1039646764#P2302>) : - property constraint (P2302) <https://www.wikidata.org/wiki/Property:P2302> = one-of constraint (Q21510859) <https://www.wikidata.org/wiki/Q21510859> - item of property constraint (P2305) <https://www.wikidata.org/wiki/Property:P2305> = original creation by uploader (Q66458942) <https://www.wikidata.org/wiki/Q66458942> // -- list of allowed values : initially this is the only approved value // - constraint status (P2302) <https://www.wikidata.org/wiki/Property:P2316> = suggestion constraint (Q62026391) <https://www.wikidata.org/wiki/Q62026391> // -- show a flag warning if the above constraint is not met on a statement involving this property P7482, rather than the more serious exclamation mark warning // - constraint clarification (P6607) <https://www.wikidata.org/wiki/Property:P6607> = "only agreed values should be used, other than on test images being considered in discussion environments" // -- explanatory message to show, if a constraint violation is flagged. Localised messages may exist for multiple languages. // It is urgent that warning flagging is put in place soon, before people start seeing P7482 "source of file" statements starting widely to appear images, and begin supplying their own new values, other than what is so-far the only community-approved value, Q66458942 "original creation by uploader". If SDC is to develop in an orderly way, visible flagging of non-conformant (or not yet generally consented to) statements is really needed. TASK DETAIL https://phabricator.wikimedia.org/T230314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Jheald, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T230314: Show constraint violations on SDC statements
Jheald renamed this task from "Checking constraints for MediaInfo entities" to "Show constraint violations on SDC statements". TASK DETAIL https://phabricator.wikimedia.org/T230314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Multichill, Jheald, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T236612: Show constraint violations on SDC statements
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T236612 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T236612: Show constraint violations on SDC statements
Jheald added a comment. Example: property source of file (P7482) <https://www.wikidata.org/wiki/Property:P7482> is intended to show the broad nature of the origin of a file. In the property proposal discussion, it was agreed that this could be rolled out widely now for the simplest case, namely images we can reliably trust to be a user's own personal creation and own direct upload (eg a user's own photo of a monument they have taken and uploaded in the Wiki Loves Monuments campaign), but that for the moment uses in more complicated cases should be restricted until there has been more community discussion and sign-off, to make sure we know how we want to model such cases, before people start applying the property more widely. This is reflected in the following constraint specification on P7482 (see revision as of 2019-10-27 <https://www.wikidata.org/w/index.php?title=Property:P7482=1039646764#P2302>) : - property constraint (P2302) <https://www.wikidata.org/wiki/Property:P2302> = one-of constraint (Q21510859) <https://www.wikidata.org/wiki/Q21510859> - item of property constraint (P2305) <https://www.wikidata.org/wiki/Property:P2305> = original creation by uploader (Q66458942) <https://www.wikidata.org/wiki/Q66458942> // -- list of allowed values : initially this is the only approved value // - constraint status (P2302) <https://www.wikidata.org/wiki/Property:P2316> = suggestion constraint (Q62026391) <https://www.wikidata.org/wiki/Q62026391> // -- show a flag warning if the above constraint is not met on a statement involving this property P7482, rather than the more serious exclamation mark warning // - constraint clarification (P6607) <https://www.wikidata.org/wiki/Property:P6607> = "only agreed values should be used, other than on test images being considered in discussion environments" // -- explanatory message to show, if a constraint violation is flagged. Localised messages may exist for multiple languages. // It is urgent that warning flagging is put in place soon, before people start seeing P7482 "source of file" statements starting widely to appear images, and begin supplying their own new values, other than what is so-far the only community-approved value, Q66458942 "original creation by uploader". If SDC is to develop in an orderly way, visible flagging of non-conformant (or not yet generally consented to) statements is really needed. TASK DETAIL https://phabricator.wikimedia.org/T236612 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T236612: Show constraint violations on SDC statements
Jheald created this task. Jheald added a project: SDC General. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION We need to flag to users if there are constraint violations in SDC statements. On Wikidata, users are shown - a flag icon to warn if a statement fails a constraint requirement identified as having constraint status (P2302) <https://www.wikidata.org/wiki/Property:P2302> = suggestion constraint (Q62026391) <https://www.wikidata.org/wiki/Q62026391>, and - an exclamation mark icon if a statement fails a constraint requirement identified as having constraint status (P2302) <https://www.wikidata.org/wiki/Property:P2302> = mandatory constraint (Q21502408) <https://www.wikidata.org/wiki/Q21502408>, Additionally, an explanatory message can be specified to show with the warning icon, via constraint clarification (P6607) <https://www.wikidata.org/wiki/Property:P6607> It is important for such warnings to become visible, and soon, to flag up immediately to users that particular patterns of usage are inappropriate, or have not yet been agreed by the community. This is particularly urgent now that we are on the brink of a vast number of more properties becoming available and going into mass usage on Commons SDC. Example in comment 1. TASK DETAIL https://phabricator.wikimedia.org/T236612 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. @Lydia_Pintscher - Having now kicked a few possibilities around on Project Chat, can we go for creating badges with: - the name `sitelink to redirect` and the icon File:Symbol_redirect_arrow_grey.svg <https://commons.wikimedia.org/wiki/File:Symbol_redirect_arrow_grey.svg> for regular sitelinks to redirects (Q70893996 <https://www.wikidata.org/wiki/Q70893996>) - the name `intentional sitelink to redirect` and the icon File:Symbol_redirect_arrow_blue.svg <https://commons.wikimedia.org/wiki/File:Symbol_redirect_arrow_blue.svg> for "intentional" sitelinks to redirects (Q70894304 <https://www.wikidata.org/wiki/Q70894304>) As MisterSynergy said at Project Chat, if people want a change once they see how they look, that's easy enough later. But these look good for the time being. Presumably the system already knows what size to scale the SVGs to for display -- at Project Chat I have been testing what they look like at 20px tall for the links on the wikidata item page, and 10px tall for the links in the sidebars of Wikipedia articles. Different scalings might be needed for screens with more pixels per inch, but as SVG is already used for the wikisource badges, I presume that's all coded in already. Thanks for making this a reality. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a subscriber: deryckchan. Jheald added a comment. There is some sense in what MisterSynergy says, but I also think there is sense in what @DeryckChan wrote in the RfC (here <https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Allow_the_creation_of_links_to_redirects_in_Wikidata#Neutral>), namely that there still ought to be some warning if someone tries to sitelink to a redirect page, and the user should be made to actively confirm that they didn't want to instead link to the redirect target. Otherwise I could see us ending up with a lot of accidental sitelinks to mis-spellings, which the present system mostly keeps us safe from. For the most part the present workaround methods to allow a sitelink to be created to a redirect seem to mostly work acceptably enough (once a user knows about them). I can see that they may make life more difficult for large-scale programmatic addition of sitelinks to redirects; but for the moment let's get the badges in place first, so the community becomes much more aware of the existing sitelinks to redirects; then when that's in place we can come back to the question of whether it should be made easier to create new ones. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. Thanks Lydia. I've started a thread at Wikidata:Project_chat#Badges_for_sitelinks_to_redirects <https://www.wikidata.org/wiki/Wikidata:Project_chat#Badges_for_sitelinks_to_redirects> to quickly see if there are particular icons people would prefer. At the moment, I'm thinking perhaps File:Symbol redirect arrow blue.svg <https://commons.wikimedia.org/wiki/File:Symbol_redirect_arrow_blue.svg> for the links in Wikipedia sidebars, and either File:Symbol_redirect_blue.svg <https://commons.wikimedia.org/wiki/File:Symbol_redirect_blue.svg> or File:Symbol_redirect_blue.svg <https://commons.wikimedia.org/wiki/File:Symbol_redirect_vote_blue.svg> on the Wikidata item pages, in blue for redirects identified as "intentional", or in grey where this is not so clear. But people may come up with better suggestions. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. The badges, and corresponding bot, might be a nice quick win for Wikidata's 7th birthday. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald added a comment. Background: Mostly, the existence of a sitelink to a redirect indicates a potential //data problem// on Wikidata: a sitelink that has been left over when two Wikipedia articles have been merged, but no corresponding merge has been made on Wikidata. A sitelink to a redirect can therefore be a strong indication that an item on Wikidata is a duplicate of another one, and should be merged with it. However, at the moment it is not possible for somebody browsing a Wikidata article to readily spot that a sitelink points to a redirect. A badge to identify this would bring the fact into plain sight. On the other hand sitelinks to redirects may also (sometimes) be created intentionally, most commonly to preserve decent interwiki linkage when different Wikipedias have adopted different article strategies for a subject with a "Bonnie and Clyde" issue. At present eleven wikipedias allow such intentionally sitelinked redirects to be marked with a Template:Wikidata redirect <https://www.wikidata.org/wiki/Q16956589> template. On English Wikipedia this currently has almost 26,000 transclusions. A community RfC on Wikidata <https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Allow_the_creation_of_links_to_redirects_in_Wikidata> in 2017-2018 confirmed that there was community consensus to allow sitelinks to be added to redirects in this way, matching the results of an earlier RfC in 2013 <https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/A_need_for_a_resolution_regarding_article_moves_and_redirects#new_Proposal_zero>. Both the Wikidata Help:Handling sitelinks overlapping multiple items <https://www.wikidata.org/wiki/Help:Handling_sitelinks_overlapping_multiple_items> help page and the Wikidata:Notability <https://www.wikidata.org/wiki/Wikidata:Notability> policy page give advice on how such sitelinks to redirects may be created. Nevertheless, a strong theme in the most recent RfC <https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Allow_the_creation_of_links_to_redirects_in_Wikidata> was that such redirects need to be much more clearly visible and distinguishable. Creating two new Wikidata badges, one to mark a sitelink to a redirect, and a second to mark an //intentional// sitelink to a redirect, would be the obvious (and comparatively easy) way to achieve this. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
Jheald created this task. Jheald added a project: Wikidata. Restricted Application added subscribers: Liuxinyu970226, Aklapper. TASK DESCRIPTION As a Wikidata editor, - I would like to be able to see when a sitelink is pointing to a redirect page on the Wikipedia. - I would like to be able to distinguish an //intentional// sitelink to a redirect (marked by Template:Wikidata redirect <https://www.wikidata.org/wiki/Q16956589> on the Wikipedia - in WDQS queries I would like to be able to identify sitelinks that point to redirects rather than full articles, when assessing the coverage of a topic As a Wikipedia reader, - I would like a subtle indication if a sidebar sitelink will be taking me to an article on a related subject (via a redirect), rather than a strictly parallel article This can be achieved rather simply, by creating two new Wikidata badges, one to indicate a sitelink to a redirect, a second to indicate an //intentional// sitelink to a redirect. The badges could be maintained and kept updated by a community bot regularly (daily?) running an SQL query to identify sitelinks to redirects (with and without the template), and comparing it with a SPARQL query to identify the sitelinks on Wikidata with badges TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T235332: Add SDC data slot to pages in the Commons data: namespace
Jheald updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T235332 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, debt, Reasno, _jensen, rosalieper, JGirault, phabyogi, Susannaanas, lxbarth, mys_721tx, Jane023, Planemad, Wikidata-bugs, Base, matthiasmullie, aude, jayvdb, Ricordisamoa, Wesalius, zhuyifei1999, Lydia_Pintscher, Fabrice_Florin, Yurik, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T235332: Add SDC data slot to pages in the Commons data: namespace
Jheald added a parent task: T155290: Add a data-page-only wiki markup header to datasets. TASK DETAIL https://phabricator.wikimedia.org/T235332 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, debt, Reasno, _jensen, rosalieper, JGirault, phabyogi, Susannaanas, lxbarth, mys_721tx, Jane023, Planemad, Wikidata-bugs, Base, matthiasmullie, aude, jayvdb, Ricordisamoa, Wesalius, zhuyifei1999, Lydia_Pintscher, Fabrice_Florin, Yurik, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T235332: Add SDC data slot to pages in the Commons data: namespace
Jheald added a comment. For discoverability, maintenance, and reuse, it is as important to be able to store metadata for datasets in SDC as it is to be able to store metadata for images. Pages in the Data: namespace on Commons, used for tabular data and for map data, should therefore have an SDC slot in just the same way as pages in the File: namespace. It may also be advantageous to create a slot for a regular wikitext file description page at the same time, a long-standing request (T155290 <https://phabricator.wikimedia.org/T155290>) TASK DETAIL https://phabricator.wikimedia.org/T235332 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, debt, Reasno, _jensen, rosalieper, JGirault, phabyogi, Susannaanas, lxbarth, mys_721tx, Jane023, Planemad, Wikidata-bugs, Base, matthiasmullie, aude, jayvdb, Ricordisamoa, Wesalius, zhuyifei1999, Lydia_Pintscher, Fabrice_Florin, Yurik, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T235332: Add SDC data slot to pages in the Commons data: namespace
Jheald created this task. Jheald added projects: SDC General, Maps, Commons-Datasets. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION As a user, I want to be able to - Describe the metadata (including source, licensing, nature of content, etc, etc) of datasets using Commons structured data, referencing Wikidata items - Be able to discover it and query aspects of it using the SDC query service. TASK DETAIL https://phabricator.wikimedia.org/T235332 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Aklapper, Jheald, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, debt, Reasno, _jensen, rosalieper, JGirault, phabyogi, Susannaanas, lxbarth, mys_721tx, Jane023, Planemad, Wikidata-bugs, Base, matthiasmullie, aude, jayvdb, Ricordisamoa, Wesalius, zhuyifei1999, Lydia_Pintscher, Fabrice_Florin, Yurik, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T233520: page_props missing links for some Commons category <-> Wikidata sitelinks
Jheald renamed this task from "page_props missing for some Commons categories" to "page_props missing links for some Commons category <-> Wikidata sitelinks". TASK DETAIL https://phabricator.wikimedia.org/T233520 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Lydia_Pintscher, Lucas_Werkmeister_WMDE, Jheald, Aklapper, Mike_Peel, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Jonas, Ixocactus, Wong128hk, Wikidata-bugs, aude, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331, Keegan ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T215073: OSM map layers other than the default should be displayable in the Wikidata Query Service
Jheald added a comment. On a separate but related issue: we now have quite a lot of images of old maps on Commons, with coordinate georeferencing allowing the maps to be "warped" to standard coordinate systems. It would be nice to be able to serve the warped versions of the maps as tilesets, allowing users to compare different historical representations of given places as layers. This would be a huge boost for the WikiMaps group that has been working with historical maps, and a service of considerable value towards a world where people can freely share in the sum of historical knowledge about their location. TASK DETAIL https://phabricator.wikimedia.org/T215073 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jheald Cc: Jheald, agray, Pigsonthewing, Tagishsimon, Addshore, gerritbot, Pnorman, Yurik, Smalyshev, Lydia_Pintscher, TerraCodes, Mholloway, Liuxinyu970226, Jim_Carter, KCVelaga, Aklapper, Titodutta, Mahir256, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, Looniverse, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Orienteerix, merbst, LawExplorer, Salgo60, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, JGirault, Jonas, phabyogi, Xmlizer, Susannaanas, lxbarth, jkroll, Planemad, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227036: Wikimania Hackathon 2019 proposal: metadata standard for map georectification
Jheald added a comment. To link the original file to these objects, three new SDC properties are proposed: - georeferencing control point data <https://www.wikidata.org/wiki/Wikidata:Property_proposal/georeferencing_data#georeferencing_control_point_data> - georeferencing pixel mask data <https://www.wikidata.org/wiki/Wikidata:Property_proposal/georeferencing_data#georeferencing_pixel_mask_data> - georeferencing mask geoshape <https://www.wikidata.org/wiki/Wikidata:Property_proposal/georeferencing_data#georeferencing_mask_geoshape> Due to the limitations inherent in the Wikibase statement structure (in particular, the limit of a single level of qualifiers), and the wish to potentially add qualifiers to these statements, eg relating them to a particular file revison, or to add information to distinguish between different live variant versions of the files, the most straightforward approach would seem for these to stand as independent full statements, related to a particular part of the image using qualifier `P518` "applies to part". Additionally a new proposed qualifier "based on tabular data" (proposal <https://www.wikidata.org/wiki/Wikidata:Property_proposal/based_on_tabular_data>) would link the mask geoshape statement to the particular files with the tabular data (out of many that might be associated with the image) used to generate it. SDC property proposals and space for discussion at: https://www.wikidata.org/wiki/Wikidata:Property_proposal/georeferencing_data TASK DETAIL https://phabricator.wikimedia.org/T227036 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bert, Jheald Cc: thisismattmiller, matthiasmullie, Jheald, Orienteerix, Abbe98, SandraF_WMF, Susannaanas, Aklapper, bert, darthmon_wmde, Ferenczy, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Morgankevinj, Omar_sansi, Jane023, Wikidata-bugs, Base, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T227036: Wikimania Hackathon 2019 proposal: metadata standard for map georectification
Jheald added a subscriber: thisismattmiller. Jheald added a comment. Quick update for those following from home. @bert and others have been going gangbusters pushing this forward, and (I think) it's starting to look really good. A first design was to try to package all the georefencing information in a singe Commons geoshape object, for example this revision <https://commons.wikimedia.org/w/index.php?title=Data:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.mask.map=362173957> This was impressive, but it was a bit of a nasty hack, and packaging all of the data up to look like a geoshape creates a data-structure that's pretty unnatural and not immediately inuitive. So a better and more straightforward approach seems to be to create three different objects in the Commons data namespace for each georectification: - A tabular data file containing the georeferencing control points <https://commons.wikimedia.org/wiki/Data:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.gcps.tab> - A tabular data file containing the pixel coordinates of the boundary of the georeferenced area <https://commons.wikimedia.org/wiki/Data:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.mask.tab> (the map mask) - A geoshape file representing the mask in latitude and longitude coordinates <https://commons.wikimedia.org/wiki/Data:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.mask.map> It's now hoped to develop a micro-service that can read these objects and serve a Tiled Map Service (TMS) layer containing the georectified map, with caching for responsiveness. In parallel to this, great progress has been made developing importers to bring in data where there is existing georeferencing for Commons maps on external sites. It should now be possible to import from Commons MapWarper, NYPL MapWarper, BL Georeferencer (Klokan v2), and the David Rumsey collection (Klokan v4). Special MVP award to @thisismattmiller for some of this. Now is a good moment for discussion / consideration / review, but I have to say, myself, I am blown away by how much and how quickly in the last 48 hours people have managed to achieve on this. TASK DETAIL https://phabricator.wikimedia.org/T227036 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bert, Jheald Cc: thisismattmiller, matthiasmullie, Jheald, Orienteerix, Abbe98, SandraF_WMF, Susannaanas, Aklapper, bert, darthmon_wmde, Ferenczy, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Morgankevinj, Jane023, Wikidata-bugs, Base, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227036: Wikimania Hackathon 2019 proposal: metadata standard for map georectification
Jheald added a comment. Resource page (under development): https://commons.wikimedia.org/wiki/User:Bertspaan/maps TASK DETAIL https://phabricator.wikimedia.org/T227036 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bert, Jheald Cc: matthiasmullie, Jheald, Orienteerix, Abbe98, SandraF_WMF, Susannaanas, Aklapper, bert, darthmon_wmde, Ferenczy, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Morgankevinj, Jane023, Wikidata-bugs, Base, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227036: Wikimania Hackathon 2019 proposal: metadata standard for map georectification
Jheald added a comment. By the way, I have a Wikidata property proposal suggested for external georeferencer URL <https://www.wikidata.org/wiki/Wikidata:Property_proposal/external_georeferencer_URL>, since a basic thing we will want to record is whether an external service has georeferencing for an image, and if so what the relevant URL is. The proposal has been up a couple of weeks, but so far hasn't attracted any discussion. TASK DETAIL https://phabricator.wikimedia.org/T227036 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bert, Jheald Cc: matthiasmullie, Jheald, Orienteerix, Abbe98, SandraF_WMF, Susannaanas, Aklapper, bert, darthmon_wmde, Ferenczy, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Morgankevinj, Jane023, Wikidata-bugs, Base, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227036: Wikimania Hackathon 2019 proposal: metadata standard for map georectification
Jheald added a comment. @bert I'll be there; I'm coming in on the Tuesday afternoon flight from Edinburgh, and then I'll be at the Comfort Hotel Xpress Stockholm Central. My focus so far has been trying to identify good Commons categories for maps based on bounding boxes for the georeferencing. I've now got reasonable code to do that for the UK & Ireland -- see the pages here <https://commons.wikimedia.org/wiki/Category:MC_upload_prep_pages> for preparations, and hoping to get some uploading going soon. The rest of the world <https://commons.wikimedia.org/wiki/Category:MC_map_identification-in-progress> outside the UK is more work-in-progress, and I could use some input from people with local knowledge to try to achieve appropriate similar refinement. I am or will be doing Wikidata matching for all the fields I can, but initially with a view to writing to Wikidata-driven field templates in conventional file description pages, rather than SDC statements. These should be easy enough to translate into matching SDC statements when the time comes, but at the moment my intention would be to wait until QuickStatements is available for bulk writing of statements, and a SPARQL service for systematic retrieval, before any systematic creation of SDC statements. I am interested by IIIF, but don't know enough about it. Later versions of the Klokan georeferencer use IIIF for all their tile serving (ie including maps layers and the image to be georeferenced). The GLAM I am working with would very much like to move from its images from Klokan's IIIF service to an IIIF service provided by WikiCommons, and use that to feed the Klokan georeferencer; but that would need enterprise-level throughput robustness and reliability, which the present WMF Labs prototype just doesn't deliver. There are some indications that a proper IIIF service might be provided by an upcoming revision of the Wiki Multimedia service, but at the moment no hard timeline or guarantees. The other aspect of IIIF would be how to expose georeferencing information as IIIF annotations. I really know *very* little about the IIIF annotation syntax, other than that it exists. But if this looked plausible (and could be made compatible with offerings from other services, eg Klokan and Recogito, it could be quite interesting. TASK DETAIL https://phabricator.wikimedia.org/T227036 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bert, Jheald Cc: matthiasmullie, Jheald, Orienteerix, Abbe98, SandraF_WMF, Susannaanas, Aklapper, bert, darthmon_wmde, Ferenczy, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Morgankevinj, Jane023, Wikidata-bugs, Base, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
