< Wikibooks:Reading room < Proposals < 2018
This is an archive of past discussions. Do not edit the contents of this page.
If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Categorizing individual pages

The time has come (I recommend) to work out how we want to do this; we want to get it right. Afaik we've wanted a good way to categorize individual pages for years, and were bogged down by a category infrastructure that served its purpose but got in the way of doing more; now that we've finished a year and a half of overhauling the existing infrastructure so that we can move forward (see previous thread), we don't want to get stuck with individual-page handling that doesn't do what we want and would take another humongous effort to fix. As background, before explaining what I envision and what we need to decide, here's what we now have:

We have two main kinds of organizational pages:

  • Book categories. A book category contains the pages of a particular book. For a book with main page <title>, the book category is Category:Book:<title>.
  • Subject pages. A subject contains books (not individual pages of books). Subjects are arranged in a hierarchy; each subject has one or two parents, except the ancestor of all subjects, Subject:Books by subject, which has no parent. Subjects are sort of like sections of a library. (The facility that subjects replaced, historically, was called "bookshelves".) The main page of each book, <title>, uses a special template, {{subjects}}, to name subjects that the book should be filed in (usually only one or two subjects, though more are possible; template {{subjects}} is internally quite complicated, btw, but the point is to hide all that so it's very simple to use). For each subject page Subject:<name>, books that file themselves in that subject belong to Category:Subject:<name>.

So the major categories have a prefix, either Book: or Subject:. That's really handy for keeping track of what kind of category you're looking at. I propose we do the same for the new categories that classify individual pages, and use a template on each page to file it appropriately. We need to make at least a couple of choices, to do this.

  • Should these categories be for books and individual pages, or just for individual pages?
I favor both, so that each category corresponds to a topic, making it analogous to an article on Wikipedia, topic category on Wikinews, etc.; thus, these categories would be natural targets for incoming wikilinks from other sisters.
  • What should these categories be called: what prefix should be used, and what template name for filing?
We could use prefix "Topic:" and template name {{topics}}; there's a danger users could get confused between "subjects" and "topics", though. I had considered "Keyword:", but it's been suggested that is too syntactic whereas I think we're after a more semantic classification; or "Tag:" but apparently that would collide with other usage on the platform (indeed, there is already a standard template called {{tag}}). So I'm having trouble coming up with a really good name.

On the technical side, it may make sense to modify the subject-hierarchy facility so that books in a particular subject can be automatically classified in certain of these more-inclusive categories (whatever they're to be called). --Pi zero (discuss • contribs) 21:02, 17 January 2018 (UTC)

First off, I definitely think that individual pages can be categorized on a by-page basis. Two examples immediately come to mind: let's say that you have a textbook on a broader topic that includes a page on a more narrow topic which itself also has a textbook (e.g. A page on Spanish morphology in a linguistics book but we also have a textbook[s] on Spanish). Another is categorizing pages by type, such as Category:Coding examples for all of the textbooks about computer programming which have individual pages which are just code or Category:Math worksheets, etc. I think there is definite value in these. To give an example of the how the latter is useful, imagine if MediaWiki changes how it renders code and there is a better way to make it visible or if someone builds a little tool for randomizing homework questions from a bank and we can deploy that tool across textbooks faster. As to your second question, I'm open to suggestions. Topic was what came to mind immediately but I agree that it seems too ill-defined compared to "Subject" (we had a similar issue with Topic/School/Portal on en.wv...) Plus, there is always the prospect that Flow/Liquid Threads will get deployed here and break a bunch of pages (as happened on en.wv). —Justin (koavf)❤T☮C☺M☯ 09:28, 19 January 2018 (UTC)
I'd wondered about the variety of namespaces at wv.

The examples of per-page categories you mention are more technical classes of pages; we could do those, certainly, and perhaps we should, but I suspect they're yet a different type of category (more of an "internal" sort of thing). I've had in mind semantic per-page-or-book categories that would be natural sister-links to/from Wikipedia articles etc. They would share some of the advantages of en.wn topic categories. Two advantages in particular come to mind:

  • Sister links, incoming and (of course) outgoing: Each Wikinews topic category has outgoing wikilinks to Wikipedia (almost always), to Commons (usually), and sometimes to Wikiquote, Wikivoyage, etc.; and of course the category is also a suitable potential target for incoming sister links from those pages. When I set those up, though, I rarely provide an outgoing sister link to Wikibooks, because I can't easily choose one target here that corresponds to the Wikinews category.
  • In-project wikilinks: The more a project uses project-internal wikilinks, the more it feels like a coherent project (in the old days, almost all wikilinks in the body of a Wikinews article were to Wikipedia, and that made Wikinews feel more like an appendix of Wikipedia than like its own project, whereas with a "real" project like Wiktionary or whatever, readers in the mood to explore can spend an extended browsing session just clicking from one page to another within that project without ever being dumped into another such as Wikipedia unless they choose to); so the project needs to have as wide a range of targets as possible. We have a template {{w}} at en.wn that doesn't just link to Wikipedia: it first checks to see if the target exists in Wikinews mainspace, and if so it links locally, otherwise it links to Wikipedia; which over time has allowed the project to feel much more coherent.
I deplore Flow, which I see as an example of the Foundation trying to go in diametrically the opposite direction from what is best for the volunteers and sisterhood (other examples being VisualEditor and some aspects of the implementation of Wikidata). At en.wn we use liquid threads (LQT) — only for our "opinions" pages, where readers discuss the topic of an article; we all "love to hate" LQT, but agree that for that one purpose it actually works better than wiki markup which most readers don't know (more's the pity), and we'd far rather LQT than Flow even for that purpose. My hope is that, with a bit more experience in how to effectively use wikidialog, we can implement semi-automated tools to assist wiki-markup-based discussions, making both Flow and LQT irrelevant. --Pi zero (discuss • contribs) 13:11, 19 January 2018 (UTC)
Visual editor isn't bad. It is useful for wikipedia, and perhaps only wikipedia.
Im thinking of categorization of the ones that are ok. Then others can be case-by-case. Some pages could be both marked.
Artix Kreiger (discuss • contribs) 14:37, 19 January 2018 (UTC)
Of VisualEditor: I consider WYSIWYG to directly undermine the human foundation of wikis, because (I maintain) wikis are a successful thing thanks to wiki markup, and people learn wiki markup by seeing how other people's wiki markup is written, but WYSIWYG is all about preventing the user from seeing how things are done underneath. --Pi zero (discuss • contribs) 14:55, 19 January 2018 (UTC)

Subjects and sections

  • One approach would be to rename the existing "subject" hierarchy to something else, and reuse the Subject: space for the purpose. It'd be a bother to do, but it could be done — it's a highly uniform mechanism and I understand it thoroughly — and once done it'd be done. There are nomenclature advantages for both kinds of pages:
  • The name "subjects" for the existing hierarchy has always been a bit odd; how about calling them "sections"? When explaining them I tend to say they're like sections of a library.
  • The non-hierarchical groupings of pages are organizationally much more like the physical dead-tree subject catalogs that were ubiquitous in public libraries prior to the twenty-first century. (The old dead-tree subject catalogs were superior, btw, to most of the electronic catalogs that have replaced them, because those old catalogs had been crafted by hand over time in a very wiki-like way; but I digress.)
--Pi zero (discuss • contribs) 21:05, 3 February 2018 (UTC)
That seems like a reasonable scheme. —Justin (koavf)❤T☮C☺M☯ 05:26, 4 February 2018 (UTC)
A snag occurs to me. Atm the standard template on a book main page to file it under subjects is called "subjects". If that gets renamed to "sections", the name may make people think of sections of the book. Perhaps a different name for the template... --Pi zero (discuss • contribs) 12:05, 4 February 2018 (UTC)
Such as {{library}}... ---Pi zero (discuss • contribs) 12:07, 4 February 2018 (UTC)
Brainstorming about terminology. This renaming can be done, but it's not a small operation, so once we commit to it we're likely to live with it for quite a while. In the old system, from before subjects, the root page was Wikibooks:Departments, and the subdivisions were called bookshelves. It does bother me some that "section" is so generic it can be used to refer to a part of a book. "Department" sounds to me like a top-level subdivision of the entire library. "Shelf" is good in that it has high recognition value as a grouping above the book level, but it sounds odd to have one "shelf" contained within another "shelf". We can't use "collection" because it's been preempted. --Pi zero (discuss • contribs) 14:19, 5 February 2018 (UTC)
Also worthy of mention: stacks. --Pi zero (discuss • contribs) 19:05, 5 February 2018 (UTC)
(Looked around a bit for a good picture of library stacks,
having spent many happy hours in such places.) --Pi zero (discuss • contribs) 19:11, 5 February 2018 (UTC)

┌────────────────┘
 I'm now leaning strongly toward prefix Shelf:, which seems likely to have instantly graspable meaning. Instant recognition of intended meaning seems to be the top priority for this. The oddity of one "shelf" being a subset of another is something one can just get used to. --Pi zero (discuss • contribs) 19:42, 6 April 2018 (UTC)

Whether to reuse Subject: for the other purpose, or use some other prefix, is a decision we'd have time to consider, while the renaming of the existing hierarchy from subject to shelf was underway. --Pi zero (discuss • contribs) 19:45, 6 April 2018 (UTC)
I agree if we merge them with Category:Wikibooks bookshelves. JackPotte (discuss • contribs) 20:51, 6 April 2018 (UTC)
@JackPotte: Afaik, the organizational information in the old bookshelves is contained within the current subjects hierarchy. What do you have in mind when you say "merge"? --Pi zero (discuss • contribs) 23:18, 6 April 2018 (UTC)
For example, to move Wikibooks:Greek bookshelf and Subject:Greek language, which have basically the same content, into Shelf:Greek language. In this particular case, there will be nothing but the history to get from the old bookshelf, but it may be worth comparing their contents, before closing this maintenance task, telling that the list is moving since 2009. JackPotte (discuss • contribs) 04:20, 7 April 2018 (UTC)
Ah! Yes, I see. --Pi zero (discuss • contribs) 12:56, 7 April 2018 (UTC)
I'm giving some thought now to details of page nomenclature. Presumably the categories — whose names are especially critical, as they need to be very lucid when they appear at the bottom of each book main page — would have names like Category:Shelf:Mathematics. However, there are at least three choices for the primary information page associated with that category (corresponding to the previous generation's Subject:Mathematics):
  • Shelf:Mathematics. This however is a root page in mainspace, with implications to think through carefully.
  • <bookname>/Mathematics, where <bookname> is the name of a book containing all the shelves; we might also want to have such a book even if its pages were to use prefix Shelf:.
  • Wikibooks:Shelf:Mathematics, which would exclude it from mainspace searches.
