hey,
maybe I overlooked options, but I find an unneccessary/unwanted barrier to not be able to search content/strings across content and attributes.
I think this would make the global search (more) truly global, and open up some other useful search/use-scenarios; could also be offered as an option via prefix/operator in searchbar (analog to 'text=xxx')
lerone-b
All 10 comments
Hello, you can combine searching for both text and attributes, e.g. @text*=*Hello @attr=val
zadam
on 23 Apr 2020
TLDR:
try a search for '_Tregillis_', an _author of a book_ entered into Trilium example content. the author obviously is a) central information (i.e. something you want to find easily later); and is b) technically entered via a seperate field in the note: an attribute. – now, run a basic search for 'Tregillis' in the KB. result: nothing! – conclusion: something is wrong with the data/search concept...
hey Zadam,
thx first of all for Trilium! it is genius in lots of ways. so thx for sharing that.
also thx for your reaction!
as to your answer. there are three levels for a reaction from my point of view: (1) principal (– dataarchitecture / KB philosophy), (2) practical (– current use case), and (3) consequential (– future (negative) effect on Trilium use).
(1) principal:
my point was partly motivated by the philosophy of Knowledge Management. sry for length, but I hope it adds to discussion/thought.
I think, after having tried dozens of ways + tools etc., that any sustainable personal knowledge tool should see (single term) search as very fundamental pivot point of such a system (besides good structure, metadata, overview and structural 'liquidity').
Trilium excels in lots of ways, e.g. most solutions do not provide for things like link/relation-graphs (overview + overview production) and clones (structural 'liquidity') etc.
BUT I never understand why a PKM should in principal (ontologically) treat attributes (as in 'tags', custom 'metadata' (e.g.' author'), 'categories' etc. as distinct universes of meaning? after all in a PKM-tool you search... _information_. nothing else.
– take the paradoxical / counterintuitive / counterproductive results (to treat it otherwise) via the example of your own Trilium example content: search for _'Tregillis'_ in Trilium (the author you seem to value). what you find is: _nothing_! that is on central information and therefor does not seem a trivial/incidental observation.
the question behind that: what if you setup via attributes a structure for '_author of a book_' (important information) – just to not find it in a simple/basic search.
– add here the idea that this KB _scales_ up over years as single authoritative knowledge container, holding 100.000s scraps of info, developing _complex tree-/metadata-structure_, etc. all meaning: in 2 years you might just not remember or deem useful to search for '_author= Tregillis_' (because I don´t remember; because there are many more alternative attributes that would qualify as relevant; because I just don´t remember attribute-structure etc. – see (3))
(2) practical:
the example you give somehow works, but also not as I would expect.
my scenario: trying to find ways to make PDF-content searchable within Trilium. realization: I have a PDF that is the subnote of another note.
now I have the string '_image_' twice in there: one time as part of a custom-label I set up for the PDF-text (the label holds all of the pdf-text as copy); and a second time in a child-note of the PDF as pure and simple text.
when I search with this kind of search combination I only find one note (of two) (the pdf-note that contains another text note; the text (sub-)note is not shown in the results
- and: peculiarly _@text=image_ also produces empty results here :-?
(3) consequential
it seems currently Trilium relegates me to search important content twice. the problems with that:
– it means I do not find important stuff (like '_Tregillis_') in 'simple' (=basic) searches; which means I can´t trust the results
– alternatively I would have to revert to complicated syntax (see 2); which adds a load of issues / complexities / frictions, e.g. once I set up more attribute fields, I will have to include (and: remember!) them all; e.g. what if _Tregillis_ appears in the meaningful attributes 'author', 'subject', and 'reference' etc. ... but I want to simply find all notes that deal with / relating to Tregillis?! etc.?
sorry again for length. I hope it shows that I am raising this just because I am so much in sympathy / love with Trilium... :-D
lerone-b
on 24 Apr 2020
Hello, I understand and agree that attributes should be included in the "basic" search. This is now implemented in master and will be in 0.42.
when I search with this kind of search combination I only find one note (of two) (the pdf-note that contains another text note; the text (sub-)note is not shown in the results
and: peculiarly @text=image also produces empty results here :-?
Could you perhaps post here (or send to [email protected]) and export of the subtree where I can reproduce this? Since this behavior is not expected ...
zadam
on 25 Apr 2020
hey Zaddam,
thx for joining and sharing the thoughts. and implementing this!
– it definitely makes Tilium now my #1 candidate as KB!
as to subtree sample: sure!
– strange thing is, when I go vie export subtree (as html or markdown) I see no further trace of things happening, not knowing whether (and whereto) something was exported... (also couldn´t locate it via Spotlight)
... is there another way you could point me to for export; then I am happy to share!
best! oliver
lerone-b
on 26 Apr 2020
hey Zadam,
I see this is reverted bec of performance. A little bummer but then understandable.
I am wondering – not only looking at you but also community help – whether there would be an easy way to script a copy of the attributes into the note body itself? (preferably in a certain extra formatting, like code block, or an invisible block, or... the like).
– as the reference case of the unfindable author field maybe illustrates, for some use cases where one really relies on / works with attributes as meaningful metadata, it is just not really 'tolerable' (in terms of: practical) to not be able to find that info...
... so this would be my final hope. otherwise I´d have to consider manually copying the attribute info from the right hand pane into the note each and everytime. which obviously is suboptimal...
as you see: still trying to find a way... :-}
lerone-b
on 6 May 2020
Yes, this was reverted for 0.42, but I'm preparing search overhaul for 0.43 which will support this in a much faster way and also include searching inherited attributes as you mentioned in another issue.
zadam
on 6 May 2020
wow! great many thx - for work, and for sharing the info!
lerone-b
on 6 May 2020
thx for the continuous development - that is great to see!
just to check back on this one thing which is more central to my way of dealing with info management: from the first run of 0.43.3 I take that the inclusion of attributes into search has run into some barriers.
just checking what to settle for for future use scenarios :-)
- thx for any comment / enlightenment!
lerone-b
on 28 Aug 2020
Search changes have been postponed to 0.44, first beta coming probably next week.
zadam
on 28 Aug 2020
thx for that update!
lerone-b
on 28 Aug 2020
Related issues
tvortsa
·
3Comments
hrzboy
·
5Comments
wwalc
·
3Comments
apg-dev
·
5Comments
gerroon
·
5Comments
Most helpful comment
Yes, this was reverted for 0.42, but I'm preparing search overhaul for 0.43 which will support this in a much faster way and also include searching inherited attributes as you mentioned in another issue.