Tue, Jun 18
Marking this as stalled for now with a note to reopen once AMC is more widely available.
Wikidata should be accessible to mobile Wikipedia readers, not just advanced mobile contributors.
The idea is that one could navigate to the mobile view of Wikidata. I don't actually suggest that people should use a mobile to contribute to Wikidata nor be required to log-in to view Wikidata.
off-topic: what is cool is that it displays images (which www.wikidata.org doesn't)
Why is there such a "need"?
For harvesttemplates, it would be great if this could be queried/defined somewhere
We could use the https://www.wikidata.org/wiki/Q64335281 approach. Also solves the problem of structured data on EntitySchemas.
A problem we had with the Russian gadget is that people try to "update" information from the client instead of adding a new statement, e.g. change 2019 to 18 June 2019. In general, this isn't much of an issue for this type of edit except when the statement on Wikidata includes a reference stating "2019" and not "18 June 2019". Even a typo could be something that requires a new statement.
Sat, Jun 15
Thu, Jun 13
Simple solution could be to use items instead, see https://www.wikidata.org/wiki/Q64335281
I changed the sample in the description above.
+ check items against EntitySchemas
As PetScan has some troubles these days, I'm using query server/mwapi:generator "categorymembers" again.
Fri, May 31
Wikidata has most of that: https://www.wikidata.org/wiki/Wikidata:Database_reports/WMF_projects
Wed, May 29
Maybe it should be a Wikimedia-Site-requests or an interwiki one.
np. I made E27 directly .. bad news is: now I have to come up with items that match the scheme ;)
good point .
We used to have an url property that was suitable for that .. not sure where it went.
Tue, May 28
Somehow I like the summary. Anyways, here it is for future reference
Sun, May 26
I'm not sure if that can be sorted out. There seems to be lots of politics and possible conflicts of interests involved, none really related to the simple issue at hand.
Currently, I don't think the constraint system allows to limit a constraint scope to items only.
The IPA statement on Q102090 isn't really a sample to follow.
I don't think the wdtn triples are needed. I'd just add the "wikibase:identifier" ones.
May 25 2019
P407 isn't needed on lexemes. Even, I asked them not to add it.
You'd need that if most content you want to enter is directly in UPA
Do you want to create codes that allow entering UPA directly? e.g. "sms-fonupa" ?
The current (above) format of the triples (when it works) seems fine from a Wikidata perspective, but from a LOD perspective, shouldn't the triple just be something like:
Suggestions are better than before, but I think a review should be done to see what is still open and what could be improved further.
Maybe you want to add support for replacement_property as well.
May 23 2019
For (non-contemporary) people, I think an interesting grouping could be by century, but I'm not entirely sure how that could work without a dedicated statement.
Not sure if this is relevant here, but the most frequent unhappy paths I notice are:
It seems to using grouping_threshold .. I noticed that when I started using a fairly high one.
For grouping by some sub-national level, maybe a separate query to get levels first is the most efficient. A shorthand for that could be a P31 statement or a property (if there is one).
Anyways, thanks for adding so many of the suggestions. I'm aware that it's usually up to the coders to pick them.
maybe items with Q5 could have separates stats.
May 21 2019
Some not so random suggestions:
Independently of the above, is there a way to use CONSTRUCT ?
Alternative: query by units. Sample: https://www.wikidata.org/wiki/Property_talk:P6591#Query_with_%C2%B0F/%C2%B0C_conversion
May 19 2019
What is needed to run the generator just once, at least once for a given variable?
Apparently codes for lexemes are distinct from monolingual ones. We could solve this first and wait for the other to be sorted out . or whatever.
Interesting. "mad" outputs more than "max" ;)
May 18 2019
Not that it changes the problem, but the current URL should have preferred rank and the former url normal rank. See https://www.wikidata.org/wiki/Help:Ranking#Deprecated_rank
Thanks to both of you. I tested the workaround on the sandbox item above and it worked.
May 16 2019
I tried it there just now: the first worked, the second didn't.
I don't use it that often, but I think it didn't work every time in recent weeks.
It's two years now.
Feb 8 2019
Aug 14 2018
Jun 21 2018
q="don't escape the backslash" :)
So you think it's not possible to link some of the queries to specific users?
Clearly we disagree on the proposed release, its scope and users expectations for privacy. If one thinks it's normal to publish users search history, the arguments you advance are probably a valid point of view.
Jun 20 2018
Maybe page properties should include counts of lemmas, forms and senses, as they do for statements and identifiers.
Do we have any discussion of this usecase onwiki? It seems contrary to a problem raised onwiki.