[Wikidata-bugs] [Maniphest] T362305: Add monolingual language code "ko-kr" → Korean (South Korea)
TomT0m added a comment. The IETF code seems to be (see https://www.wikidata.org/wiki/Q18795#P305 ) "ko-KR", with capital KR. TASK DETAIL https://phabricator.wikimedia.org/T362305 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: TomT0m, Aklapper, revi, Koreller, Danny_Benjafield_WMDE, S8321414, mrephabricator, Astuthiodit_1, MaryMunyoki, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, srishakatux, KimKelting, Esc3300, LawExplorer, _jensen, rosalieper, Scott_WUaS, Nikki, Wikidata-bugs, aude, Nemo_bis, Raymond, Arrbee, KartikMistry, 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] T355427: Pretty print for link to projects in Wikidata Query UI results
TomT0m added a comment. It would actually make sense to add prefix like "commons:" into the default prefix. I have also used the technique to define a prefix like "fr: https://fr.wikipedia.org/ when manually wrinting stuff like "?article schema:isPartOf fr:" and that actually works. This does not however with ":w:fr" unfortunately. TASK DETAIL https://phabricator.wikimedia.org/T355427 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Nikki, Lucas_Werkmeister_WMDE, Aklapper, TomT0m, Danny_Benjafield_WMDE, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, EBjune, KimKelting, 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] T355427: Pretty print for link to projects in Wikidata Query UI results
TomT0m added a comment. The ambiguity could be solved by using the standard wikimedia prefixes "w:en:Victor Hugo", this works as a wikilink. A bit obscure for a lot of course, but … An icon as for commons could help, a tooltip too. TASK DETAIL https://phabricator.wikimedia.org/T355427 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Lucas_Werkmeister_WMDE, Aklapper, TomT0m, AWesterinen, Namenlos314, Gq86, Mahir256, EBjune, KimKelting, 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] T355427: Pretty print for link to projects in Wikidata Query UI results
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T355427 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, TomT0m, AWesterinen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, Mahir256, EBjune, KimKelting, 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] T355427: Pretty print for link to projects in Wikidata Query UI results
TomT0m created this task. TomT0m added a project: Wikidata Query UI. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **Feature summary** (what you would like to be able to do and where): For Wikimedia commons images, when seen in table format query result or other, a link to the image is displayed as ":commons:…". It could be great to have the same kind of features to better display links to projects such as "en:Victor Hugo" as compared to https://en.wikipedia.org/wiki/Victor_Hugo that it is now. Alternatively, or as another option, the query service should provide a way to compute a label, which could be displayed as a HTML link "https://en.wikipedia.org/wiki/Victor_Hugo;>?articleLabel" where ?articleLabel is the variable name of the computed value **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): When Wikidata query is used to display results about a wikiproject, for a replacement of categories. The full link url are not very pretty and do not give an idea of the title of the link. **Benefits** (why should this be implemented?): It would provide better looking results for users, increasing the probability that Wikidata is considered an alternative to the Category system when relevant. It would also save space while displaying results by avoiding text redundancy in the results, while allowing user to easily go back to their home wiki. TASK DETAIL https://phabricator.wikimedia.org/T355427 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, TomT0m, AWesterinen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, Mahir256, EBjune, KimKelting, 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] T327601: Templatized WDQS scope does not really work. Propose fix : use a prefix instead of a bind.
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T327601 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, TomT0m, Astuthiodit_1, AWesterinen, 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] T327601: Templatized WDQS scope does not really work. Propose fix : use a prefix instead of a bind.
TomT0m created this task.
TomT0m added a project: Wikidata Query UI.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
I filled this as a bug but this might be considered a feature request,
depending on the point of view. (The point is that I considered this as a
bummer when trying to use the feature)
The "template" feature of WDQS is useful, but there is a stopper that make it
hard to use for some query. It requires a variable to "bind" a value, and that
works only in some scope of a query.
If you write a complex query, the variable is likely to not be accessible in
all the scopes.
See for example this query
#TEMPLATE={ "template": { "en": "Textual description of template,
referencing ?var" }, "variables": { "?var": { } } }
select * {
bind ( wd:Q5 as ?var)
?person wdt:P31 ?var .
{
select ?person2 (?var as ?plop){
?person2 wdt:P31 ?var .
bind ( wd:Q5 as ?var)
} limit 10
}
} limit 100
that can be checked
(here)[https://query.wikidata.org/embed.html#%23TEMPLATE%3D%7B%20%22template%22%3A%20%7B%20%22en%22%3A%20%22Textual%20description%20of%20template%2C%20referencing%20%3Fvar%22%20%7D%2C%20%22variables%22%3A%20%7B%20%22%3Fvar%22%3A%20%7B%20%20%7D%20%7D%20%7D%0ASELECT%20*%20WHERE%20%7B%0A%20%20BIND(wd%3AQ571%20AS%20%3Fvar)%0A%20%20%3Fperson%20wdt%3AP31%20%3Fvar.%0A%20%20%7B%0A%20%20%20%20SELECT%20%3Fperson2%20(%3Fvar%20AS%20%3Fplop)%20WHERE%20%7B%0A%20%20%20%20%20%20%3Fperson2%20wdt%3AP31%20%3Fvar.%0A%20%20%20%20%20%20BIND(wd%3AQ5%20AS%20%3Fvar)%0A%20%20%20%20%7D%0A%20%20%20%20LIMIT%2010%0A%20%20%7D%0A%7D%0ALIMIT%20100)]
There is a "bind" in a subquery with the same variable, but when you
interactively change the "human" value of the "?var" value then the value does
not change in the subquery. This query is dummy of course, it’s just provided
here for illustration.
There could be a solution using named subquery, doing the bind in a dummy
named subquery and include in later in any relevant context, but it’s tedious
to do, and named subquery tends to sometimes make a query timeout for non
obvious reasons, which require work to solve.
I see too solutions for this problem :
- either drop the use of a "bind" and instead use the "prefix" feature as
used in scholia, see
https://github.com/WDscholia/scholia/blob/master/scholia/app/templates/author_list-of-publications.sparql
. This solves the scope problem. It can coexist with the current solution by
adding an option to the template json, or by checking if the "?var" part is
replaced by a prefix syntax "var:" as it is done in the "prefix" case.
- Non exclusive, instead of replacing the bind value in only one bind replace
it in all places, requires putting multiple "binds" in the query, less
convenient to use.
TASK DETAIL
https://phabricator.wikimedia.org/T327601
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: TomT0m
Cc: Aklapper, TomT0m, 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] T311483: Add a « color » datatype to Wikidata
TomT0m added a comment. Comment by Infrastruktur ( https://www.wikidata.org/wiki/User:Infrastruktur ): https://www.wikidata.org/w/index.php?title=Wikidata:Request_a_query=1668084082=1668050412=source Thumbs up. 24 bits was AFAIK for some time considered sufficient to represent all colors discernible by humans, but this model is too simplistic. The human eye is more sensitive to changes in luminance than to changes in chrominance something that video compression schemes know to take advantage of. It's a good idea to have a datatype for color, but chances are the best way to natively store this isn't RGB. Maybe a floating point version of YUV or YCbCr is closer to optimal? It certainly gives a more accurate representation using the same amount of bits per component. I don't have a developer account so if someone can copy and paste this into Phabricator that would be great, thanks. TASK DETAIL https://phabricator.wikimedia.org/T311483 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, TomT0m, 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] T311483: Add a « color » datatype to Wikidata
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T311483 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, TomT0m, 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] T311483: Add a « color » datatype to Wikidata
TomT0m created this task. TomT0m added projects: Wikidata, DataTypes. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **Feature summary** Wikidata has datatypes for numbers, dates, and a number of other things. However it does not have a datatype and proper support for stuffs that are popping all other the place, like, here, colors. **Use case(s)** : The Wikidata property P465 <https://phabricator.wikimedia.org/P465> https://www.wikidata.org/wiki/Property:P465 has 10430 use at the time of writing. It’s a property that stores a HTML coded color as an hexadecimal triple. It’s a popular and widely used color format, although of course not universal. **Benefits** : It would allow the color to be shown in the Wikidata user interface without ugly hacks, allow a proper support of colors in the query service visualization for example. TASK DETAIL https://phabricator.wikimedia.org/T311483 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, #wikidata, #datatypes, TomT0m, 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] T310894: Merged lexemes are referenced in statements with no way of trace to sense ID
TomT0m added a comment. A solution could be to break stuff and add senses and forms proper stable ids for themselves. The current IDs « Laaa-S2 » are not easily usable anyway and not so easy to find out from the page when you need them, at least with current UI. If a « break things » solution is adopted, the sooner the better I guess … TASK DETAIL https://phabricator.wikimedia.org/T310894 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: TomT0m, Lydia_Pintscher, Mohammed_Sadat_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, 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] [Retitled] T247027: Add a « Gregorian mean year » ( Q87193822 ) unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m renamed this task from "Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit" to "Add a « Gregorian mean year » ( Q87193822 ) unit to the Wikidata conversion table to normalize values that uses this unit". TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Commented On] T247027: Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m added a comment. In fact the unit corresponds to the « mean gregorian year », and I created a fresh item <https://www.wikidata.org/wiki/Q87193822> for this, to be sure there is no pollution from inconsistent datas on Wikipedia articles. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Commented On] T247027: Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m added a comment. Indeed. I don’t know if a unit has previously be added to the translation table after the first initialization, but the problem seem to be that creating a ticket and pinging everyone for such simple task seems like an overkill procedure. I don’t know if someone less community involved or a newbie would even try to do something like this. Can we imagine a procedure with more visibility with a simple set of criteria on wether or not a unit is eligible for inclusion in this translation table ? TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Commented On] T247027: Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m added a comment. In T247027#5947353 <https://phabricator.wikimedia.org/T247027#5947353>, @Lea_Lacroix_WMDE wrote: > @Ladsgroup Do you know where the Wikidata conversion table is stored and how to add new entries? I wondered a while ago, the answer is unitConversionConfig.json <https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/master/wmf-config/unitConversionConfig.json> and I added the fact on the wikibase doc on mediawiki <https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Normalized_values>. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Ladsgroup, Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Edited] T247027: Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Created] T247027: Add a "tropical year" unit to the Wikidata conversion table to normalize values that uses this unit
TomT0m created this task. TomT0m added projects: Wikidata, Wikidata-Query-Service. Restricted Application added subscribers: Liuxinyu970226, Aklapper. TASK DESCRIPTION The annum <https://www.wikidata.org/wiki/Q1092296> unit is used in Wikidata statements to represent half life of isotopes, this is shown by this query <https://w.wiki/JBE>. 1 annum = 1 tropical year = 31 556 926 s The value is also cited by the NASA in this document as used currently for calendar calculation by them <https://www.grc.nasa.gov/www/k-12/Numbers/Math/Mathematical_Thinking/calendar_calculations.htm>. This unit is used in the dataset used to source these half-life statement, as shown in this document <http://amdc.in2p3.fr/nubase/2017Audi03.pdf> (if I’m not wrong) in the name « tropical year ». The number of seconds indicated in the item and of the « tropical year » used in the document corresponds. Amongst the different units used to represent half life statements of isotopes, it’s basically the only one that is not normalized as shown by [[https://w.wiki/Jo2 | this other query}] This basically blocks the possibility to use normalization in this query <https://fr.wikipedia.org/w/index.php?title=Utilisateur:TomT0m/Brouillon=168099274> that is a part of a work in progress work to build a Wikipedia Module that uses Wikidata data to maintain a frwiki table of isotope from Wikidata data. (The workflow of which would be, generate a json dataset from the query service, use listeria bot to import this in an frwiki, use Lua to load the json file from this page. This works, as a prototype, actually — see the module <https://fr.wikipedia.org/wiki/Module:Table_des_isotopes> and a page where it’s used <https://fr.wikipedia.org/wiki/Mod%C3%A8le:Table_des_isotopes/Bac_%C3%A0_sable>). It’s a comfort in the query to use the normalization possibility not to have to deal with the unit. Currently the isotopes with high life life are not colored in the sandbox page due to this. There is a difficulty with the « tropical year » unit, it’s that in the broader sense it’s a variable quantity. But it’s not a problem if we use several items with different length in seconds and decide, as it’s done in the paper cited above, that the number of seconds is that one. Other items can eventually represent a different number of seconds for different tropical years (like the « tropical year 1900 » mentioned in the paper). Of course it’s possible to convert without normalization one way or another, but considering the legitimate use in datasets, the importance of the unit, I think it’s worth adding it to the conversion table anyway as another variant of « year », even if the number of uses is not that high. TASK DETAIL https://phabricator.wikimedia.org/T247027 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Aklapper, Liuxinyu970226, Lydia_Pintscher, Lea_Lacroix_WMDE, TomT0m, darthmon_wmde, 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] [Commented On] T244924: wikibase:label autovariables and sparql aggregation function like group_concat don’t work together
TomT0m added a comment. In T244924#5874472 <https://phabricator.wikimedia.org/T244924#5874472>, @Dipsacus_fullonum wrote: > Not a bug. Use of the Label service in automatic mode for unbound variables in "GROUP BY" isn't mentioned as supported in the user manual (https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Label_service) so cannot be expected to work. But it’s also present in the select clause « select ?person ?personLabel (group_concat(?citizenshipLabel;separator="/") as ?citizenships) » technically contains a « ?citizenshipLabel ». So unless the usage in « group by » is supposed to be a kind of binding, this means the ?citizenshipLabel is present in the « select » and is not bound. TASK DETAIL https://phabricator.wikimedia.org/T244924 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Dipsacus_fullonum, Wikidata-bugs, Aklapper, TomT0m, darthmon_wmde, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, 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] [Edited] T244924: wikibase:label autovariables and sparql aggregation function like group_concat don’t work together
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T244924 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Wikidata-bugs, Aklapper, TomT0m, darthmon_wmde, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, 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] [Edited] T244924: wikibase:label autovariables and sparql aggregation function like group_concat don’t work together
TomT0m updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T244924 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: Wikidata-bugs, Aklapper, TomT0m, darthmon_wmde, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, 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] [Created] T244924: wikibase:label autovariables and sparql aggregation function like group_concat don’t work together
TomT0m created this task.
TomT0m added a project: Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
This query using label variables from the query service ( ?profLabel ) with
the aggregation function works fine. But I had to explicitely name the
?profLabel variable in the wkibase:label call. I’d had expected the next query
to work also (same without doing the explicit naming) but it does not work,
blazegraph seem to not pick up the autonamed variables to work in agregation
functions.
sparql
select ?personne ?nombre_profession ?personneLabel
(group_concat(?profLabel;separator=" ; ") as ?professions)
with {
select ?personne (count(?prof) as ?nombre_profession) {
?personne wdt:P106 ?prof .
service bd:sample {
?personne wdt:P31 wd:Q5 .
# optional service params for the
sample
bd:serviceParam bd:sample.limit 10 .
#bd:serviceParam bd:sample.seed 0 .
bd:serviceParam bd:sample.sampleType "RANDOM" .
}
} group by ?personne having (?nombre_profession > 3)
} as %sample
with {
select ?personne ?personneLabel ?nombre_profession ?prof ?profLabel {
include %sample
?personne wdt:P106 ?prof .
#?personne rdf:laber ?personneLabel filter (lang(?personneLabel) = "fr"
or lang(?personneLabel) = "en" )
SERVICE wikibase:label {
bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en".
?prof rdfs:label ?profLabel .
?personne rdfs:label ?personneLabel .
}
}
} as %labelled_sample
{
include %labelled_sample
} group by ?personne ?personneLabel ?nombre_profession
order by desc(?nombre_profession)
sparql
select ?personne ?nombre_profession ?personneLabel
(group_concat(?profLabel;separator=" ; ") as ?professions)
with {
select ?personne (count(?prof) as ?nombre_profession) {
?personne wdt:P106 ?prof .
service bd:sample {
?personne wdt:P31 wd:Q5 .
# optional service params for the
sample
bd:serviceParam bd:sample.limit 10 .
#bd:serviceParam bd:sample.seed 0 .
bd:serviceParam bd:sample.sampleType "RANDOM" .
}
} group by ?personne having (?nombre_profession > 3)
} as %sample
with {
select ?personne ?personneLabel ?nombre_profession ?prof ?profLabel {
include %sample
?personne wdt:P106 ?prof .
#?personne rdf:laber ?personneLabel filter (lang(?personneLabel) = "fr"
or lang(?personneLabel) = "en" )
SERVICE wikibase:label {
bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en".
}
}
} as %labelled_sample
{
include %labelled_sample
} group by ?personne ?personneLabel ?nombre_profession
order by desc(?nombre_profession)
TASK DETAIL
https://phabricator.wikimedia.org/T244924
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: TomT0m
Cc: Wikidata-bugs, Aklapper, TomT0m, darthmon_wmde, Nandana, Lahi, Gq86,
Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst,
LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll,
Smalyshev, 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] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
TomT0m added a comment. I implemented something like that in https://www.wikidata.org/wiki/Module:Iterators without the coroutine module. There is also the Luafun library https://github.com/luafun/luafun that does functional stuffs, totally usable in as a Mediawiki module : https://www.wikidata.org/wiki/Module:Luafun without the coroutine module. My own code is not perfect, as the iterators are statefull however. TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T169374: Add support for exception list
TomT0m added a comment. Another option : specify a class of exceptions. A property « exception class » If an item is an instance of the execption class, then the constraint is not relevant. In spirit, if we require for example items with a birth date to have a death date, and if we have a subclass of « fiction human », say « immortal », that should actually not have one birth date : constraint : requires statement property: death date exception class : immortal Which reads in english « any item with a birth date should have a death date except immortal instances » TASK DETAIL https://phabricator.wikimedia.org/T169374 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: TomT0m, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Liuxinyu970226, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, 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] T193728: Solve legal uncertainty of Wikidata
TomT0m added a comment. Psychoslave added a comment. In T193728#4231659 https://phabricator.wikimedia.org/T193728#4231659, @TomT0m https://phabricator.wikimedia.org/p/TomT0m/ wrote: That mean that you could potentially indeed rebuild the very same set of books with a prose automaton, but also (and most likely) many other prose variations. And if you would include predicates extracted from fanfictions from different sources and unsourced predicates around Harry Potter universe including potentially completely novel ones, that would probably be a even more closely corresponding analogy with the current state of Wikidata. *This is rather unrealistic at this point and unrelated to my point. The question raised is rather : Wikipedia has an infobox. Wikidata has the same informations compared to that infobox, but it was not imported but rebuilt from scratch by a user. * This rather unrealistic at this point and unrelated to my point. The question raised is rather : Wikipedia has an infobox. Wikidata has the same informations compared to that infobox, but it was not imported but rebuilt from scratch by a user. Question: is the fact that it was rebuilt relevant to copyright or only matters the fact that the informations are the same ? I'd tend to think that the equality of information is the key, which would mitigates kind of a lot the relevance of discussing eternally the fact they were or not copied from a Wikipedia. Said differently: the fact that the informations are in Wikipedia would prevent to have them in Wikidata or any other database.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Aschmidt, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
TomT0m added a comment. Well, entries that were not created thanks to massive import from Wikipedia obviously don't raise any concern of infringement of Wikipedia community copyright. It doesn't say more about those that were indeed imported in such a way, do it? As far as I understand copyright, if by a pure random event I happen to write exactly one page of Harry Potter, I can’t publish this as easily as I would want. The stuff is protected whatever the way it was created. So it does not matter if we actually imported datas or it happens we substancially have the same result by over means.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
TomT0m added a comment. Well, you just said that that there might be cases "where copyright law permits the extraction of information from copyrighted texts", so I believe that an explicit indication about those cases in the CC-BY-SA license could be helpful for other people to avoid repeating this conversation in other places. You can add anything to the licences terms, but if the law do not give you the power to act on that unything the clause is illegal, hence ignored by courts. In this case, the existence of the licence depends on the copyright law. So the things you can act on are the precise « rights » the copyrights defines, and nothing more. If you add an out of scope clause in a CC, it’s not relevant.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
TomT0m added a comment. In such cases there is a simple rule which says that you should choose the safest way in order to comply with the law, as any doubt remaining would be baneful. Well, a few things: This is only my personal opinion, certainly not a definitive answer. I would not want a decision taken only because I’m mistaken or because of incorrect community opinions This is the situation as we have it for a few years, so if there is an issue even if we take a conservative decision now this won’t change the past and the current situation is at risk « as any doubt remaining would be baneful. » Well, this is a balance question, the change of license could be more painful/harmful or put some datas in current Wikidata at risk of being legally challenged. This might pose a problem to some of our reuser/usecases could be . This is not that simple. There is two ways of seeing things: the legal issues have not actually been much of an issue up to now and the problem posed by it are mostly theoretical as long as we are careful not to import obviously problematic datasets. Or we take a legalistic approach and to be safe we must answer legal questions anyway as if we don’t understand the issues in depth we can’t be sure we took no risk. But considering the actual legal complexity, I think a total legal safety is rather dubious and we have to live with some amount of risk no matter what. This implies that to be conscious of this amount we have to evaluate it, knowing the truth in this area is sometime only known after a trial… In this case, considering we lived the past few years with this and we did not see anything coming beyond any discussion here and there that pops from time to time, I don’t really see (personal opinion) any reason to believe this could change in the future if things stays that way.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
TomT0m added a comment. Just to check if there is an actual problem here: let’s imagine a theorical usecase. Alice, or the AliceAndBob group, contributed to Wikipedia and are hurt because some informations they entered in Wikipedia are also present in Wikidata. She/They thinks there legal rights have been violated and want to go to court. First question: do we have actual candidates for Alice or AliceAndBob? Second question: Under which precise law could they actually file a claim? Third question: Under which condition would the court accept the case? The rationale behind this question is that my impression is that, at least in the france case, only the producer of data in a database can claim rights, if he has engaged a substantial amount of efforts or resources, and if he can prove it, to compile the datas. The « author’s law » in france do not cover datas or databases beyond the pure form. Which kind of contributor in Wikipedia actually does (amongst other things) pure data compilation work to the point he can consider this « substantial »? If no individual can, can a group of contributor consider they together engage a substantial amount of effort and together file a complaint? To give an idea of the complexity of the questions, I’ll translate a few phrases of a lawyer’s webpage in french ( https://www.murielle-cahen.com/publications/p_bases2.asp ) On « who can claim the right»: Le droit sui generis appartient au producteur de la base de données. Le producteur est « la personne qui prend l'initiative et le risque des investissements correspondants » selon le Code de la propriété intellectuelle. Aucune autre personne ne peut se prévaloir du droit sui generis. « the sui generis right belongs to the producer of the database. That is « the person who take the initiative and the risk of the corresponding investments »according to the intellectual property code. No other person can claim the right. » On « what is a substantial amount : Selon la CJCE, le rassemblement des données, « leur agencement systématique ou méthodique au sein de la base, l'organisation de leur accessibilité individuelle et la vérification de leur exactitude tout au long de la période de fonctionnement de la base » peut nécessiter un investissement substantiel. « According to the CJCE (a high level European court of justice), the data compilation, their systematic or methodical arrangement into the database, the organisation of their individual access, the verification of their correctness all along the lifetime of the database activity » can need a substantial investment. Ce n'est pas l'investissement lié à la création des données qui entre en ligne de compte mais l'investissement lié à la présentation de ces données dans la base. This is not the investment linked to the creation of the datas that is taken into account but the investment linked to the presentation of the datas in the database. « les moyens consacrés à l'établissement d'une liste des chevaux ne correspondent pas à un investissement lié à l'obtention et à la vérification du contenu de la base de données dans laquelle figure cette liste » The means used to establish a list of horses do not constitute an investment linked to the obtention and verification of the content of the database in which this list is included » In this document the « substancial amount » is also discussed. An extraction of 12% of the announces of a job website was not considered substantial by a court, for example. So considered in isolation, 10% information reuse is not substantial. But in our case, does this mean 10% off all wikipedias, considering no one can claim to be the producer of all wikipedia, or 10% of a specific contributor contribution, considering it’s rarely relevant to consider the unique contribution of a single contributor, or that the contribution of a single contributor qualify to the database definition… The more I personnaly dig into this questions, the more issues are opened and the less clear it becomes that there is an actual issue, and if there is an actual issue if there is a legal risk. Or even if there is a moral or ethical issue: I think we will all agree here that pure facts can be used by anyone (beyond private life one).TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T187314: Display labels for entity values at result visualisation step in Wikibase Query Engine
TomT0m added a comment. I think the simpler the writing of the query is, the better for the user. As a user, I’d prefer not having to care about wikibase:label at all, having a label for a human is such an important and basic thing … Most of the time it’s just annoying to have to add this to a query. Automatically wrapping the query to solve a problem of performance of a service I’d prefer not having to care about seems like a weird complication to me (almost like a Goldberg machine :). But I don’t care that much and you’re the boss :) I guess the service is needed in some cases anyway and you’ll have to solve the performance issues in these cases as well. My personal opinion however is that it’s moistly useful when we need to use the label variables for some reason to filter the results of the query, and in that case the optimization of wrapping the query will not work as the label has to be computed in any case.TASK DETAILhttps://phabricator.wikimedia.org/T187314EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: Lucas_Werkmeister_WMDE, Aklapper, TomT0m, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, 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] [Created] T187314: Display labels for entity values at result visualisation step in Wikibase Query Engine
TomT0m created this task.TomT0m added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONReplace wd:Q255 and the like with their label according to the user language is the query service result display for entities datatypes.
Rationale:
Labels for item or other entities can be computed through the « wikibase:label » service. This is useful, but causes major performance issues in queries as some queries timeout with the usage of this service while taking a handful of seconds with the query service call commented.
An idea to solve this is to deal with the computing of the label not at the query time with wikibase:label but at the result display time of the result set. This could be way more efficient in some cases, for example when the result set is small but the service is actually called a lot during the query, or when the result set is big but the user actually watch a tiny fraction of it, especially when the ?xLabel variables generated by the service are used only in the « select … { » projection part of the query and never in the « { … } » part.
The case where only a tiny fraction of the result is actually watched by a human may be pretty common as the results in the table view are paged and the full result set may actually not be use to be watch fully by a human but its destiny is actually to be used by an external tool.TASK DETAILhttps://phabricator.wikimedia.org/T187314EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: Aklapper, TomT0m, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, Jonas, FloNight, 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] T107595: [RFC] Multi-Content Revisions
TomT0m added a comment. In T107595#279, @daniel wrote: @TomT0m No, Multi-Content-Revisions does not help with consistent display of old template revisions. Well, it does in cases where the use of templates is replaced by the use of slots - if e.g. template documentation was stored in a slot instead of a subpage, you would always see the correct version of the documentation for old versions of the template. But that would be because it would no longer use the template mechanism. Ok, I got confused. Does that mean that the documentation will not have its wikipage address anymore ? Would this then be possible to have a special type of "reference" slot which would hold a pointer to another page revision ? I guess the parser could be modified to maintain those reference slots when page are saved. For example the parser computes a new version of the page when its content is modified, and when he expands a template a hook triggers the slot mangager to store the revision number of the template with those "reference" slots - I guess this this kind of hooks or something similar exists since we got a list of the used templates on previsualisation of a page.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, TomT0mCc: Izno, Pppery, Alsee, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions
TomT0m added a comment. Question : History of old articles If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited. Two questions arise then : will that also work for deleted templates ? will we be able to restore the revisions of version prior to multiple content revision deployment, say a 2005 revison of some article ? TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, TomT0mCc: Izno, Pppery, Alsee, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T148617: Precise number forgot when a precision is set in Wikibase UI
TomT0m created this task.TomT0m added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONUsecase and rationale : In french census a precise number for the precision of the counted number is officially published, without precision. But the same organism publishes a document to compute a precision for this number : http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/resultats/doc/pdf/fiche-precision.pdf As Wikidata is made, it seem (to the author of this ticket) that it's reasonable to store both information in a single statement sourced by the official results and the preceding document. Problem: Wikidata UI does not expose at all the precise number but always rounds wrt. the precision. The probem is that the precise number is the official number used by french administration. Suggested solution : gives a way in the UI to see the precise number entered ignoring the solution.TASK DETAILhttps://phabricator.wikimedia.org/T148617EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: Aklapper, TomT0m, D3r1ck01, Izno, 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] T107595: [RFC] Multi-Content Revisions
TomT0m added a comment. In T107595#2664347, @Alsee wrote: A page is simply a text file. A page is definitely not a simple text page. It's a text page written in a programming language - the wikitext and tempates - that happens to have a textual representation. It also includes references to external content like images inclusion, metadatas as categories and so on. It also happens that the wikitext representation of a page is not the only one and that parsoid has its own who may become the main representation for convenience of the developpers. This representation can also be copy/pasted. To be rendered, it must be manipulated by a compiler that turns it into HTML content and does pretty complex stuff like managing the wiki categorisation index, include the templates and do on. This proposal, as far as I understand, won't change a bit the textual representation of the content and the fact that you can copy/paste it into another page. This is proposing turning Wikipedia into a gigantic complex app. Open your eyes, Mediawiki is an app with decades of developpement and continuous developement, new features are constantly added, new usecases emerge. It's already a gigantic complex app. The only valuable question is "how do we manage such complexity", and this proposal is one of the answer.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, TomT0mCc: Alsee, Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117032: Create configuration for specifying units conversions
TomT0m added a comment. Hi, maybe I come after the battle, but if you're not aware of this, Wikidata has now a "conversion to SI unit" that could come valuable for this as it stores the value of the configuration file. Maybe instead of this configuration we can make the mechanism more flexible by just specifying such a property on the database. The set of unit supported by the export could then be extended with no privilege at all.TASK DETAILhttps://phabricator.wikimedia.org/T117032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: TomT0m, gerritbot, Smalyshev, Aklapper, daniel, aude, mschwarzer, MelodyKramer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T139834: Wikidata Entity datatype
TomT0m created this task.TomT0m added projects: TemplateData, Wikidata.Herald added subscribers: Zppix, Aklapper.Herald added a project: VisualEditor. TASK DESCRIPTIONI'd want to use a "Wikibase entity" datatype to templatedatas. "Page" dataype is not enough for Qids or Pids, so we have to choose something else, like free text who is not appropriate either There is several ways to enter an entity value ; the Mediawiki way as "Namespace:Pagename", the web URI as in "https://www.wikidata.org/entity/Q11344" or the web URI of the wikipage of the entity "https://www.wikidata.org/wiki/Q11344" (more easily copy/pasting possible) or the same in Mediawiki space address [[:d:P:31]]. Some of my templates like https://www.wikidata.org/wiki/Template:Q' can use all of them.TASK DETAILhttps://phabricator.wikimedia.org/T139834EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TomT0mCc: Aklapper, TomT0m, Zppix, merbst, AlexMonk-WMF, Wess, D3r1ck01, Izno, Jrf, Husun1297, Wikidata-bugs, Etonkovidova, aude, Swainr, Jdforrester-WMF, Mbch331, Jay8g, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
TomT0m added a comment. @kaldari : the proposed solutions with arbitrary access are here : https://www.wikidata.org/wiki/Wikidata:WikiProject_Cross_Items_Interwikis TASK DETAIL https://phabricator.wikimedia.org/T54564 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: TomT0m Cc: TomT0m, Thryduulf, Rich_Farmbrough, Zppix, ChristianKl, Mike_Peel, Wittylama, Liuxinyu970226, SebastianHelm, MisterSynergy, Oliv0, JanusTroelsen, Blahma, MGChecker, MSGJ, Izno, Nnemo, bzimport, Unknown Object (MLST), DanielFriesen, Gymel, Denny, jeblad, Abraham, Addshore, SamB, Toru10, Wikidata-bugs, JAnD, Nemo_bis, He7d3r, -jem-, ValterVB, Filceolaire, Micru, JanZerebecki, matej_suchanek, Ricordisamoa, MZMcBride, Aklapper, Tgr, kaldari, Laddo, Lydia_Pintscher, Jane023, Ltrlg, JohnLewis, Fomafix, Zellfaze, D3r1ck01, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
TomT0m added a comment. It's not a question of appearance, but of meaning. In a boolean algebra, the inputs and result of the operation are sets, whereas in logics we manipulate truth values of different kind. I have a feeling that it would be useful to add a feature such as a mapping Tex macro ; arity ; meaning with macro beeing a string such as \frac ; arity beeing a number of parameters (2 here) ; and meaning beeing a Qitem such as https://www.wikidata.org/wiki/Q1068675 depending of the type of objects the formula ranges on. There could be a default mapping, such as standard division on the real numbers for \frac, of course. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, TomT0m Cc: ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, NiharikaKohli, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
TomT0m added a comment. > Otherwise it would be like a Wikipedia article where every word is a link. I don't think it's a question of generating a link, but a way to have a generic math formula semantics precisions. But to take only one example : the ∧ and ⋁ symbols means something different in - https://en.wikipedia.org/wiki/Boolean_algebra_%28structure%29 - https://en.wikipedia.org/wiki/First-order_logic ... More broadly, scientists constantly introduce new symbols, so a way to map à symbol / macro (parametered macro) to an operation or a meaning may be necessary for some semantic representation of formulas. Operation also differs, so map this to an item about the operation itself might be cool TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, TomT0m Cc: ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, NiharikaKohli, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T107595: [RFC] Multi-Content Revisions
TomT0m added a subscriber: TomT0m. TASK DETAIL https://phabricator.wikimedia.org/T107595 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel, TomT0m Cc: TomT0m, Krenair, Krinkle, intracer, Tgr, Qgil, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, Wikidata-bugs, aude, jayvdb, Mbch331, Jay8g, bd808 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
TomT0m added a comment. You are working on automatic mapping ? Does seem a little hard indeed. I was thinking on optional manual mapping in the UI of the formula datatype as a first step. Maybe we could suggest a few predefined operator mappings for common case later ... TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, TomT0m Cc: ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, NiharikaKohli, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
TomT0m added a comment. The variables are mapped, but what about the operators ? TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, TomT0m Cc: TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, NiharikaKohli, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T67397: [Story] add a new datatype for formulae
TomT0m added a subscriber: TomT0m. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, TomT0m Cc: TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, NiharikaKohli, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