Some observations about these.
  • Because Shelf:Mathematics is in mainspace, it would be included in a general search of mainspace; that might be a good thing. One could do a search of pages with prefix Shelf: just as one would a search within a book. Because it is a root page in mainspace, it would become a potential result for the Random book navigation link; is that a good thing? We would want to wire {{BookCat}} to do the right thing, whatever we decided that is.
  • For a bookname, we would want something short and self-explanatory so it wouldn't be burdensome for the names of the subpages, but also something self-explanatory as a book name. For example, we wouldn't want to call the book Shelf because, although it might be tolerably clear what a page Shelf/Mathematics is supposed to be, it wouldn't be clear what a book called Shelf is supposed to be. The same goes for Shelves and Shelving, either of which one could just about imagine using as the name of a how-to book for home organizers. Likely the best choice, for standalone self-description, would be either Wikibooks Shelves or Wikibooks Stacks, which is slightly longer, and has no length advantage over putting it in project space instead of mainspace: Wikibooks:Shelves or Wikibooks:Stacks.
  • I'm not enamoured of using project space, as Wikibooks:Shelves or Wikibooks:Stacks. That would exclude those pages from a generic content search, and I'd rather include them in a content search.
One thing I would not want to do is to create a new namespace, such as was done for Subject:; that seems to me to just complicate the project infrastructure in a cumbersome way. --Pi zero (discuss • contribs) 15:48, 7 April 2018 (UTC)
My current inclination is to set up the pages in mainspace using prefix Shelf:, with {{BookCat}} wired to categorize them in a hidden subcategory of Category:Book:Using Wikibooks. The current template {{subjects}} would, I suppose, be replaced by (or, morph into) one called {{shelves}}. --Pi zero (discuss • contribs) 17:06, 7 April 2018 (UTC)
Personally I could treat several pages, but I don't want to choose for you if you intend to treat the hundreds of them, like you had done for the books categories.
Nevertheless, I would draw your attention on the facts that:
  1. a book containing all the shelves will take several hours to be built and synced, while been redundant of {{Category tree}}. That's why if it was just for me, I would rather delete the subjects and shelves pages (but not the subjects categories).
  2. a shelf books content will be impossible to print due to the server technical limits. For example, I couldn't automate Java Programming/Print version in Lua from the TOC, because of an overflow (and it's only 163 A4 pages long). Moreover, a few books had been cut to bypass the different resources limits, like Messier Index/Print Version/1 & Messier Index/Print Version/2. I notably remember a limit with Special:Book too.
  3. Wikibooks:Shelf:Mathematics would be counterintuitive because we don't usually publish the content into this namespace, and it won't be able to filter the shelves only. So a dedicated namespace would be the ideal solution for the search engine. We just have to include the "Shelf:" namespace in the default searches, and anyone will be able to uncheck it into Special:Search.
  4. But I don't think that a shelf in the random pages would be irrelevant.
