Generic Tags Fields: State Of Play

[Cade Roux]

I find myself looking to use this concept in my data mart data dictionary/user manual, as I want to have three types of tags for one set of generated tiddlers and three types of tags for another set of generated tiddlers and putting a prefix on each set and throwing them into tags field is kind of unwieldy and the filters will be really awkward.

Is https://ooktech.com/jed/ExampleWikis/GenericTagFields/ this the latest thinking on that or is there another plugin I should be looking at (or something that has made it to core?

Thanks,

Cade

[TW Tones]

Cade,

As far as I know Gentags is the state of the art for a plugin giving you alternative tag fields. 

Just keep in mind tags are a solution built into the core. 

• I for one avoid them to keep them free for ad hoc tagging. 
• Instead I tend to use my own fields and list fields that in many ways work not unlike tags if you want them to.
• See listops and other operators and widgets.
• Avoid the use of prefixes on titles, including tag names where practical otherwise you will find you need to parse the title to extract info.

For a small or for purpose wiki do what you want with the tags and prefixed titles, its only when you transfer tiddlers or grow wikis it may become a problem.

Regards

Tony

[Cade Roux]

Thanks, I have started using a field and I am struggling with list intersections, i.e. lists of items that are tagged both A and C:

I thought these would be the intersection and should be equivalent:

<$list filter="[[A]listed[my.field]] +[[C]listed[my.field]]" />

<$list filter="[[C]listed[my.field]] +[[A]listed[my.field]]" />

But not only are they not equivalent, they are not correct lists:

What am I not understanding correctly about the filter intersections?

Thanks,

Cade

[Mirko Richter]

Hi Cade,

you are understanding the mathematical "idea" of intersection correct BUT you are telling TW to throw away everyting that your first run outputted when you are using filter-operators that throw away the input (stated as "input ignored" in the filter operator) in subsequent runs, as [A] and [C] do. See also: https://tiddlywiki.com/#title%20Operator.

What you actually get is everything that lists C in your first <$list> and A in your second.

Regards,

Mirko

[Eric Shulman]

On Saturday, September 26, 2020 at 8:56:02 AM UTC-7, Cade Roux wrote:

I thought these would be the intersection and should be equivalent:

<$list filter="[[A]listed[my.field]] +[[C]listed[my.field]]" />

<$list filter="[[C]listed[my.field]] +[[A]listed[my.field]]" />

But not only are they not equivalent, they are not correct lists:

Try this:

<$list filter="[[A]listed[my.field]then[C]listed[my.field]]" />
<$list filter="[[C]listed[my.field]then[A]listed[my.field]]" />

"if [A] is listed, then test to see if [C] is listed"

"if [C] is listed, then test to see if [A] is listed"

-e

 

[Cade Roux]

Same issue.  Filtering only on C gives me the A/C, B/C items, then seemingly when adding the additional filter through the then operator, removes the B/C but ADDs an A/B item which wasn't in the first list.  I'm clearly missing something in the syntax, including where the runs are defined and the which brackets are used as logical grouping delimiters and which are used as parameter containers.

I'm using the comments here regarding using the listed operator to find tiddlers based on tags in a field https://ooktech.com/jed/ExampleWikis/GenericTagFields/#%24%3A%2Fplugins%2Finmysocks%2FGenericTagFields%2FReadMe

