Talk:American Council on Germany/Young Leaders

From Wikispooks
Revision as of 18:12, 2 May 2023 by Robin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Robin, Could you do me a favor with this one, to save me some time?

  • Mass change/blanking the |constitutes=American Council on Germany/Young Leaders which are in each year, to avoid having them listed twice in the main folder.

and:

  • add a table in the main folder, listing all participants from all the years that has a biography.

Terje (talk) 06:11, 30 April 2023 (UTC)

The blanking would be easy, but since it is correct information, it would be good to keep it (from an SMW point of view) and instead only display it once. So how about a change to Template:SMWDocs instead? On a desktop, I think the page looks fine as it is, though I take the point that it's redundant without the descriptions set, and there's no point having the links duplicated.
I've been slow to change SMWDocs, since it takes a lot of CPU to rebuild all the pages, but I've been mulling this problem over for ages, and the more of these excellent name lists, the more it would be worth changing it to suit them. So I suggest instead we fix the duplication. Changing SMWDocs is more work, but it'll also fix this issue for WEF/Young_Global_Leaders and quite a few other pages. Here are three ways that we could remove the duplication but keep the semantic content:
  1. Currently, the examples lists all the pages with that |constitutes. Template:Examples could specifically exclude sub-pages
  2. Conversely, the subpage list could exclude pages which have |constitutes= to the parent page
  3. Or maybe the subpage list could be styled as something that could be expanded, so it was only there if people asked for it
A one size fits all solution is never going to be perfect for all the pages, but I'm keen to modify pages through Template:SMWDocs as a way to control the complexity/maintenance.
Actually, the bespoke tables are similar. They're not that hard to do, but they do involve a lot of cutting and pasting, and are less well updated/maintained than tables produced by SMWDocs. Although it isn't pretty, and is not without limitations, the SMW semantic language is very flexible, so we could devise solutions such as "if the page is a stub, or has less than 2048 characters of content, do this, else do that" etc. I can see we might want to branching on the amount of items in a table. I say "we", because while I can do the coding, I welcome suggests as for what to code.
The semantic properties are a composite of info put in the infoboxes & information it has calculated about the page. Click on the right hand blue RDF icon to see what is available to work with as regards semantic logic.
PARENTPAGE/YEAR has become a common standard for a lot of pages (events and groups), so extending Template:SMWDocs to list people who are known and attended a .../YYYY event -- or were a member of a .../YYYY group would probably improve a bunch of pages. Since it's people, dates/nationality/constitutes list/description could be good to have in a table.
One starting point would be to look at the bespoke stuff that already exists, with a view to replacing it with a standard subtemplate of SMWDocs; what we agree would look good on this group parent page will probably also improve the others in a similar semantic position. What do you think? -- Robin (talk) 21:00, 30 April 2023 (UTC)
When you start talking about the technicalities of SMW, I easily lose track of the meaning of what you say! I can give you input, but you have to word it simpler :) Anyway, I trust your judgement! Terje (talk) 06:57, 1 May 2023 (UTC)
I understand that SMW is not straightforward. I started a simple explanation of how SMW works, which ended up as at Wikispooks:Semantic Mediawiki#What is semantic data?, and I hope will shed some light on which is going on underneath the complex syntax of SMW, and the templates which let SMWDocs do its magic...
Assuming you've read that, let's look at Bilderberg/Guests/Visit count/6+. A look at the page source reveals that all the automatic content is generated by referring to a single property, Has bilderbergCount, which is displayed using Template:By Count. This template runs a series of SMW queries to look for triples of the form (*, Property:Has bilderbergCount, 100), (*, Property:Has bilderbergCount, 99), (*, Property:Has bilderbergCount, 98) ... and so on. Of course, to make this work, those triples have to be set (and be dynamically generated based on content). This happens at Template:SMWDefaultMarkup, which is run on each page, since it's included in Template:SMWDocs. This runs a semantic query looking for triples of the form ...
(Bilderberg/*, Property:Has participant, PAGENAME)
(Bilderberg/*, Property:Has witness, PAGENAME)
where PAGENAME is the name of whatever page the template is run on. Let's suppose there are 8 such triples. Rather than displaying anything, it creates a new triple and adds it to the page:
(PAGENAME, Property:Has bilderbergCount, 8)


So, in summary, it all happens using these triples, which are -- conceptually at least -- relatively simple. See here what they look like in practice for the American Council on Germany/Young Leaders page. It's in two sections:
(American Council on Germany/Young Leaders, P, X)
(X, P, American Council on Germany/Young Leaders)
The bottom set it refers to as "incoming properties". To save space, the "American Council on Germany/Young Leaders" part of the triple is not listed, which is why they appear to be doubles rather than triples.
Template:SMWDocs is basically just a bunch of if ... then statements about these triples, and it builds sections according to the rules specified in its subtemplates (see the SMWDocs page for a list). I'm looking for suggestions about which of these subtemplates need adjustment, and -- ideally -- also how to adjust them.
e.g. Template:Examples includes items which are already linked in the case of subpages or subgroups, which shouldn't be hard to detect by comparing the pagenames, or looking for triples that use Property:Has subGroup. Maybe such duplication is OK on some pages, since the subpage/subgroup links are near the top, but the examples are at the bottom. But on pages with minimal content these links appear close together, so it's redundant duplication. Can the computer tell which pages have minimal content?... Looking on that page shows that:
(American Council on Germany/Young Leaders, Has revisionSize, 764)

i.e. there is only 764 bytes of wikisource, i.e. not much content. So we could add a rule that for pages with (PAGENAME, Has revisionSize, <5000) then skip the duplicate links, but otherwise show them. -- Robin (talk) 18:03, 2 May 2023 (UTC)