Thank you for your attention. JackPotte (discuss • contribs) 13:43, 8 April 2018 (UTC)
Sounds like we're largely in agreement. One remark re namespace usage: agreed shelves are rather too contentful for project space, the same seems to me true for category space. It's one thing to copy the shelf presentations into categories (we do this now for subject presentations, and went to some trouble to make it happen), but that's not the same as having the presentations primarily reside there. --Pi zero (discuss • contribs) 00:23, 9 April 2018 (UTC)

┌──────────────────────────┘

One nuance, as I start to map out implementation details on this. At the very top of the soon-to-be-shelf hierarchy are a few pages that logically don't appear to be shelves. In the old bookshelf regime, the root was Wikibooks:Departments, and each page directly below it was a "department" rather than a "bookshelf". It's possible to make allowances for one "shelf" to be a subset of another, up to a point, but there's a scale at which it becomes really hard to imagine a "shelf" containing such a vast array of books. Even in the dedicated Subject: namespace, those top two levels of pages —the root and its children— are treated differently, in that they don't use {{Subject page}} and aren't supposed to ever have books directly filed in them. In the more recent discipline, there has been no enforcement of the principle of not filing books in the top two levels of subjects, as putting all those pages in a separate namespace naturally creates a sense of uniformity between what had been distinguished as "departments" and "bookshelves". However, in moving to give the lower echelons prefix Shelf:, one doesn't want to use that prefix for the pages at the two top levels. A likely solution is to treat those top-level pages as modules of a book. The shelves themselves would not be treated as pages of the book, though it would still make sense to file them in a hidden shelving category under the book category.

