Rewrite remaining entities layouts

[jum-s]

This PR propose to rewrite in Svelte the following layouts:

1. Publisher and collection: Pretty straight forward, as they were already on main branch but commented out (cf. 30ab9d7b3). Notes: WorksBrowser now displays editions. Publisher layout displays a collection section AND can filter by collections ; it looks like a duplicate at first sight, but the collections section does display links to collection layouts which adds some discoverability, and the collections facet allow to quickly scan a collection without having to change context by loading the collection's layout. Note: there are no facet filter on those layouts, since server search has not indexed editions yet.

2. Article as type of entities to display in authors layouts and as a standalone layout (95edc0dc8). Also straight forward, one may find recent and rich claim articles for testing with this query. Thought: read journals (Q5633421) as publisher type to be able to use advanced options on articles (cf server issue #254).

3. Subject/genre/movement aka claim layout (867275a18). Quite a chunk since ramifications are numerous. I couldn't a method to explore all possible paths, so this is a best effort. [New feature] Claim layouts have now some relatives entities list section based on their available properties (ie. /entity/wdt:P921-wd:Q10814056) (1dbc096aa). [Implementation token] introduce P69 (educated at) as a human relative property, hence humans in WorksBrowser (see below).

Notable to know before review

• Works browser is already displaying works and series together (ie. claim layout entity/wdt:P1433-wd:Q90) but ideally it should display any entity type (publishers and collections now displays edition, and below describes introduction of humans in works browser). Which leads to renaming works_browser -> entities_browser? (not done in this PR).

• Expanding works browser to subject notably implied:

  • having humans in works browser: which is recovering claim layout displaying humans (ie. entity/wdt:P69-wd:Q13371). Sidenote: adding P69 to subjects RelativeEntitiesList properties (commit 8578932d1) also adds an P69 claim layout link on on some subject layout (ie. /entity/wdt:P921-wd:Q13371) (commit d2ccffb5a)
  • possibly handling more entities than an author layout, up to server limit (1000). One may want to load those pages for performance testing: entity/wdt:P840-wd:Q90 entity/wdt:P136-wd:Q1004 entity/wdt:P921-wd:Q13371 (P69 RelativeEntitiesList contains 1000 entities)

Other testing claims layouts used to create this PR

Valid claim layout: entity/wdt:P135-wd:Q7081 entity/wdt:P136-wd:Q3238422 entity/wdt:P674-wd:Q216605 entity/wdt:P674-wd:Q830561 entity/wdt:P737-wd:Q76 entity/wdt:P1433-wd:Q220 entity/wdt:P2679-wd:Q17790

Invalid claim layout: entity/wdt:P4033-wd:Q216605

Empty claim layout: entity/wdt:P921-wd:Q3205273

One may find useful to have an overview of properties used by inventaire works : query

Server side possibility: open P135 (movement) to works ?

An "Add to" button could be added to work browser list element, but this component currently doesn't have editions populated, thus postponing until a better related entities cache is in place.

Idea: Author strings, which are redirected to a inv search query now, could be thrown to https://author-disambiguator.toolforge.org/names_oauth.php?doit=Look+for+author&name=H.%20L%C3%BCdeke (as Scholia is doing)

Related issue: #150

[maxlath]

The works browser on master uses a width ratio of 1 serie width = (2 works width + gutter width):

This was lost in this PR:

Which leads to messy alignments, in particular when works and series are displayed together in a list: example here with /entity/wdt:P921-wd:Q6206

[maxlath]

What about replacing with

and for sections that contain elements, have this button at the bottom, and remove the MissingEntitiesMenu

[jum-s]

The works browser on master uses a width ratio of 1 serie width = (2 works width + gutter width)

done. Padding on li element in works_browser_section has been deleted from commit named works browser: add action button when table mode display

[jum-s]

What about replacing with

and for sections that contain elements, have this button at the bottom, and remove the MissingEntitiesMenu

Im all for it, but I would prefer to leave it for another PR, this one is already big, it would also make it cleaner, since it will modify already merged layouts (authors, publishers).

[jum-s]

remaining todo, but i would like it to happen in other PRs:

• rename works_browser -> entities_browser
• remove MissingEntitiesMenu
• cleanup old layouts
• add series facets on author layout (and filter it like in c97e3109f "display the collection if the selected facet is this collection")

[jum-s]

Todo before prod: limit amount of sub entities to 1000 for large layouts (ie. Nature)

[maxlath]

Regarding, 7499193 I would be for reducing the limit to 200, and wait for a better solution for pagination. I'm afraid that above that level it might make some browsers crash (typically on not so recent smartphone), and that even users with more powerful machines will have to wait a lot, especially to fetch articles items, which are less likely to be cached by the server.

Ideas for after this PR on pagination: build facets on the server (like with inventory-view for the inventory browser), and only display the first entities of the facet-filtered list, fetching more on scroll. Ideally, we would also cache those built facets on the server, but just like for inventory views, that would require to figure out a reliable way to invalidate that cache. An idea to do that could be to have a reverse index allowing to easily list al the cached facets that should be invalidated when a particular claim is modified.

[jum-s]

To be considered : for people wanting facets anyway (typically a researcher would mind waiting for 2 hours, if necessary), there could be a link with a query parameter (ie. &allFacets=true) in a warning to reload the page with facets. But the problem is that inv server wouldnt like to cache the thousands of articles, would it?

I modified the limit to 200 in aa124b7abb along with a lengthy commit message composed of the 2 comments here.

[maxlath]

I preferred .works-browser-section background before this PR:

Before:

After:

Is there really a need for another level of boxing?

[jum-s]

I preferred .works-browser-section background before this PR:

Done in 752975971f0fc2f424ca9aabb08e307796661f72

[jum-s]

I modified the limit to 200 in aa124b7

Are we sure about 200 ? Its kind of low, as some prolific authors dont have all their works displayed (ie. /entity/wd:Q34981, I. Asimov). 500 sounds more adequate? Another possibility would be to limit by entityType (ie. 200 for publishers, subjects, genre and no limit for the rest) (?)

[maxlath]

Another possibility would be to limit by entityType (ie. 200 for publishers, subjects, genre and no limit for the rest)

yes, let's try that

[jum-s]

Another possibility would be to limit by entityType (ie. 200 for publishers, subjects, genre and no limit for the rest)

yes, let's try that

done in 3c9509b2194e1e767d346eb7bf0fa8f3384f35a0

[maxlath]

yeah advanced subject browsing! :heart: :tada: