I’ve built a template applied on all pages tagged with author to gather their books in a Shiraz Dynamic Table.
I’m extracting the author from the page in a variable <cauthor> (current author).
I’ve added a search field in the dynamic table as per Shiraz’s relevant tutorial.
I’ve tried adding the <cauthor> value in the paths used to avoid crossing the streams give each Author page an independent search state, but it didn’t work. Without my failed hack below, all open Author tiddlers share the same search terms.
I guess it’s a usual case of wrong use of brackets? As I see it in the More → Explorer sidebar, <cauthor> is interpreted literally and becomes a static part of the resulting path.
<$list filter="[all[current]tag[author]]">
<$set name="cauthor" value={{!!title}}>
!!! Works by ''<<cauthor>>''
Filter and search in table
<$edit-text
tiddler="$:/temp/dtable/<cauthor>/search"
filed=text
tag=input
default="" />
<$button
set="$:/temp/dtable/<cauthor>/search"
setTo=""
tooltip="clear searchbox">❌</$button>
<<table-dynamic
filter: "[contains:author<cauthor>search{$:/temp/dtable/<cauthor>/search}]"
fields: "tbl-expand title tags"
stateTiddler: ""
editButton: "yes"
pagination: "yes">>
</$set>
</$list>
I tried your solution but it doesn’t work unfortunately. The initial Dynamic Table is empty (it had proper results before trying to implement the cauthor part).
Τyping in the search field does create the appropriate temp tiddler under $:/temp/dtable/$(cauthor)$/search but it doesn’t seem to used in the Dynamic Table which starts off empty and remains empty. I guess something is wrong in the table’s filter query:
\define searchAuthor() $:/temp/dtable/$(cauthor)$/search
<$list filter="[all[current]tag[author]]">
<$set name="cauthor" value={{!!title}}>
!!! Works by ''<<cauthor>>''
Filter and search in table
<$edit-text
tiddler=<<searchAuthor>>
filed=text
tag=input
default="" />
<$button
set=<<searchAuthor>>
setTo=""
tooltip="clear searchbox">❌</$button>
<<table-dynamic
filter: "[contains:author<cauthor>search<searchAuthor>]"
fields: "tbl-expand title tags"
stateTiddler: ""
editButton: "yes"
pagination: "yes">>
</$set>
</$list>
Your original filter used search{...} (note the curly braces). This means “search for matches using the text contained in the specified tiddler title”.
However, the current filter uses search<...> (note the angle brackets), which means “search for text matching the specified tiddler title”.
What you need to do is to first get[...] the contents of the specified search input tiddler title, and then use that value to actually perform the search. Perhaps something like this will work:
The other idea I had was to keep the search string in a field of the author tiddler. They would be separated by definition and I would not clutter my temp folder with extra tiddlers.
Still, in case it’s helpful: You seem to be doing a bibliographic database…
If you have lots of tiddlers, you may find it convenient to make automatic templates show up at the nodes that correspond to authors — rather than having to create a tiddler, and tag it author, in order to get your dynamic table. This is a technique talked about elsewhere, most recently as [“virtual tiddlers”] …(Virtual tiddlers)
I have thousands of biblio records for my personal library and other research-resources of interest. Building on the core bibliographic functions of refnotes by @Mohammad, I’ve been steadily adding features:
In the tiddler for a book or article, all author and editor names display as links.
Even if there’s technically no tiddler for that author/editor name (The tiddler is “missing”), we see a dynamic table for books authored and edited by that person. This is accomplished with a template (with cascade conditions if you want to get fancy).
Extra stretch: I’ve defined custom functions that begin to cope with the fact that some imported biblio records show names as “Nussbaum, Martha C.” while others come in as “Martha Nussbaum (ed)”… Would be nice to maximize recognition of that same person “on the fly” across these differences (without needing to clean up first), so I’ve made quite a bit of progress on that.
Here’s a landing page where you can click on some author names to see what else shows up under the same and similar names (Perhaps additional aspects of the site will prove helpful while you’re developing your wiki):
A solution like this doesn’t prevent you from making tiddlers for authors of interest (where you can add notes, biographical data, etc. — in addition to accessing dynamic tables), but it speeds up the “intertwingularity” of a biblio-oriented wiki.
That’s a nice idea, I’m already applying templates to missing tag tiddlers on my Bookmarks TW to show a list of bookmark tiddlers tagged with the current tag. I’ve defined a view template that opens with:
and is thus applied regardless of whether the tiddler is missing or not. It makes sense to me because when it comes to bookmark organization, there are way too many tags to keep track of them. On my bookkeeping TW, the authors are relatively few and I tend to manage them by hand. I might apply it there too, I’ll see.
I really like your book-thumbnails page, I think I’ll steal it. I’ve been thinking of having a page with a random, limited selection of book covers, as a source of inspiration and something to resemble the physical, all-you-can-see bookshelfs of yore.
As a final note, I’ve managed to transform it to using current tiddler fields instead of generating separate temp tiddlers. I ended up with a simpler code that does the same thing, without relying on additional external tiddlers.
I’m quite proud that I’ve wrestled through all those different bracket combinations, big shout out to https://pesky-brackets.tiddlyhost.com and to everyone here who helped me through this
Current code:
<$list filter="[all[current]tag[author]]">
!!! Works by ''{{!!title}}''
<$edit-text
field=searchTerm
tag=input
size=50
placeholder="Search in title, text, tags" />
<$button
set="!!searchTerm"
setTo=""
tooltip="clear searchbox">❌</$button>
<<table-dynamic
filter: "[contains:author{!!title}search{!!searchTerm}]"
fields: "tbl-expand title tags"
stateTiddler: ""
editButton: "yes"
pagination: "yes">>
</$list>
I expect that what I’ve done with hours of squinting barely holds up to what you would do with a half-hour of methodical coding. But here’s the current state of the custom functions.
Generally, the only time methodical coding is fast is when you already understand the rules and can easily describe them. The real work is in discovering and formalizing those rules.
This seems to me a difficult impossible problem to get entirely right. I’m on my phone now so won’t be readily able to look at the implementation, but I look forward to seeing what you’ve done.
The varieties you show for the relatively simply Martha C Nussbaum point to how many issues there might be for de la Cruz, or for Willard Van Orman Quine. Just that “Van” would be a headache, given the difference in meaning between Dick Van Dyke and Van Morrison. And if Martin Luther King, Senior also published…
I’ve thought about this problem several times in the past, and always gave it up as a thankless job. To make up for that, here’s my own thanks to you. I look forward to reading the implementation.
I did get a chance to look at these, finally. They look great. It seems that you already have the components for your latter two wish list items, and a good part of the way toward the first. The biggest open issue I see is last name particles — “de”, “la”, “de la”, “van”, “van de”, “von”, et al. But that is very much a non-trivial problem.
I don’t know if honorifics such as “Dr.” or “Lady” are used in academic citations, but they might also cause issues on the first-name side. Also interesting is solo names: Cher, Madonna, Prince. For classic names like Socrates, it seems straightforward to understand that as a last name, with no first. But for these singers, those solo names are in fact first names. Hmm.
I’m not sure whether you’re trying to normalize these on import. That is, would you want an authors field derived from bibtex-author, with an entry like [[Dewey, John]] [[Nussbaum, Martha C]] [[de la Cruz, Sor Juana Inés]]? Or would you want these displayed only on a render of the bibliographic entry that includes them? I see some real advantages in the former—if your workflow permits it—allowing you to do fuzzy matching and gathering together all the Nussbaum, Martha, Nussbaum Martha C., Martha C Nussbaum, etc. records into a single place. But that won’t work for large bulk imports.
Here I split the difference with the “clean the data first” norm.
I’m not going to clean up all the “Lastname, Firstname M.” vs “First Middle Last” variations before using the data, and I’ll keep a short list of suffixes and prefixes that circulate commonly enough as red herrings for name recognition. (with et al being much easier to deal with in some ways, but more difficult in other ways!)
I want to reduce the need to “normalize on import” partly because I’m thinking of a community edition that might be taken up by folks whose needs and data-sources don’t match whatever my preferred standardization might be. (And in particular, I think the Lastname, Firstname M. pattern is more informative, but sometimes we simply do not know how to parse a complex conventional-order name into that structure, and my first mandate is “Do no harm” to the data. So, the less invasive path is to try for fuzzy recognition that accommodates First Second Third (but where does surname start?) mysteries, and to aim for a friendly solution for folks who don’t want to commit to a big initial clean-up.)
But this 98%-good-enough approach means I’m committing to a hand-manipulation of a string like “Sor Juana Inés de la Cruz” — once I do understand which parts should count as the last name (replacing spaces within a last-name-string with non-breaking-space characters). This feels ok on case-by-case basis…
So far my only routine “clean up on import” is to look for multi-author / multi-editor fields that separate with commas between names (rather than semicolon or and), because getting a function to parse the three comma-separated names in Gavin Van Horn, Robin Wall Kimmerer, John Hausdoerffer (a real editor list as it appears on at least one of my books) — while also preserving the ability to recognize Lastname, Firstname strings! — is a nightmare I’d rather postpone indefinitely.)
I have not yet tackled the single-name Plato problem (beyond pasting in a zero-width first initial), and of course I should solve that next, given my field! I’m much less worried about merely honorific titles (Dr., Lady), since if they’re not part of the actual name, they can be deleted without harm to the bibliographic integrity of the record. Deleting the Dr. from Dr. Martin Luther King, Jr. (if I ever found an imported record that specifies the author that way) is arguably not dropping any part of the name, while dropping the Jr. would be doing damage to the integrity of the name data.
Another problem I haven’t begun to consider is how an author tiddler (a real tiddler, not just a virtual template!) could leverage an alias field (and then use template to draw seamlessly on associated data) so that someone who published under multiple names (especially multiple last names) could have all their work showing up at one node (or even better, all their work showing up at each of the two or more named nodes).
Are you doing this clean up before you import the record into TW or afterward?
Again, I don’t know your workflow, nor have I ever worked with bibtex, but if you’re usually importing at most a handful of entries, I can easily imagine (and no, I don’t know how to do it) an interception of the import process, that lets you correct the best automated guesses, perhaps something like this:
So, the less invasive path is to try for fuzzy recognition that accommodates 