Quotes and Minimum Information Units as Tiddlers

[Diego Mesa]

Hello all,

I have a tiddler of "Important Quotes" with a bunch of bullet points of interesting quotes Ive come across. I thought it would be nice to randomly pick one of these as display them. Immediately, I thought this community would say "They should each be in separate tiddlers!", which got me thinking, what would I title each of those tiddlers? Surely nothing meaningful, especially if I have several quotes by one person on the same topic. For example, "Emmerson on Nature 1", "Emmerson on Nature 2", etc. 

Question 1: How would you organize/solve this?

Question 2: The "minimum unit of information" aka Tiddler needs to have a title, but does this issue (I've had several related issues like this) expose that there is a deeper/smaller level of relevant information than the tiddler? If so, does this require a way to be able to section off/refer to pieces of a tiddler easily?

I can see fields being an answer to this question, but if so they are very deficient (cant handle multiple lines, not easy to make/edit, etc)

Best,

Diego 

[Matthew Lauber]

I would consider putting the quote (or the first line of the quote) as the title of the tiddler, the full quote as the body, and then including information like speaker, date spoken, location, etc, in fields.  I'd also tag the tiddlers as "Quotes" so it's easy to find all of them.  There's some plugins/filters you can use to get a random set of quotes, including my "Shuffle" operator, available at http://mklauber.github.io/tw5-plugins.  In this case, to randomly pick one to display I'd use the filter "[tag[Quote]shuffle<now>limit[1]" which does the following:  Grab all tiddlers tagged Quote -> Shuffle the provided list randomly based on the date displayed (so you get a different list order each time) -> Limit the results to the first item.

Matt Lauber

[Mark S.]

Yes, tiddlers have sub-parts.

Each tiddler can be thought of as a record in a conventional database, where the title functions as a title, unique id, and visibility flag. There is only one field that corresponds to a blob or text field (i.e. the text field). Real databases may have more than one blob field per record.

When organizing your quotes, perhaps try to figure out what is most important (date? author? topic?). Then organizing your titles like author - source - topic - date will give you a unique title that is human readable. BUT, you don't want to depend on it for searching. Probably.

For organizing your records further, you will want fields like "author", "quote-date" , "source", topic. You could, of course, put some of this information into the tags. Then color-code the tags for whether they correspond to author (blue), date (red), source (green). This has the advantage because so much utility is already built into the tag structure. You don't have to add templates or take additional steps. So if you have a tiddler tagged with "Emerson", you can instantly see all the other titles tagged with Emerson and with a single click you can go to the Emerson author tiddler and learn when he was born, worked, etc. I think this is the way I would go if I had only a hundred quotes or so to manage. More than that, and it's probably time to start thinking of using multiple fields and template patterns to apply. C Pa had a good overview of such a system here:

https://groups.google.com/d/msg/tiddlywiki/QUXd3kG1pTQ/RnYdTqLmAwAJ

Systems that depend on exact spelling of names and other field values can be very fragile. That's why for key fields like author, it might be best to assign an id (perhaps a number, or a standard abbreviation) and "link" by that. That is, your author's tiddler would have an id field (e.g. "rwe") and your quotes would have a corresponding author id field (author-id). That way you can nest list filters without causing confusion between Ralph Waldo Emerson, "Emerson, Ralph", "Emerson, Ralph W.", "Emerson, R.W." etc.

Those are my thoughts. Probably others will have better suggestions.

HTH

-- Mark

[whatever]

Hi!
You can take a look at my PersonalQuotePlugin (1) or Eric's QuoteOfTheDayPlugin (2, 3) for TWC to see how it could be done. You can then port those principles to TW5.

(1) http://personalquote.tiddlyspot.com/(2) http://www.TiddlyTools.com/#QuoteOfTheDayPlugin
(3) http://www.TiddlyTools.com/#QuoteOfTheDayPluginInfo

w

[Diego Mesa]

Thank you all for your response and suggestion.

For me, it seems like this brings into sharp focus the relationship between a minimum information unit (tiddler?) in TW and its requirements (title?). As Mark S said, I like thinking of a tiddler more as a database. If so, then it makes sense that we should have better ways to make and edit fields.

[@TiddlyTweeter]

Comments on fields ...

1 -- you can set TW to show them even if not used (and reveal them outside the editor if you need)

2 -- you can move them to a different position in the editing interface

3 -- its possible to order them (if you need a lot) other than a-z.

A fundamental problem is you can't have more than a line in one. In theory it would be possible to get round this but probably not worth the hassle.

[Diego Mesa]

I (respectfully) disagree completely on having fields take up multiple lines!

I think a combination of:

https://github.com/Jermolene/TiddlyWiki5/issues/1947#issuecomment-261960097

and

https://github.com/Jermolene/TiddlyWiki5/issues/3308

Would adequately address this!

[@TiddlyTweeter]

I respectfully think you are right. I didn't mean they should.

I meant it is an issue that one might want to store data with breaks. BUT I don't think its necessary the breaks go with it. Its more about the interaction with fields. Breaks can be re-constituted. The same issue applies to easier managing of arrays. 

[David Gifford]

I would have a new journal button that titles the journal down to the second.

[Diego Mesa]

Hey David,

This is a good idea - but my concern is not so much about how to create and ensure I have a unique title. Its more that these methods cause me to question the entire idea and meaning of a tiddler title under these circumstances  

[TonyM]

Just to add

Although a field can have only one line it can include <br> or a reference to a text field which is multiline eg {{othertiddler}}

[RichardWilliamSmith]

Hi Diego,

You have stumbled upon the deep philosophical conundrum at the heart of tiddlywiki (and maybe the whole world) and one of the "two hardest problems in computer science"

"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors"

Regards,
Richard

[TonyM]

Diego,

I have no such conumdrum, but I am looking at the edge cases, recently creating a unique field ID allowing references after a title change. One is unique for all time the other is unique at any moment in time. 

[PMario]

On Sunday, July 22, 2018 at 10:50:12 PM UTC+2, Diego Mesa wrote:

I (respectfully) disagree completely on having fields take up multiple lines!

I think a combination of:

https://github.com/Jermolene/TiddlyWiki5/issues/1947#issuecomment-261960097

and

https://github.com/Jermolene/TiddlyWiki5/issues/3308

Would adequately address this!

Having multi line filds will _not_ save your conceptual problems!

It will only introduce a plethora of new problems, that will signiffcally increase complexity.

-mario

[PMario]

On Monday, July 23, 2018 at 3:31:18 AM UTC+2, Diego Mesa wrote:

This is a good idea - but my concern is not so much about how to create and ensure I have a unique title. Its more that these methods cause me to question the entire idea and meaning of a tiddler title under these circumstances  

On Monday, July 23, 2018 at 3:31:18 AM UTC+2, Diego Mesa wrote:

This is a good idea - but my concern is not so much about how to create and ensure I have a unique title. Its more that these methods cause me to question the entire idea and meaning of a tiddler title under these circumstances  

When you start with TiddlyWiki, the tiddler title is "plain text". ... That's a good thing, because it's simple.

 - Plain text titles tend to be long. ...

 - That's why they may not fit nicely into TOCs

 - So we introduced the "caption" field. 

That's a good solution, but it already increases complexity. ... Users need to know about the caption field, and where the core UI automagically uses it.

eg: lists, tabs, ... and so on.

At the moment that's as far as "the core UI" goes. ---------------------------------------

Using plugins, you can go further. ... Using plugins is a "user decision" ... So advanced users know, what they are doing ;)