Re JackPotte's note that "a shelf books content will be impossible to print due to the server technical limits." If we want to generate a print version, it seems to me there should be no insurmountable technical problem generating a print version of the small book I'm describing, consisting of a splash page, departments page [maybe or maybe-not distinct from the splash page], and pages for the individual departments (but not the shelves). Although, I'm unsure whether we would care about a print version, since the book is something of an organizational device (reminiscent, in that regard, of "book" Engineering Tables). --Pi zero (discuss • contribs) 14:24, 15 April 2018 (UTC)

Additional functionality to comment/annotate

Hi, met recently with SvNicholls, Head of Humanities at Teesside University and she thought Wikibooks would be an excellent platform for online courses for students to contribute Open Textbooks on courses such as the Creative Writing MA. The one thing we discussed that might be useful is for the ability to comment (and respond to comments) on drafted pages as you can do on Google Docs and also how you can do in MS Word using their annotate function. Might be missing something but currently I could only see the ability to use Visual Editor's 'Comment' function exists but that this is fairly limited with comments only visible in Edit mode. I think having extra functionality around annotating and commenting on the text would be very useful on WikiBooks so am happy to create a task on Phabricator if others think this would be welcome.Stinglehammer (discuss • contribs) 10:38, 30 April 2018 (UTC)

@Stinglehammer: I would avoid VisualEditor if I were you.

Each page has a talk page; that's the primary forum for discussion of a given wiki content page. --Pi zero (discuss • contribs) 12:04, 30 April 2018 (UTC)

This article is issued from Wikibooks. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.