Philosophy & TW -- Title v. Content

[@TiddlyTweeter]

This is one of those offtopic/ontopic things.

The filtering mechanism in TW is very orientated to "titles first".

MY problem is that I often have TEXT that is more meaningful than its title.

The title is merely a placeholder (till later).

For instance ...

Title: "Working Title #247"
Text: "When Willowy goes for donuts the cicadas sing.
In harmony."

Title: "Working Title #595"
Text: "Willowy is an instrument of
Thomos The Third."

1 - How do I SEE all lines containing "Willowy"?

2 - How do I correct "Willowy" to "Willowby"?

You see here the irrelevance of "Title", yes?

Is TW a text-base or a title-base?

TT

[@TiddlyTweeter]

repeat for email

[Rob Hoelz]

They say that the tools you use can shape how you think about a problem, and I definitely think this is the case for TiddlyWiki and titles.  I think it's interesting you bring this up, especially considering all of the recent discussion around titles, linking, breaking links, aliasing, etc, but I've noticed this mostly in the area of search.

I've gotten into the habit of making sure my tiddler titles contain all or most of the keywords I'll need to find it again.  I've also created an alternative search results view that treats tags as titles for the purposes of search, and renders tag pills for any tags that contributed to a hit, like so:

I've been thinking about tweaking my search results further to include a "keywords" field, but I'm not sure if I want to go through the effort to maintain that field for all of the tiddlers in my wiki.

One big issue with the title-oriented nature of the search, in my experience, is journal entries - I tend to write a single journal entry per day, using headings to denote separate events.  One way I could alleviate this would be to use something like "2019-08-23 - TIL kubectl describe node shows pods scheduled to that node" and split my journal entries out into individual tiddlers, but again, the tool shapes my usage!

[Ste Wilson]

Not sure if it's what your looking for but danilos context search plugin might do the job..

[@TiddlyTweeter]

Yeah Ste, you are right that Danielo's context search is helpful.

And it is illustrative of the issue.

I often need VISUAL feedback of content (text field) matches. 

Whilst filters can be used easily to detect & match in the text field, its often quite convoluted to get more than the title back.

My main point was commenting that maybe we need to leverage more getting content back. 

That many users are not really working with titling predominantly.

TT

[@TiddlyTweeter]

Rob Hoelz wrote:

.... I've been thinking about tweaking my search results further to include a "keywords" field, but I'm not sure if I want to go through the effort to maintain that field for all of the tiddlers in my wiki.

Right. That is a good point. 

I think I'm mainly groping my way towards "what is the minimal route". 

Workarounds that add complexity that has to be maintained is not ideal. 

One big issue with the title-oriented nature of the search, in my experience, is journal entries - I tend to write a single journal entry per day, using headings to denote separate events.  One way I could alleviate this would be to use something like "2019-08-23 - TIL kubectl describe node shows pods scheduled to that node" and split my journal entries out into individual tiddlers, but again, the tool shapes my usage!

Right. The crux issue is getting something that works but has the least "shaping" possible. 

IMO maybe ...

• More examples of filters that "split" out and return content might help? 

That is not so transparent at the moment, especially if what you need returned is more than a single line of content. 

Thoughts

TT

[coda coder]

On Sunday, September 1, 2019 at 5:30:38 AM UTC-5, @TiddlyTweeter wrote:

1 - How do I SEE all lines containing "Willowy"?

In bk-tw I use Mark S's various split* filters for that, typically +/- 50 or 100 chars so I get some surrounding context. (Not sure your generation of bk-tw has that).

The macro/filter (edited for brevity and evolved a little since Mark wrote it) goes like this:

\define toc-get-text-context(find)
<$set name=f value='[title<foundTiddler>get[text]regexps[(?g)(\w|\s|\,|\.|\-|“|”|\`|\?|\x22|\x27|\/\/){1,50}$find$(\w|\s|\,|\.|\-|“|”|\`|\?|\x22|\x27|\/\/){1,100}]first[5]]'>

<h2 class="bg-text">Sections</h2>

<$list filter='[all[tiddlers]tag[toc]!tag[bk-doc]nsort[chapter]]' variable=foundTiddler>
<$list filter=<<f>> variable=text>
<p style="color:#666;margin-left:20px">...<<text>>... (<<toc-get-text-context-sv-link>>) [<$link to=<<foundTiddler>>><<foundTiddler>></$link>]</p>
</$list>
</$list>
...

[David Gifford]

Only slightly on topic...My title-vs-text issue has to do with alphabetization in lists, especially in Spanish. In English we don't put articles in front of abstract nouns. So a list of tiddlers of virtues might include Courage, Patience, Self-control, Wisdom. No problem. But in Spanish it would be La valentia, la paciencia, el dominio propio, la sabiduria. So an alphabetical list would end up ordering the articles (el and la). Makes it hard to find things in a list unless you use the list-search plugin, which sometimes I don't want to do.