The uni-link plugin allows you to use the "caption" and "subtitle"-field to be shown instead of a [[tiddler link]] without breaking backwards compatibility. 

The alias-function goes even further, it allows you to reference a tiddler, by a completely different alias-name.

It abstracts away the "tiddler-title", by signifacally increasing complexity. eg:

 - a lot more documentation is needed

 - a new [[link syntax|?]] is needed ... (still backwards compatible)

 - new javscript code is needed to speed things up.

 - ViewTemplate extensions are needed to identify alias tiddler (see alias-footer)

 - new link-colors are introduced to make alias links visible for users

 - ...

At the moment that's as fare as uni-link goes --------------------

Creating a new theme can go even further: eg: slant-01 is an opinionated theme.

I use it as a starting point for my TWs (+ a lot of my other plugins)

 - It scales down the tiddler title in the view-template, to make it less dominant.

 - This allows me to use real h1-headings in the tiddler content.

    - This makes tiddler content more reusable, since the titddler title is decoupled from content.

    - Especially in combination with the new upcomming tv-adjust-heading-level variable it will be a "killer"

 - The tiddler title is nothing but an identifier anymore.

 - Once it is defined, it will never be changed again

   - having good tiddler names is hard !!!!!!

   - that's just a convention.

 - my tiddler titles need to be human readable (so UUIDs are a no go!)

 - my tiddler titles (should) create nice URL links.

   - eg: https://wikilabs.github.io/editions/slant-01/#01-slant-01-theme

   - this rule will be broken, if the use-case needs it!

In combination with uni-link and the alias function I think it's almost possible to eliminate tiddler titles.

BUT

to fully eleimnate them, the theme would need to be expanded quite a bit. ... Which is complex ;)

just some thougts

have fun!

mario

 

[PMario]

I did edit my previewous post: https://groups.google.com/d/msg/tiddlywiki/nJVYWLmxEmk/fv3T5UZUCgAJ

-m

[Diego Mesa]

I agree Mario - having multiline fields will not solve this conceptual problem - the problem being the relationship between titles and content in a minimum information unit framework.

The solution might not be multiline fields, instead its some way to specify and access some kind of "sub structure" of a tiddler. 

In a quote framework, I dont like the idea of having to come up with some unique title to specify each quote. I'd rather have a quotes database (tiddler) with rows (fields? bullet points in the text field?) that I can access outside that tiddler in a sensible way. 