Current testing goal: List of all tiddlers which have all specified "tags" in a dedicated field "my.field" - i.e. my.field contains 'A' and my.field contains 'B' where A and B are tags (potentially containing spaces, so delimited in my.field with []_

Ultimate goal for context: Offer a filterable tiddler index of cardiovascular observations with dropdowns for Name, Structure, Context.  Each page of observations will have three fields: observation.name, observation.structure, observation.context.  A page which discusses e.g. Regurgitation and Stenosis observations might have observation.name="[Regurgitation] [Stenosis]", observation.structure="[Left ventricle]", observation.context="[History] [Findings]"

This is very similar to the case here: http://inmysocks.tiddlyspot.com/#%24%3A%2Fplugins%2Finmysocks%2FBookmarks%2FBookmarks%20by%20Tags except all three dropdowns would be present at all times and the tags would be restricted to the relevant field - this is why I broke it up into three dedicated fields, to avoid having to prefix different tags which only apply to certain dropdowns.

In this case, I would always be looking for my list to be the intersection of tiddlers matching all three dropdowns (ignoring any dropdowns set to Select All)

Thanks in advance.  I know I am rather slow wrapping my head around the filter syntax.

[Cade Roux]

I see what you are saying, but I thought it was starting with a default [all[]] operator.  I even tried putting an explicit [all[]] operator on the front.

Thanks,

Cade

[Cade Roux]

FWIW, to me it appears like the listed operator cannot be re-used in the run for some reason, even on a different parameter or different field.  Yet by itself just once, combined with tag does work.  I made my.field and my.field2 with combinations of A, B, C and X, Y, Z respectively and put alpha, beta, gamma in tags, and combining tag operator with listed works fine.  And tag filter intersection seems to work as expected: [tag[alpha]tag[gamma]]

Perhaps the clunky original plan of prefixing tags for the possible values of each field may have to be what I resort to.  e.g. [tag[name-some name]tag[structure-some structure]tag[context-some context]]

[Cade Roux]

That's my testbed file

[Eric Shulman]

On Monday, September 28, 2020 at 6:39:48 AM UTC-7, Cade Roux wrote:

FWIW, to me it appears like the listed operator cannot be re-used in the run for some reason, even on a different parameter or different field.  Yet by itself just once, combined with tag does work.  I made my.field and my.field2 with combinations of A, B, C and X, Y, Z respectively and put alpha, beta, gamma in tags, and combining tag operator with listed works fine.  And tag filter intersection seems to work as expected: [tag[alpha]tag[gamma]]

Perhaps the clunky original plan of prefixing tags for the possible values of each field may have to be what I resort to.  e.g. [tag[name-some name]tag[structure-some structure]tag[context-some context]]

I think you might be using the wrong filter operator!  Try using "contains:fieldname[value]", like this:

<$list filter="[contains:my.field[A]contains:my.field[C]]" />

(see https://tiddlywiki.com/#contains%20Operator)

-e

[Cade Roux]

OK, that appears to work.  I was working from the readme on GenTags.  I think to do what I need, I don't even really need the GenTags plugin anyway (I don't need to display the tags), and this wasn't relying on it.

Thanks,

Cade

[TW Tones]

Cade,

The contains operator is newer than GenTags. Also as I said earlier;

• Instead I tend to use my own fields and list fields that in many ways work not unlike tags if you want them to.
• See listops and other operators and widgets.

Tones

[Cade Roux]

Cool, is there also now a Core alternative now to the tags:field[] operator?  I am using that extension from the GenTags plugin to build my dropdowns of tags across a set of tiddlers.

Thanks,

Cade

[TW Tones]

Cade;

You can access the tags filed with the tag operators or 

as a field in its own right {{!!tags}} or has[tags] or has:field[tags]  these should work with gen tags fields

If you are asking about operators for gen tags specifically refer to its documentation. It adds a some operators.

Regards

Tony

[Cade Roux]

Yes, as you know, GenTags extends the tags operator to add tags:field[] so I can do something to get a list of tiddlers and then get the union of their tags:

[myfield[fieldcriteria]contains:myfield2[sometagcriteria]tags:myfield3[]sort[title]]

It's something like that which I am doing to build the various filter drop downs for my cardiovascular observations.  Each filter is based on the tags in a specific field and as one dropdown changes, the others change to only offer the tags in their field that are still available.

To do this, I rely on the tags:field[] operator from https://github.com/OokTech/TW5-GenTags/tree/master/core%20updates

But maybe the list or get operators can now do this?

[TW Tones]

Cade,

The fields you create through gen tags are just fields. But just like the tags field it is typically a list of titles, ie none, one or more titles, be they tiddlers or not.

 

Gentags supports the edit and use of these additional tag fields however even regular tags come with additional features are are only an example of what you can do with other fields;

To access and filter what we call list fields, including tags and Gentags fields, you can use the list operators, the listops widget, or you can split[ ] the contents of a list, and use search and contains against list fields.

You can also use enlist operator on a field to turn it into a list. You can count[] how many members in are in list (or list field) then use the range operator and the nth operator to extract a specific member in the list (perhaps one at a time)

The list ops features allow you to have a text field containing "-tagname +tagname" and more.

Other tricks can include using a select widget and setting a tiddler/field or one of a fields values to a selected title or fieldname. Then have this selected field value used in a subsequent list.

Perhaps you can ask some more specific questions as you continue?

Regards

Tones