Page MenuHomePhabricator

SDC: Suppress usual UI display of a property when its number of statements is very large
Open, Needs TriagePublic

Description

Certain use-cases may generate very large numbers of statements for a particular property -- for example, content annotation of certain old maps

As a user, if the number of statements for a property is very large, I would like the UI not to display the statements, but instead to advise me to try to view and edit them some other way

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

A bit more about the use-case. Early next month the external Viae Regiae project, with which Wikidata:WikiProject Early Modern England and Wales is closely co-operating, will start a mass participation effort to transcribe all of the places and placenames on several series of 16th and 17th century maps, like this 1576 Saxton map of Essex on Commons. (They will actually be using a higher-resolution copy, which we will be uploading).

As can be seen from the map, the number of places on it is very large; the process may generate of the order of 1000 located places per map, which we should like to record as Commons SDC, using either P180 "depicts" or some similar property, with qualifier P2677 "relative position within image".

The wikibase software should handle this number of statements per file-item. But the SDC user interface will not, Attempting to display 1000 depicts statements would make the SDC information page essentially unusable, if it did not crash altogether. The solution suggested is therefore to suppress display of statements when the number of statements for a particular property becomes very large, and suggest the user interact with them in some other way.

Use of SDC to display annotation information for images has been a core use-case for SDC from the start. T214405 ("Designing for structured image annotations") links some of the other tickets that have been raised for annotation in the past. The present ticket is not a duplicate of T214405 (on which work has currently been frozen), nor does it depend on it, but it probably is a blocker for it.

Uploading media files with a very large number of annotations will be a valuable stress-test for Commons wikibase, in particular per-page performance under such conditions. It will be extremely useful to be able to see how well the UI and supporting software can handle the editing of other statements on the file, when such a very large number of statements (albeit undisplayed) are already present on an item.

The ability of SDC to usefully handle annotations, sometimes very large numbers of annotations, is of critical importance to the GLAM sector's interest in the project. At the suggestion of @SandraF_WMF (now a civilian again as @Spinster), who previously carried out scoping work in this area, I am therefore copying in @FRomeo_WMF and @GFontenelle_WMF to this ticket.

Even though work on T214405 is currently frozen, the presence of images with very high number of annotations will be a useful resource for the further development and refinement of user-created tools in this area.

In particular @Lucas_Werkmeister_WMDE (in his private capacity as @LucasWerkmeister) has developed a tool as described at https://www.wikidata.org/wiki/User:Lucas_Werkmeister/Wikidata_Image_Positions to examine and edit/create statements with such P2677 "relative position within image" qualifiers (visual example), and also to export them into working IIIF manifests, to allow them to be viewed (and ingested for further editing) in external viewers such as Mirador (click on the 'speech bubble' icon at the top left of the image to visually display the annotations). In future the tool may also be able to work similarly with annotations attached to non-rectangular polygons using P8276 "region within image" (value syntax open to modification, for most flexible reusability).

The presence of these images on Commons, with high amounts of annotation information, will therefore be a useful test for developing our ability to read infomation in, find good ways to represent it as SDC, and then round-trip it out again as IIIF. This is the essence of T173346 and a fundamental technology path-finder for T261621 (Copying in @David_Haskiya_WMSE)

To be able to check the well-functioning of SDC in such cases, when very large amounts of SDC content of one particular kind may be present, it would be very very desirable that the SDC UI tab continues to be operable for other statements, even when a very large number of statements may be present for one or more particular properties.

I would suggest to first try how the SDC UI fares with large statement lists, e.g. on a test wiki (Test Wikimedia Commons hasn’t been deleted yet), and see what kind of problems emerge, before implementing a solution.

To date, the file with most depicts statements seems to be Nature Timespiral.png, with 128 statements. It seems to work reasonably well in Wikidata Image Positions; on Commons, Firefox showed the “a web page is slowing down your browser” notice for a bit, but eventually the page became usable.

If it aint' broken, don't fix it? Let's just see what happens and if anything explodes, than focus on fixing that.

A couple of follow-up things.

  1. There are now specific Wikiproject pages for the upload, at https://www.wikidata.org/wiki/Wikidata:WP_EMEW/Map_uploads -- please forgive for being rough and ready, the whole EMEW wikiproject is only ten days old
  1. Bert Spaan (IIIF maps SIG co-chair, https://www.allmaps.org , ex-NYPL, came to Wikimania Stockholm) is on a 'get to know' zoom call *today* (1pm London / 2pm NL) with the project and GIS co-leads from Viae Regiae.

If there is anybody working on WMF-GLAM-IIIF that this would be useful to, to attend as an observer, please email me for the link -- jpm.heald (at) gmail.com

Bert will be talking about what is possible using map-IIIF (ie the software he's developed: http://www.allmaps.org which could be a very useful replacement for the frankly horrible present version of Commons MapWarper), what VR should be looking to export to fit the map IIIF toolchain, and what they can import from map-IIIF manifests.