Right now, I'd have to come up with some contrived way to have meaningful but unique tiddler titles, and use tags to specify that these are all really rows of the quotes tiddler.

[Jed Carty]

You can use a data tiddler to hold the quotes and just give each one a numeric key that you increment each time. That way you don't have to worry about names and you can have multi-line quotes. You can't tag them individually that way but you could have one tiddler for each group of quotes.

[PMario]

On Monday, July 23, 2018 at 6:10:14 PM UTC+2, Diego Mesa wrote:

I agree Mario - having multiline fields will not solve this conceptual problem - the problem being the relationship between titles and content in a minimum information unit framework.

The solution might not be multiline fields, instead its some way to specify and access some kind of "sub structure" of a tiddler. 

Yea, This possibility has been removed from TW5. I think this was a error. With TWclassic it was possible to transclude parts of a tiddler using headings as delimiter. ...

The syntax was {{tiddler-name##heading-text}} ... Which is now access to data tiddlers.

The problem with TWc was, that changing the heading-text broke the links !!!  Which caused a different set of problems :/

-------------

You are right, if someone creates an intrinsic structure, while writing prose text. It should be possible to access (transclude) parts of this structure into other tiddlers.

If we can reliably detect the "start" and "end-point" of the content to be used, I'd be in favour of using it!

-m

[Mark S.]

On Monday, July 23, 2018 at 9:10:14 AM UTC-7, Diego Mesa wrote:

In a quote framework, I dont like the idea of having to come up with some unique title to specify each quote. I'd rather have a quotes database (tiddler) with rows (fields? bullet points in the text field?) that I can access outside that tiddler in a sensible way. 

 

Right now, I'd have to come up with some contrived way to have meaningful but unique tiddler titles, and use tags to specify that these are all really rows of the quotes tiddler.

The problem is that you're getting hung up on "meaningful" names. They don't need to be meaningful. They just need to be unique. You can add meaning through fields, tags, sub-titles etc. Most "real" database systems depend on a unique ID field that is auto-generated and that has no relationship to the actual data.

That said, many of us would like to have the slices capability of the old TWC back. Most people don't start with short little paragraphs and then build up a document. Most people start with a document, and then create sub-sections within it that they want to refer to later. Five years on, there are still no core tools to make it easy to move or delete "documents" (tiddlers associated by tag  or field structure). Using tags to form a document means that you're using tags both for semantic and structural constructions, which results in tag-space pollution. In addition, there's at least a hundred bytes of overhead space required for every tiddler. In a system that is space-sensitive. But I digress.

Oh well. That's progress for you.  Have to keep up with the times. You can construct an entire document, or even an entire document from tiddlers. Search the group and you'll find a Bible where every single verse is in it's own tiddler. I would be surprised if your quote collection exceeded that.

Have fun

-- Mark

[TonyM]

Folks,

A friendly rant.

In any given structure, there tends to be an atomic smallest unit. In tiddlywiki this is the tiddler. This unit is so practical we tend to operate in this domain. In databases the minimum unit is a record, and people have to build larger structures such as client records (plural) to get any meaningful work done. This is not the case, in tiddlywiki.

Because the tiddler title must be unique, you always have a unique key to reference the smallest unit. This means you do not need to worry about unique keys.

If you want larger structures, especialy multiple multiline text fields you need to build them. I think this only comes as a supprise to people because the smallest unit is so useful.

Here are a few ways to extend a tiddler
Use the tiddler to tag a set of tiddlers
Transclude other tiddlers
Make "subtiddlers" such as tiddlername/subtiddler name
Create a chain of tiddlers, or list of tiddlers
Use datatiddlers

For example if you have multiple quotes for fred and others, do new here and call the tiddler quote, clone this to quote 1 and it to will be tagged fred. Do as many as you want, now you want quotes from Wilma, clone one of freds quotes, remove the fred tag and add wilma tag, now clone that for multiple wilma quotes. Here you do not care about the quote titles Only that the are unique and tagged with the quotee.

There is I believe no structure you can not build with tiddlywiki. And that is even before using alternate tag structures and custom fields.

The universe has being fine built by quarks, so to is tiddlywiki built on tidders.

Regards
Tony

[@TiddlyTweeter]

I should write sometime about how "software" can become more like music playing. I.e. you have a vast system of "instruments" in play, each of which has a history, a way of working.

The art is in the mastery, at which level you can construct the new, and not repeat.

Software is still fairly young. It is fairly crude. But the twin honing of both the "instrument" (code blocks) and intent of the user (player) is interesting and getting a bit clearer and useful without having to re-design the "instrument" every time.

Josiah

[Mark S.]

It will also be a short era. Once the AI start writing code, there will be no need for us coffee-fied wetware interfaces.

So enjoy the music while you may.

-- Mark

[@TiddlyTweeter]

The irony is if I "Up-Vote" that comment I will fall into its fallout.