[Wikidata-bugs] [Maniphest] [Commented On] T145522: [feature request] how to clean up redirects in sitelinks
Alphos added a comment. The debate is long over. Links MUST point to articles specifically about the entity described. Not sections, not redirects, not articles about generic entities, not articles about something unrelated. There can be no exceptions. This is especially useful to machines, which are the first consumers of Wikidata - including interwikis on Wikipedia, as they're served to you by machines that need to get them from Wikidata. Machines can't read URL fragments in a meaningful fashion, only browsers will scroll until the top of the screen aligns with the top of the (x|ht|xht)ml element with the id specified as fragment so the user can read from their screen, but that's browser behaviour for web browsing, and should not be expected from other software. Additionally, assuming the debate wasn't over, this would not be the appropriate place to have it, so please, drop it.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanek, AlphosCc: 2015.ww, TomT0m, Lydia_Pintscher, Alphos, Aklapper, Esc3300, 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] T145522: [feature request] how to clean up redirects in sitelinks
Alphos added a comment. It doesn't matter that Wikipedias chose to handle things that way. Wikipedia chose to fill any gap by pointing to a related article. Wikidata chose to fill any gap by actually filling said gap. Wikidata chose to point to articles specifically about the entity described. If you wish for Q12902372 to have a link to an article on enwiki, have an enwiki article about Q12902372. There can be no approximation. So no, I would not agree, no matter how you put it.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanek, AlphosCc: 2015.ww, TomT0m, Lydia_Pintscher, Alphos, Aklapper, Esc3300, 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] T145522: [feature request] how to clean up redirects in sitelinks
Alphos added a comment. In T145522#2999881, @2015.ww wrote: Could someone kindly show a case -- or two :) -- of how such links cause a problem? For example... looking at flautist / flûtist / fløjtenist (Q12902372) with an article e.g. at Fløjtenist but some other links, such as in enwiki, redirecting to the instrument page -- vs the instrument, flute (Q11405) but also recorder (Q187851), etc. etc. ... so aren't such additional links in fact rather helpful ? Thanks much. A flute is a woodwind instrument, therefore a wind instrument, therefore an aerophone, therefore a musical instrument, therefore a tool. Are you saying flautists are tools? Yes, the [[Q2030511]] was fully intended. A redirect from enwiki:flautist to enwiki:flute can somewhat make sense locally - although it prevents enwiki from having an article about the actual "obnoxious or uptight person" behind the instrument. But from a Wikidata perspective, when someone expects to click on a link and find an article on the specific subject they's looking at, and in fact finds an article on something related instead of what they was looking for, it is only confusing, not "rather helpful" at all.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanek, AlphosCc: 2015.ww, TomT0m, Lydia_Pintscher, Alphos, Aklapper, Esc3300, 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] T145522: [feature request] how to clean up redirects in sitelinks
Alphos added a comment. For what it's worth, I've built WRCR with the intent of finding items that link to pages that redirect to other pages that have items linking to them too. I must warn there are some false positives, due to a tradeoff between specificity and speed ; and even though I'd like better specificity, I had no choice given the time "big" wikis (anything bigger than arwiki, really) would have taken (certainly hours, possibly days or even weeks - instead of seconds or minutes with the current setup). I however don't believe there are false negatives, sensibility should be 100%. I am still looking for a way to improve specificity to 100%. It publishes CSV files for every wiki every friday around 03:00 UTC, and keeps track of the number of hits on each wiki - a visualization tool for the number of hits over time is planned.TASK DETAILhttps://phabricator.wikimedia.org/T145522EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlphosCc: Alphos, Aklapper, Esc3300, 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] [Created] T145466: ASK considers absurd subclasses as valid in Wikidata Query Service
Alphos created this task.Alphos added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONAfter finding an odd result while testing an ASK query, I stumbled upon this obvious example case :
ASK {
wd:Q618123 wdt:P279+ wd:Q5 . # is "geographical object" an indirect subclass of "human being"
}
returns true. Results are the same with wdt:P279* (is indirect or direct subclass of).
Oddly enough, the same query without + (direct subclass of) returns false :
ASK {
wd:Q618123 wdt:P279 wd:Q5 . # is "geographical object" a direct subclass of "human being"
}
and this SELECT query returns no result (as expected, quite frankly :-D ) :
SELECT ?q
WHERE {
wd:Q618123 wdt:P279* ?q . # "geographical object" is a direct or indirect subclass of the class we're looking for
?q wdt:P279* wd:Q5 # which is itself a direct or indirect subclass of "human being"
}
So wd:Q618123 is a { direct or indirect } and { indirect } subclass (so it must be indirect by intersection) of wd:Q5. But it is not a direct subclass of wd:Q5 (which we've already established), and it is impossible to find an intermediate class between wd:Q618123 and wd:Q5, which means it isn't an indirect subclass of wd:Q5 either.TASK DETAILhttps://phabricator.wikimedia.org/T145466EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlphosCc: Aklapper, Alphos, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143897: Use of xsd:duration throws an error in Wikidata Query Service
Alphos added a comment.
Or, to handle the string literals too :
# People who died in the last 7 days
SELECT ?person ?deathDate {
?person wdt:P31 wd:Q5 .
?person wdt:P570 ?deathDate .
FILTER( IF ( sameTerm(dataType(?deathDate), xsd:dateTime), ?deathDate >= ( NOW() - "P7D"^^xsd:duration ), STRDT( ?deathDate, xsd:dateTime ) >= ( NOW() - "P7D"^^xsd:duration ) ) )
} ORDER BY ?deathDateTASK DETAILhttps://phabricator.wikimedia.org/T143897EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlphosCc: Esc3300, gerritbot, Smalyshev, Alphos, WikidataFacts, Aklapper, Sylvain_WMFr, mschwarzer, MelodyKramer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143897: Use of xsd:duration throws an error in Wikidata Query Service
Alphos added a comment.
It's weirder than you think :
SELECT ?now WHERE {
BIND( ( NOW() - "P7D"^^xsd:duration ) AS ?now ) .
}
returns "Sep 1, 2016", which is 6 days from today (we're 2016-08-25T23:55:00.000+02:00, give or take a few minutes)
SELECT ?now WHERE {
BIND( ( "2016-08-26T00:13:14.567Z"^^xsd:dateTime - "P7D"^^xsd:duration ) AS ?now ) .
}
returns "Sep 2, 2016".
Same goes for all values of date and time, including time values such as [...]T00:13:14.567Z, [...]T12:13:14.567Z, [...]T23:13:14.567Z to account for my timezone not being Zulu (I'm currently UTC+02:00) : all these subtractions of 7-day xsd:duration actually add 6 days, for some reason.
I'd look in the - operator implementation for xsd:dateTime and xsd:duration entities ;-)TASK DETAILhttps://phabricator.wikimedia.org/T143897EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlphosCc: Smalyshev, Alphos, WikidataFacts, Aklapper, Sylvain_WMFr, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T143897: Use of xsd:duration throws an error in Wikidata Query Service
Alphos added a comment.
Temporary workaround :
# People who died in the last week
# Well, more accurately, people whose death + 7 days is after the current day and time, but still !
SELECT ?human ?humanLabel ?date
WHERE
{
?human wdt:P31 wd:Q5;
wdt:P570 ?date.
FILTER(?date + "P7D"^^xsd:duration >= NOW() ).
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
ORDER BY ?date
Enjoy :-)TASK DETAILhttps://phabricator.wikimedia.org/T143897EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AlphosCc: Alphos, WikidataFacts, Aklapper, Sylvain_WMFr, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T94159: Put lastrevid of linked entities in mw.config.values.wbUsedEntities
Alphos added a comment. Way ahead of ya ;-) Current implementation (JS on test.wikidata <https://test.wikidata.org/wiki/User:Alphos/ytreporp.js>) performs the ##action=wbgetclaims&props=claims|info## call at window.onload time on items that are targetted by properties of interest. Still wrapping my head around widgets and triggered events, planning on implementing them to do things more cleanly, but that's another talk altogether. Thanks for your input ! TASK DETAIL https://phabricator.wikimedia.org/T94159 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alphos Cc: adrianheine, Aklapper, Alphos, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T94159: Put lastrevid of linked entities in mw.config.values.wbUsedEntities
Alphos added a comment.
I'm working on a gadget that will allow you to insert by hand only one side of
a relationship, and click for an automated insertion of the other side.
Let me clarifiy with a real world example :
- La Villette <https://www.wikidata.org/wiki/Q532352> was a subdivision of
Seine department <https://www.wikidata.org/wiki/Q1142326>.
- Q532352 (La Villette) <https://www.wikidata.org/wiki/Q532352> has therefore a
P131 (is located in) <https://www.wikidata.org/wiki/Property:P131> pointing to
Q1142326 (Seine) <https://www.wikidata.org/wiki/Q1142326>.
- and Q1142326 (Seine) <https://www.wikidata.org/wiki/Q1142326> has a P150 (has
subdivision) <https://www.wikidata.org/wiki/Property:P150> pointing back to
Q532352 (La Villette) <https://www.wikidata.org/wiki/Q532352>.
Imagine the two items exist, but their properties aren't set yet.
1. You set the P131 (is located in)
<https://www.wikidata.org/wiki/Property:P131> property of
https://www.wikidata.org/wiki/Q532352 (La Villette), with qualifiers and
references, by hand.
2. And you have to do it again //on the other side//, setting P150 (has
subdivision) <https://www.wikidata.org/wiki/Property:P150> on Q1142326 (Seine)
<https://www.wikidata.org/wiki/Q1142326> and setting the same qualifiers and
references, **also by hand**.
The gadget I'm creating would make step 2 shorter by having it done on the
click of a button placed on the first page you edit. It will only work for one
claim per click, for anything too big a batch process (bot or quick-statements)
would be more appropriate.
It would also make sure that a similar claim (same property pointing to the
same item - the current, "local" item) doesn't already exist on the "remote
item" (the one that will be automatically edited) ; if one does exist, it would
only add missing qualifiers and references to it ; and it would do nothing in
case several similar claims exist (performing an action would be non-trivial).
The list of Wikidata property pairs that are concerned is quite extensive, and
the gadget would reduce the amount of redundant actions performed by hand by
users :
{
"P361": "P527",
"P527": "P361",
"P301": "P910",
"P910": "P301",
"P155": "P156",
"P156": "P155",
"P460": "P460",
"P184": "P185",
"P185": "P184",
"P1066": "P802",
"P802": "P1066",
"P1344": "P710",
"P710": "P1344",
"P22": "P40",
"P25": "P40",
"P26": "P26",
"P451": "P451",
"P43": "P40",
"P44": "P40",
"P355": "P749",
"P1308": "P39",
"P1478": "P1536",
"P1536": "P1478",
"P1479": "P1537",
"P1537": "P1479",
"P747": "P629",
"P688": "P702",
"P702", "P688",
"P828": "P1542",
"P1542": "P828",
"P150": "P131",
"P1383": "P131",
"P47": "P47",
"P190": "P190",
"P398": "P397",
"P397": "P398"
}
It is not however a plain pair list : properties A and B may both be "inversed"
into property C, which forbids "inversing" C automatically. See for instance ['P
TASK DETAIL
https://phabricator.wikimedia.org/T94159
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Alphos
Cc: adrianheine, Aklapper, Alphos, Wikidata-bugs
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T94159: Put lastrevid of linked entities in mw.config.values.wbUsedEntities
Alphos added a comment. I did find wgCurRevisionId ;-) Too bad about wbUsedEntities being dropped, it means we're either : - facing race conditions (and potential edit conflicts) : the lastrevid of the used entities may have changed since the loading of the current page - or not caring (and potential edit conflicts), which is even worse. Alternatively, to lessen the probability of race conds (though not as efficiently as providing it straight away), it could be interesting to provide the lastrevid of an entity when performing a ##wbgetclaims## API call on it. TASK DETAIL https://phabricator.wikimedia.org/T94159 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Alphos Cc: adrianheine, Aklapper, Alphos, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T94159: Put lastrevid of linked entities in mw.config.values.wbUsedEntities
Alphos created this task.
Alphos added a subscriber: Alphos.
Alphos added a project: MediaWiki-extensions-WikibaseRepository.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
When viewing an entity, wbUsedEntities currently contains JSON (a string, not
an actual javascript object) representing an object with all entities and some
of their attributes, namely for each :
- datatype (string)
- descriptions (localized, as an object)
- id (string, "P" for a property, "Q" for an item)
- labels (localized, as an object)
- type (one of "item", "property")
However, when performing an API call on a "used entity" using the mw.api.edit
module, you should also provide the lastrevid for that entity in order to avoid
edit conflicts. Gadgets currently don't check for edit conflicts : that is not
sane behaviour, but they don't have much of a choice in the matter.
Performing an API call to get the lastrevid would create two problems :
- you have to perform an API call to get it
- the lastrevid may have changed since you loaded the page, even though the
current page hasn't (because it's been loaded back then)
The current format of wbUsedEntities is as follows :
```{"P":{"content":{"type":"property","id":"P","labels":{"en":{"language":"en","value":"P
english
label"}},"descriptions":[],"datatype":"wikibase-item"},"title":"Property:P"},"Q":{"content":{"type":"item","id":"Q","descriptions":{"en":{"language":"en","value":"Q
english description"}},"labels":{"en":{"language":"en","value":"Q english
label"}}},"title":"Q"}}```
Adding the lastrevid would make wbUsedEntities into :
```{"P":{"content":{"type":"property","id":"P","labels":{"en":{"language":"en","value":"P
english
label"}},"descriptions":[],"datatype":"wikibase-item"},"title":"Property:P",
"lastrevid": >},"Q":{"content":{"type":"item","id":"Q","descriptions":{"en":{"language":"en","value":"Q
english description"}},"labels":{"en":{"language":"en","value":"Q english
label"}}},"title":"Q", "lastrevid": >}}```
TASK DETAIL
https://phabricator.wikimedia.org/T94159
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Alphos
Cc: Aklapper, Alphos, Wikidata-bugs
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