At times I have added an 'order'field, added the term without the article and sorted by order or filename. And I have done it the other way around, where the tiddler title is Sabiduria, and a 'viewtitle' field is 'La sabiduría', and I hide the title and show the viewtitle field. That way searches and lists are in alphabetical order, and exporting to static avoids all the %20's, etc.

And, more on topic, I have often had systems that created tiddlers with datetimestamps, so that the title IS irrelevant, and I can use 'newhere' to generate individual notes on a topic that transclude to the parent topic. The problem of course is that searches turn up datetimestamps, and ordering thoughts in a topic requires opening them and giving them titles in a specific order.

Dave

On Sunday, September 1, 2019 at 5:30:38 AM UTC-5, @TiddlyTweeter wrote:

[Mark S.]

Hi Dave,

In database design you're not supposed to use a single field for more than one job. But TW has at least 4 jobs built into it's "title" field. And sometimes people

layer on additional tasks like "datestamp" Thus there is a constant source of tension, as people try to work around the problems caused by this structure.

Since "title" is the only guaranteed unique field, the "real" job of the title is provide a unique ID. So other fields should be used for display, system status, dates, etc.

But of course, the title field is right in front of you, so it's hard not to use it for display, search, status etc. But I digress.

Here's a lister that sorts your Spanish words (it removes the prefix, sorts, puts the prefix back on) :

<$list filter="[tag[spanish]removeprefix[el ]] [tag[spanish]removeprefix[la ]] +[sort[]]" variable="word">
<$list filter="[<word>addprefix[la ]tag[spanish]] [<word>addprefix[el ]tag[spanish]]">
 
</$list>
</$list>

When I first took Spanish, they told us that terms like "rr", "ll" and "ch" were to be considered as separate letters. I always thought what a night-mare

that must make for programmers working in Spanish. My understanding is that the Spanish Academy (excuse me if that's not the right term) has

changed those rules.

Thanks!

-- Mark

[David Gifford]

Thanks Mark! I wonder how sluggish that list filter would become after adding las, los, un, una, etc. with more than a few tiddlers...

Yes, the title field has too much weight on it. This saves time for many use cases and users, but there are many use cases where it gets in the way.

Blessings.

[@TiddlyTweeter]

Mark & Dave

I think that Mark S. understanding of this is pretty much unique.

His ability to combine filters is really outstanding.

He IS the documentation of practice needed ... can we write it up?

My tuppence

TT

[Mat]

David Gifford wrote:

Only slightly on topic...My title-vs-text issue has to do with alphabetization in lists, especially in Spanish. In English we don't put articles in front of abstract nouns. So a list of tiddlers of virtues might include Courage, Patience, Self-control, Wisdom. No problem. But in Spanish it would be La valentia, la paciencia, el dominio propio, la sabiduria. So an alphabetical list would end up ordering the articles (el and la). Makes it hard to find things in a list unless you use the list-search plugin, which sometimes I don't want to do.

Interesting problem. One way to go might be to use only the noun as the title of the tiddler but add the article by means of styling(!). The LinkStyle plugin would enable this. This way it would read e.g "la valentina" but the actual title is only valentina including when it is sorted. Using the linkstyle plugin you'd add a field:

linkstyle-before :  content:"la "; font-weight:300;

Some tweaking might be needed.

<:-)

[TonyM]

Folks,

I will just point out in English the titles of movies and books and the like, that start with "The" often ignore "the" in sorting. So this must have well established code patterns available. You could have the title without the prefix and have a prefix field that is added whenever displayed. Or you could lookup a list of titles that include the prefix and retrieve that for display.

Regards

Tony

[@TiddlyTweeter]

Right. In indexing the movie "THE FATAL JUNCTION" you really want it indexed as "FATAL JUNCTION, THE". Otherwise its gonna be in the basket with THINGIE 2. But it is inelegant to present the title "Fatal Junction, The" so the codicil "The" is best in a sub field and reassemble on presentation.

FWIW, some software specialised for movies, deals with this dynamically by sensing the lead "The" and discarding it in search orders. They let you define what "prelims" to discard on search. Its an interesting approach that works too. 

Thoughts

TT

[Scott Kingery]

Had some time to work with this last night in my Movie database/wiki. This code works to strip "The " off of movies that start with that and give them back to me with the rest of my movies sorted as I'd want.. Works well. Not as elegant as Mark's solution to add "The " back in but I couldn't make that work correctly.

<$list filter="[tag[Movie]removeprefix[The ]] [tag[Movie]] -[prefix[The ]]+[sort[]]">
 {{!!title}}<br />
</$list>

[Sycom]

Maybe do not display {{!!title}} but a set of filter on the currentTiddler ?

Sylvain
@sycom

[TonyM]

TT,

I am a bit late to this thread and have not read it all, May I respectfully suggest the value of the title is something you have chosen to set in your example, it is you who has diminished its value by giving it a numeric title. If you really wanted to number them you could do so in a separate field. Also in your example if the content of the text is "When Willowy goes for donuts the cicadas sing. In harmony" it could actually be your title.

