Searchable fields when using _Canonical_uri ?

[Mark S.]

Is there any field you can insert into a canonical uri tiddler to make it searchable?

The problem is that you can have content, say an image or a PDF file, that is not itself searchable. If you want to find the content someday, there needs to be a searchable field. I tried it adding my own field, hoping that TW would check, but it didn't appear to work.

Thanks!
Mark

[Zaphod Beeblebrox]

Interesting conundrum...

I haven't run into this particular problem, yet - The only _canonical_uri tiddlers I have right now are the background images for the TW, and they all have a uniform title ($:/_BG_Background Name) so they're easy to find in the Advanced Search box.

Will be watching for eventual answers to this.

--Zaphod

[Dragon Cotterill]

This is one of my biggest problems, with one of my TWs. My Doc Library ( https://dl.dropboxusercontent.com/u/1207193/library.html ) has a lot (and I do mean a LOT) of PDFs in it. Most of the entries point to a document of one sort or another.

For local access I have not found any program which is capable of indexing the documents in a directory and making that index accessible. This is your issue Mark. Attached or linked documents are not part of the TW structure. Including the content of said document inside TW essentially doubles the storage space and inflates the size of the TW. Which to my mind makes it an unworkable solution.

But this Dropbox removal of opening HTML files (which interestingly enough, I have not received notification of) may force my hand into moving the whole system into Domino (my web server of preference) where all of the content would immediately become searchable.

I have been toying with the idea now of pushing TW into a Domino platform, as this would solve a number of issues such as multi-user editing, security/authentication, advanced searching etc. Looks like I might have to implement this sooner rather than later.

[Mat]

@Mark

based on the replies from the others, it seems I misunderstand your question... but I'm posting anyway;

AFAICT, it is enough to merely add a new field and then simply search for it in the Advanced search > Filter.

For example, add field Foo and value Bar.... searching for e.g [has[Foo]Foo[Bar]] or merely [Foo[Bar]] gives the desired tiddler title.

...?

<:-)

[Mat]

You might also have interest in a solution by Grand Wizard Tobias; Keyword search.

<:-)

[Mark S.]

Sure, but clumsy. External objects should be treated as first-class objects, especially since they may contain more information than can actually fit in TW.

Thanks,
Mark

[Mark S.]

There are technical reasons why a HTML-based product like TW can't search external documents. Without an indexing system, a simple search might take hours or days.

But what I want is just to have an associated index or key field that gets its contents added to the search. Then I could paste in 50 to 100 keywords (phrases if possible) that could be used in searches.

Thanks,
Mark

[Danielo Rodríguez]

For local access I have not found any program which is capable of indexing the documents in a directory and making that index accessible. This is your issue Mark. Attached or linked documents are not part of the TW structure. Including the content of said document inside TW essentially doubles the storage space and inflates the size of the TW. Which to my mind makes it an unworkable solution.

Have you tried docfetcher? http://docfetcher.sourceforge.net/en/index.html

Did a pretty decent work for me 

[Mat]

On Monday, September 5, 2016 at 7:26:33 PM UTC+2, Mark S. wrote:

Sure, but clumsy. External objects should be treated as first-class objects, especially since they may contain more information than can actually fit in TW.

Actually, IMO all fields should be treated as first class objects. Or at least all custom made fields. Exactly so that foo:bar is found by default. 

<:-)

[Tobias Beer]

Hi Mat,

 

Actually, IMO all fields should be treated as first class objects. Or at least all custom made fields. Exactly so that foo:bar is found by default.

Perhaps not all, but surely all fields that are not date fields or hold binary data, e.g. base-64 encoded.

Best wishes,

Tobias. 

[HC Haase]

Off topic:
That is a fantastic freaking amazing collection you got on my favourite topic. is there any chance you will be willing to share it???

[Sylvain Naudin]

Le dimanche 4 septembre 2016 22:34:24 UTC+2, Mark S. a écrit :

Is there any field you can insert into a canonical uri tiddler to make it searchable?

The problem is that you can have content, say an image or a PDF file, that is not itself searchable. If you want to find the content someday, there needs to be a searchable field. I tried it adding my own field, hoping that TW would check, but it didn't appear to work.

Hello Mark,

Maybe you can use this search field option, have a look to this thread : https://groups.google.com/forum/#!msg/tiddlywiki/w03HpUdfSIk/fb-B-kdhrXcJ

If you have a file name rules, I think you can find what you want. Or and any other field and search with it.

Hope this help,
Sylvain

[Mark S.]

Thanks Sylvain, but what I would want is a way (perhaps through a configuration option) to add a key field to the regular search. For one thing, I don't want to have to remember what kind of document I stored the information in or what the name of the field was. If I could remember all that, I wouldn't need TiddlyWiki!

Thanks!
Mark

[Tobias Beer]

Hi Mark,

 

Thanks Sylvain, but what I would want is a way (perhaps through a configuration option) to add a key field to the regular search. For one thing, I don't want to have to remember what kind of document I stored the information in or what the name of the field was. If I could remember all that, I wouldn't need TiddlyWiki!

I think what is required is to be able to configure a list of field names all of which will be searched via default search, now those would be "tags text title".

Best wishes,

Tobias.