Tags vs fields to organize selected poetry collection

,
#1

Background

I have a collection of selected poems stored in TiddlyWiki. Each tiddler is a poem.

I need to organize them by language, the poet’s name, and more criteria.

Like, I plan to have a list of poets that should be automatically generated from the tiddlers using filters. Clicking on a poet’s name should take me to a list of poems by that poet in the Wiki, which, too, should be done using filters.

Dilemma

How to add this metainformation to the tiddlers?

I can use tags and also fields.

Using fields

I can add custom fields, like

  1. poet
  2. lang

Then use these filters on these fields to create a list of content.

Using tags

I can also use tags. To differentiate between “types” of tags, I can prefix them. Like

  1. poet-Rudyard Kipling
  2. poet-Tennyson
  3. lang-English

Then I can use filters like [tags[]prefix[poet-]] to get a list of poets.

Tags let you change the sort order using drag and drop. That’s the only advantage I can think they have over fields.

Tags are visible by default. Fields, too, can be made visible using a custom template.

Question

I would greatly appreciate your insights and experiences in using TiddlyWiki for organizing collections of poems (or any similar content).

Have you found one approach to be more efficient or practical than the other? Are there any pros and cons that I might have overlooked? Additionally, if you have any alternative suggestions or creative ideas, please feel free to share them!

#2

I have a buildings database. The types of buildings (where I have a finite set) I use tags. For architects, builders and georeferenced locations I use fields. Perhaps that helps.

2 Likes
#3

Thank you @myfta

I looked around the forum and this is the schema that has come to my mind.

  1. Create a root tag, “poet”
  2. Make sure all poets’ tiddlers are tagged with “poet”.
  3. Create a root tag, “language”
  4. All language tiddlers, like “English” are tagged with it.

Then I just have to make sure each poem tiddler is tagged with correct tags.

This way, I get a hierarchy of tags without having to use fields.

There is also Mohammd’s Indexer plugin, which I am currently exploring.

https://kookma.github.io/TW-Indexer/

1 Like
#4

This schema sounds exactly right; it’s both simple to use and flexible. It doesn’t clutter the tag-space. You will probably also want a Poem tag, since not every tiddler is a poem.

If you find you have other lesser categories (publication-source, year, whatever), then those can go in fields that can be included in a poem template.

1 Like
#5

My rule of thumb has been this:

Tags are ideal for the kinds of info that call for the tag’s UI and convenience (tag-pill with drop-down access – EDIT: and/or built-in TOC macros, which work directly with tags). Is it likely, when looking at a poem by Kay Ryan, that you would want quick comparative access to a Kay Ryan “home” tiddler, and to all other poems by that poet? Might you want to make a TableOfContents (TOC) around everything within this category? If so, use a tag for each poet’s name (without any extra prefix). The “parent” tiddler of a tag is a super place to make a custom “home” template for each individual poet, with biographical info and/or a helpful overview of poems by that individual (perhaps including a TOC)…

But in order not to clutter the tag space, I try to tuck most other informational details into fields. As @Scott_Sauyet points out, you can always tinker with how field info is displayed within the tiddler. When info is in fields, it makes interface tweaks especially easy. This is one of the advantages of fields.

For example, suppose you’re going to print a set of poems to share at a gathering, and you want each page to include some info near the header about the poet, date, and the anthology in which the poem was first printed. You can customize the ordering and formatting of that info in a template, so it’s consistent and clean, present or absent, according to your tastes. Maybe the poet name is first, then the year is in bold, with the anthology name in italics on the line below… Things like that are so easy to do with fields, but not with tags!

For info such as date or language, you probably don’t often think, “Oh, let’s browse all the other poems there are in English!” or “let’s have a tiddler with info about the English language itself.” (Maybe you would do it for some other language? Still, it’s probably enough of a niche use that it doesn’t need to be “right at hand” within every tiddler in the way the tag-pills are.)

As others have suggested, rather than make awkward complex tag names, you can use a hierarchy among tags.

Last added note: Though “out-of-the-box” TiddlyWiki is performance-optimized around tags, pretty much any interface convenience available for tags CAN be replicated with filters that draw on fields in any way you need. Here’s a variant on toc that works with fields by @pmario, and @TW_Tones has been working on a filter-pill tool that can make something similar to tag-pill, but with any filter (and with further convenient options built in) – will link if I can find an official public version. A simpler version of filter-pill is also available, thanks to @arunnbabu81.

I think these developments are very important, because field-structure is ultimately more fine-grained and powerful than tags, for any project that is likely to grow in complexity.

3 Likes
#6

Following up, because this thread will come up when someone searches for poetry (or tiddlers with poems):

Poetry curators like @talha131 will surely be interested in this solution with thanks to pmario for recent post – link here to documentation at TiddlyWiki.com for getting line breaks in poetry to render naturally in TiddlyWiki. It’s simple enough that I’ll just paste it in below, tailored to poetry-specific use:

Assuming you have a poem tag on each poem tiddler, all you need is a tiddler tagged $:/tags/Stylesheet with the following:

[data-tags*="poem"] .tc-tiddler-body {
  word-break: normal; 
  word-wrap: break-word;
  white-space: pre-wrap;
}
4 Likes
Semantic linebreaks and TW discussion
#7

Oh, wow, that is extremely useful. I hadn’t noticed the data-tiddler-title and data-tags attributes at all. Those make it so much easier to target CSS!

1 Like
#8

In case you didn’t know this either :grimacing:, you can apply CSS based on a filter.

#9

I hadn’t thought through all the implications, but that’s a nice one. What would be nicer still would be if we had simple control of the generation of the DIV that holds these data-* properties, so that we could add additional fields we wanted to use and thus could do simpler styling with CSS.

Then I could imagine using that for, say, a ratings field on a 0 - 10 scale, with some accompanying CSS like this:

[data-rating="0"] .tc-tiddler-body div.rating {background-color: #ff0080;>
[data-rating="1"] .tc-tiddler-body div.rating {background-color: #ff9980;>
[data-rating="2"] .tc-tiddler-body div.rating {background-color: #ffb280;>
[data-rating="3"] .tc-tiddler-body div.rating {background-color: #ffcc80;>
[data-rating="4"] .tc-tiddler-body div.rating {background-color: #ffe580;>
[data-rating="5"] .tc-tiddler-body div.rating {background-color: #ffff80;>
[data-rating="6"] .tc-tiddler-body div.rating {background-color: #e5ff80;>
[data-rating="7"] .tc-tiddler-body div.rating {background-color: #e5ff80;>
[data-rating="8"] .tc-tiddler-body div.rating {background-color: #b2ff80;>
[data-rating="9"] .tc-tiddler-body div.rating {background-color: #99ff80;>
[data-rating="10"] .tc-tiddler-body div.rating {background-color: #00ff80;>