Not withstanding what I have said, if the title is less important to you, or you want to automate this aspect so you do not need to "think about it" that is OK as well, you just need to recognise you are forgoing something when you do so. In this case you are using the title for its other primary function, it is operating as the "Primary key" to a piece of data. This still maps very well to TiddlyWikis philosophy, of the tiddler being the primary unit of information.

As I have stated before I think one of Tiddlywiki's key features is the "Primary Key" to data by being the title is "at eye level", "Directly in your face", "front and center" and all objects have this key. In other solutions the primary key is a document name, or a hidden numeric index. Titles allow anything to be an object even if it is one of many, and yes you can automate it.

Zooming out from titles you can use naming standards or tags and fields to group them, Zooming in you can use "subTiddlers", "Compound Tiddlers" and Data Tiddlers for smaller than a single tiddler. 

I am collecting techniques to enhance the use of "Compound tiddlers" which will help provision the automated tiddler, but in this case the subtiddlers will in effect have two keys, the top level tiddler and its childrens names.

Thanks for raising this important Question.

Tony

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote:

I am a bit late to this thread and have not read it all, May I respectfully suggest the value of the title is something you have chosen to set in your example, it is you who has diminished its value by giving it a numeric title.

You are right. The example, in a way, over-simplifies the issues.

 

... it is operating as the "Primary key" to a piece of data.

 Yeah. Title as "simple king". Point being to start with what is indexed already, not what fields do I need add.

For SOME purposes it makes most sense to treat the title as the index and present another field as the visible title ("caption" as my first choice).

A good example is novels where you have a simple structure. It is actually easier to have "title" as v01ch49pa17 (=volumn 1, chapter 49, pqragraph 17) than do it through another field. The user never needs to see the titel anyway. You'd likely use a macro to present only a chapter at a time, headed by a caption from the first item. Seems logical?

So. I'm, on titles just talking about a minimalist approach to certain types of (quite common) situations. This is not really news :-).

Text field in general is another issue. A dopo.

Best wishes

TT

[TonyM]

TT;

You say 

It is actually easier to have "title"  v01ch49pa17 (=volumn 1, chapter 49, pqragraph 17)  than do it through another field.

Whilst I think this can be an easy interim solution, because the key contains the structure, and fields are a little more complex initially, I do not think it the best ultimately. What is happening in this example is you are creating a compound key. You are storing multiple parameters or values inside the one key. It becomes harder for you to iterate each partial key and demands you parse the key. It makes changes and reordering difficult.

By separating these values into fields (or tags) you can actually apply multiple structures to the same information. Imagine publishing an abridged version on top of the previous volume, or an executive summary made up of an abstract of the underlying full document.

I have a vision of providing tools to tiddlywiki to make such structuring much simpler, supporting my own interest in tiddlywiki as a modeling environment helping users build sophisticated knowledge networks using fundamental database and organization techniques. There has being decades of great work done in this field that is not readily available to the general population but a relatively few principles can drive much more effective knowledge management. Most of this has come from professional and academic database designers. One of my treasured principals "Normalisation" that your example breaks is nicely written as;

The content of a record should be "related to the key(title), the whole key, and nothing but the key".

Tiddlywiki is  great platform in which to popularise such knowledge and methodologies then empower novices to take control of their own knowledge.

Regards

Tony

[@TiddlyTweeter]

Ciao TonyM

TT: It is actually easier to have "title"  v01ch49pa17 (=volumn 1, chapter 49, pqragraph 17)  than do it through another field.

 

TonyM wrote: 

Whilst I think this can be an easy interim solution, because the key contains the structure, and fields are a little more complex initially, I do not think it the best ultimately.

I agree, sort of. BUT everything depends on USE CASES. 

In the specific use case (which I neglected to spell out!)---it is for standard novels. The primary order for scholars would be "vol-chap-para". 

For the use case what is needed is bookmarking and cross-links. The more complex scenario you suggest (I think) is unneeded. 

I'm open to suggestions. But I'd need to see the final added value for the purpose of semantic analysis of sequential long texts.

Really what is needed, IMO, is a "TW Data Design Clinic" to advise on such issues interactively, case-by-case.

Thoughts. Maybe fantasies. 

But its good to talk.

TT

[@TiddlyTweeter]

Getting back to the OP ...

I wrote:

The filtering mechanism in TW is very orientated to "titles first".

MY problem is that I often have TEXT that is more meaningful than its title.

The title is merely a placeholder (till later).

I do think that tools that can do better analytic search  of the text field could be good.

At the moment its actually quite hard to get to real grips with.

Best wishes

TT

[PMario]

Hi TT,

My field-search plugin lets you select the different elements, that you want to search.

Text-only is a possibility too, if you want. Tab order can be configured too!

There is an: Intro Thread and an Intro Video in the thread.

have fun!

mario

[TonyM]

TT

I agree use cases vary. My answer to your challenge is the development of compound tiddlers because that's what you are building. See Evans recent sections prototype and my reply.

Tony