Now that I am almost two-thirds of the way through the first round (of 3 to 4) of categorizing and tagging my 3700+ posts here it has become painfully apparent to me that a blog is not the appropriate storage area for many types of posts.
The blog allows for labelling content by categories and tags. Categories are broad conceptual terms while tags are for the many details. I have come to see that this classification system is designed to show readers what sorts of content is mostly found on a blog. That’s all very fine for some purposes, I am sure, but it is not what I want. My problem is that I have an “information science” background and I want to have a system that allows users to see fairly easily and quickly if there is a post here that might be of use to them. The categories and tagging system does not serve that purpose. It only (more or less) tells viewers the main biases of broad conceptual content that dominates a blog. Not the same thing by a long shot.
Categories and tags are fine for alerting web crawlers to what’s what when comparing or harvesting info from different sites, but they are not very useful for alerting viewers if there is something here that is of particular interest to them.
Some people have urged me in the past to separate my political content from my biblical posts so that I run two blogs. Ironically, it is the political side that lends itself more easily to the categories and tagging controls. A political blog focuses more on regular updates and is the sort of thing a blog is designed for. Though I also like to do background research posts on certain political issues and once again those sorts of posts are not ideally placed on a blog.
I am beginning to think that I ought to move, copy or somehow at least link the bulk of my and Tim’s posts to a static website instead — at least one which opens with a clear table of contents that narrows down to multiple indices.
I did have in mind a Topic Map (TAO) — I thought that would be ideal: it would, I thought, enable all sorts of cross-searching of terms, linking concepts, drawing out all sorts of answers along with related possible spin-off options. But I see that Topic Map technology has passed me by and is no longer a bee’s knees thing. I am out of touch and must catch up to see if there is a stable replacement yet available.
But that’s not going to happen before next week, maybe more than a year, even. My first task is to complete the first round of doing a “rough and ready” classification of posts with a crude category and tagging system. It will have many overlapping and grey areas but those will be refined in future iterations and refinements. Going on to 4000 posts is a lot for one person to sort through, but it has to be done, and no point putting it off any longer — as I have been doing for too long already.
Latest posts by Neil Godfrey (see all)
- Varieties of Atheism #2 - 2023-05-21 02:18:55 GMT+0000
- Varieties of Atheism - 2023-05-20 07:10:56 GMT+0000
- The Troubled “Quiet” before the Jewish Diaspora’s Revolt against Rome: 116-117 C.E. - 2023-05-10 07:58:29 GMT+0000
If you enjoyed this post, please consider donating to Vridar. Thanks!
24 thoughts on “A Blog is Not Ideal for Vridar Posts”
I’d like to nominate you for Sainthood 😉
Back to 3×5 cards.
Perhaps use a “wiki application” with open talk pages for comments and locked pages for content. (“List of wiki software”. Wikipedia.)
• “PmWiki”. Wikipedia.
• “PmWiki | PmWiki / PmWiki”. http://www.pmwiki.org.
• “PmWiki | Cookbook / BlogIt”. http://www.pmwiki.org.
I’ll have to look into the wiki option. It won’t be done tomorrow but I’ll keep it in mind when I am ready to do something serious.
“How to Export a WordPress site to Static HTML”. qSandbox Blog. 9 October 2018.
• Since a Wiki does not fully support “HTML tags” but rather “wiki markup”, there is a possible conversion issue.
“PmWiki | Cookbook / ConvertHTML”. http://www.pmwiki.org.
Well, I’ve more or less completed the first stage of properly organizing the 3715 posts now. When I see a mess to be cleaned up my approach is usually just to drag everything out and dump it in one big pile so I can start with a clean space and then put back from the pile bit by bit or chuck bits out.
I’m about to start that second stage now. That means first of all working on a way to bring some sort of consistency to the tags or subcategories that need to be made into tags. Wheh!
It’s the nonhierarchical and alphabet order (as opposed to some sort of conceptual/ontological order) of the tags that bugs me. I am too used to working with standards of information control that have emerged through years of standardization — but this is the internet age and i know i need to adapt, damn it — at least do the blog thing according to proper blog ways for now.
Cf. “Plugins categorized as index | WordPress.org”.
The hard part I am facing at this stage is establishing consistent and useful tag terms – not so easy across such a large number and range of posts. Once the terms are worked out the rest will be easy by comparison.
I think at a reasonable pace, allowing me to have a sort of normal life in the real world, this task will take me about a year to complete. I’ve measured what’s involved and I’ve made a year my target date. Let’s see what happens.
“Categories”. WordPress Support.
“Tags”. WordPress Support.
“Best Practices For Using Categories And Tags In WordPress”. Elegant Themes.
“How (and Why) to Convert WordPress Tags from ‘Flat’ to ‘Hierarchical'”. CSS-Tricks.
I understand what categores and tags are. I’m talking about consistency of terms for tags. Easy on a small scale, harder on a large scale.
WordPress dev here. Not sure if you missed the bit in db’s post at the end where it shows how to /change/ WordPress Tags to be hierarchical.
Once you have categorised and tagged (perhaps with nested tags as per db’s tip) posts to your liking, you can pull them out of the database either statically (hand write lists of links to posts) or dynamically (by tag or category) to make what looks more like a static website.
There is no requirement in WordPress to organise content by date. The option is always there to present your information by topic. In fact you can do both, at once, with the same set of data.
There is absolutely no need to make a static website, and it seems to me that that considerable effort would be a waste. It is simply a matter of changing the presentation of the information you already have. WordPress can do it.
There is also a custom fields option in WordPress, which allows you to add arbitrary text data fields to each post.
A plug-in called ACF (‘advanced custom fields’) is what devs most use to easily create and organise this data.
You can then use this data in the back end (e.g. use it as an add-on to categories and tags, perhaps by designating posts as being part of a series) or front end (by displaying the data directly on the page).
Thanks, will look into this.
Hey, I was overtired with recent comments. Approaching it fresh today and it won’t take long using the batch edits instead of going through each post one by one, stupid me last night. My main issue is deciding the appropriate terms right now, and deciding on parameters that each category should cover
I have much to learn. Thanks.
Have you considered a searchable database affiliated with your site. Find what you are looking for in the database and then search for it on the site by title.
We do this crudely with a searchable text file of all of the issues of our magazine.
• The WordPress back-end database is accessible by admin.
“WP_Query Arguments: Categories and Tags”. Code Envato Tuts+.
• Ideally the WordPress front-end would feature a plugin for a reader’s SQL query (per post: tag; category; keyword; etc.) that returns matching posts.
“Include Category and Tags in the WordPress Search”. rfmeier.net. 2 August 2013.
That’s another option to consider. I rely on similar processes regularly, but I think there are certain weaknesses that concern me with systems that are strong and good in other areas. Still thinking, thanks.
• If the blog is exported to static html and then uploaded to a standard html web server. It is possible that the WordPress tag and category info may lost.
A solution is to manually append an XML string to the blog post/page. The XML string would recapitulate the WordPress tag and category info and since it would be exported as part of the page. Then it could be used by a program to create a tag and category page on the new web server.
NB: In theory, this would also allow a program to create a tag and category page by crawling all the posts on the current blog.