I think there are at least seven advantages:

• File description pages are easily visible to all users of Commons files (on Wikipedia when one page is displayed, when searching on Commons, at Wikidata, etc. ).
• The pagination on the file description page allows to view a page of a book easily.
• Many djvu/pdf files available on Commons are not transcribed at Wikisource and may never be. This is especially true now that ten thousands of Files_from_the_Biodiversity_Heritage_Library are being mass-uploaded.
• Even if just the index page exists (e.g. sample), it's unclear if having only that part there is really helpful for users of the file (if no transcription follows). Some Wikisource might not want otherwise unused index pages (at least some language versions, I'd guess).
• Pagination of a djvu/pdf is file metadata. As such, I think it should be included also as structured data on Commons.
• Most other fields of index pages are already available on file description pages.
• It might get Commons contributors to added data later useful for Wikisource contributors.

Whatever the approach chosen to determine stubs, it could set the status as a badge on Wikidata .. this can then be queried easily.

@Rotpunkt I think this might be the simpler solution to contributors' problems than the one proposed a year ago, but not implemented.

Wikidata seems to lag in terms of implementation of https compared to other parts of WMF. Can we do something about it?

In T195765#5286494, @Lucas_Werkmeister_WMDE wrote:

[..]

In T195765#5286177, @Debenben wrote:

[..]

It is impossible to get back the original, human-readable LaTeX string from some sanitized version.

[..]

I don’t see how that’s related to this task.

In T195765#5286694, @Lucas_Werkmeister_WMDE wrote:

This doesn't need to lead to a change to any other triples generated by the datatype.

The current proposal in the task description doesn’t lead to any changes in other triples either. It also adds a triple containing only the original input, but as part of a full value node rather than in psn:. (And since it’s a full value node, it includes the MathML again, that’s why the example perhaps looks a bit bloated.)

Somehow I think the task as it's currently worded above is too complicated to solve the initial problem. The idea is that an input of

c^2=a^2+b^2

leads to a triple that contains only:

c^2=a^2+b^2

as would it be if the datatype was string.

To avoid that people confuse claims and statements in general, maybe the feature should use an entirely different name.

I'm trying to figure out what the volume of queries on WQS may be:

For the sake of clarity, maybe it should be mentioned that the presence of a psn: triple wont impact users of wdt: or ps: triples.

Oh.. didn't know that. Which one is the largest one?

outputting the input string "IS" simple

Is is just an impression or do we now get redirected through http: when clicking on a Wikidata item on results on a https-connection WQS?

Maybe some of the features Pasleim wrote for https://tools.wmflabs.org/pltools/recentdeaths/ could be included.

Maybe a simple way to implement this could be a psn: triple with the string.

excellent. Works fine. Thanks.

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.

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.

Wikidata has most of that: https://www.wikidata.org/wiki/Wikidata:Database_reports/WMF_projects

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.

Somehow I like the summary. Anyways, here it is for future reference

Depending on the browser I use, I get "Javascript is disabled or slow to load or something went a bit pear-shaped." during the initial load. Could you increase the time-out?

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.

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.

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.

E27: scheme for lightbulbs . per https://en.wikipedia.org/wiki/Edison_screw

maybe items with Q5 could have separates stats.

I picked E55 from https://en.wikipedia.org/wiki/European_route mainly because it's a longer one that runs through Berlin (where WMDE offices are). E40 is a good choice too.

Some not so random suggestions:

new feature?

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

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" ;)

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.