[GUI Plugin] Library Codes

[GalacticHull]

Originally Posted by DaltonST

Version 1.0.35 - 2018-10-11 FAST Tags added to LC Customization. FAST retrieved as Tag-Like. Minimum Calibre now is Version 3.30.

See the attached.


DaltonST

This is truly wonderful. Thank you.

[knobunc]

Wow. Cool! Thank you!

However, it looks like I can't "Derive Identifiers" from Author/Title any more. And when I plug the oclc-owi identifier in, then it won't derive DDC/LCC/FAST from it. e.g. I have the OWI set to refer to http://classify.oclc.org/classify2/C...?owi=103033854 and when I derive the DDC/LCC/FAST, nothing happens.

And a small feature request... can you change the separator in the FAST responses from -- to . so that we can have hierarchical tags?

Thank you!

[knobunc]

Sorry, another quick question, do you have public git repos so other people can help do work on the plugins?

Thanks!

[DaltonST]

Nope.

[knobunc]

Ok, so I got some debug logs for the problem I reported above and I see:

FAST name: Intergenerational relations
oclc-other is: 1001478406
author(s): Albom, Mitch, 1958-
title: Tuesdays with Morrie : an old man, a young man, and life's greatest lesson
oclc-owi: 103033854
---------------------------------------------------------------------------------------------------
Author Details: LOC Authority Name: n88036767 VIAF Author ID: 97615503 Author: Albom, Mitch, 1958-
returning from api: 378.12092 LD571.B418 [u'Teacher-student relationships', u'United States', u'Schwartz, Morris S', u'Universities and colleges--Faculty', u'Brandeis University', u'Death--Psychological aspects', u'Amyotrophic lateral sclerosis--Patients', u'Intergenerational relations'] 103033854 1001478406 n88036767 97615503
OCLC-OWI Route: too many values to unpack
no books in book_ids_list; returning...

--- Below is update #1

I see the problem. oclc_classify_api() is called but the fast list is not assigned in a couple of places in ui.py.

Thanks
-ben

[DaltonST]

Version 1.0.36 - 2018-10-12 FAST Tags





DaltonST

[DaltonST]

And a small feature request... can you change the separator in the FAST responses from -- to . so that we can have hierarchical tags?

You don't understand how Tags work in Calibre. Tags are comma-separated...always. The FAST responses have absolutely nothing to do with what separator is used. Nothing.

If you want hierarchical Tags, whether for FAST Tags or standard Calibre Tags or LCEAD Tags or Genre Tags, you must handle those on your own using Calibre functionality to do so. That is a user-by-user choice.




DaltonST

[davidfor]

Originally Posted by DaltonST

You don't understand how Tags work in Calibre. Tags are comma-separated...always. The FAST responses have absolutely nothing to do with what separator is used. Nothing.

If you want hierarchical Tags, whether for FAST Tags or standard Calibre Tags or LCEAD Tags or Genre Tags, you must handle those on your own using Calibre functionality to do so. That is a user-by-user choice.

No, calibre quite happily supports hierarchical Tags. You configure which columns are treated like this in the preferences: "Look & Feel", "Tag Browser", "Categories with hierarchical items". The tag browser will then show any tags in these columns with dots in them as a tree with the dots setting the levels.

[DaltonST]

You posted this:

Originally Posted by davidfor

No, calibre quite happily supports hierarchical Tags. You configure which columns are treated like this in the preferences: "Look & Feel", "Tag Browser", "Categories with hierarchical items". The tag browser will then show any tags in these columns with dots in them as a tree with the dots setting the levels.

You omitted the context of my response (my responding to a user's request to do something absurd). My full post was:

The user wrote:

To that I replied:

You clearly did not understand the discussion, or you would not have replied with a leading "No, ...". As the blue, underlined phrase above shows, I told the Library Codes user that he must use Calibre's functionality to create hierarchies of Tags, and not expect the Library Codes plug-in to do it for him.


Essentially, the user was requesting a "small enhancement" to corrupt the Tag values in the Tag-Like Custom Column under discussion, #fast, by hardcoding in leading dots into its custom_column_NN table Tag-Like values. Not going to happen.


I stand by my original response as being 100% accurate: The user needs to use Calibre's functionality to create hierarchies.




DaltonSRT

[davidfor]

Originally Posted by DaltonST

You posted this:


You omitted the context of my response (my responding to a user's request to do something absurd). My full post was:

You clearly did not understand the discussion, or you would not have replied with a leading "No, ...". As the blue, underlined phrase above shows, I told the Library Codes user that he must use Calibre's functionality to create hierarchies of Tags, and not expect the Library Codes plug-in to do it for him.

Sorry, but your original response reads to me as saying that calibre doesn't support hierarchical tags. And while the statement of "Tags are comma-separated...always" is true, that is unrelated to how calibre does hierarchical tags. Overall, it sounded like you were saying that there was no way the plugin could create tags that could be treated as hierarchical by calibre.

Your response now makes me realise that what you were really saying is that either you don't think these tags represent a hierarchy, or you don't think it would be a good idea for this plugin to fiddle with these tags in this way. That is your decision.

Essentially, the user was requesting a "small enhancement" to corrupt the Tag values in the Tag-Like Custom Column under discussion, #fast, by hardcoding in leading dots into its custom_column_NN table Tag-Like values. Not going to happen.

I'm really missing something here. I didn't see any mention of anything I would call "leading dots". The user seemed to be suggesting that if the FAST tag of (from the sample above posted by @knobunc) "Amyotrophic lateral sclerosis--Patients" was found for a book, store it on the book as "Amyotrophic lateral sclerosis.Patients". Then calibre could treat that column as a hierarchy. And looking at the sample you posted when you released the FAST support, it looks like this would work.

I stand by my original response as being 100% accurate: The user needs to use Calibre's functionality to create hierarchies.

And for the record, if @knobunc wants to do this:

1. Select the books to be changed.
2. Open the bulk metadata editor and go to the "Search and replace" tab.
3. In the fields:
   • Search field - select the column with the tags you want to change.
   • Search field - enter "(.*)--(.*)" (without the quotes)
   • Replace with - enter "\1.\2" (without the quotes)
   • Search mode - select "Regular expression"
   • Destination field - select the column with the tags you want to change. Or another if you want to copy them there.
4. Press OK or Apply to make the changes.

That will only do one level of changes. It would need to be run it multiple times if there are tags with multiple "--" separators. Or work out the correct regex to do them in one go.

[DaltonST]

Sorry, but your original response reads to me as saying that calibre doesn't support hierarchical tags. And while the statement of "Tags are comma-separated...always" is true, that is unrelated to how calibre does hierarchical tags. Overall, it sounded like you were saying that there was no way the plugin could create tags that could be treated as hierarchical by calibre.

My response would sound like to someone who knew nothing about the Library Codes plugin, and knew nothing about the heavily modified Classify API (that was the topic of discussion in the first place) that it uses to obtain many of them.

The Library Codes plugin is 3 years old, and has been generating LCEAD Tags (Tag-Like Custom Column Tags) flawlessly for 3 years. FAST Tags are just a new source for a Tag-Like Custom Column. No big deal.

LC is a generic plug-in, and I will not hardcode anything special in its API for a single user. Calibre is powerful enough in functionality so a user can use standard Calibre functionality to achieve whatever they want without asking me to hardcode it just for them.

Since I have developed 14 plug-ins, I should be presumed a priori to know a little about programming plug-ins, using both Calibre's APIs and native SQLite, to create Tags in all of their flavors.



DaltonST

[davidfor]

Originally Posted by DaltonST

My response would sound like to someone who knew nothing about the Library Codes plugin, and knew nothing about the heavily modified Classify API (that was the topic of discussion in the first place) that it uses to obtain many of them.

The Library Codes plugin is 3 years old, and has been generating LCEAD Tags (Tag-Like Custom Column Tags) flawlessly for 3 years. FAST Tags are just a new source for a Tag-Like Custom Column. No big deal.

LC is a generic plug-in, and I will not hardcode anything special in its API for a single user. Calibre is powerful enough in functionality so a user can use standard Calibre functionality to achieve whatever they want without asking me to hardcode it just for them.

Since I have developed 14 plug-ins, I should be presumed a priori to know a little about programming plug-ins, using both Calibre's APIs and native SQLite, to create Tags in all of their flavors.

Firstly, I have already apologised for misunderstanding something you said. And in the above quoted section I was simply trying to explain that. And for the record, I have made no claims about your ability to code or your understanding of calibre. Except one, which I was attempting to apologise for.

One thing I was trying to understand in the second post was whether not changing the tags to allow them to be treated as a hierarchy was a technical issue (can't be done easily), or a philosophical decision (doesn't fit into the way you see the plugin or the tags should be used untouched). I can see that it is that latter.

It definitely isn't a technical issue as it took me about five minutes to find the line to change to do this. For the record, all that is needed is to change line 704 in ui.py from:

fast_list = fast_dict[s_book]

to:

fast_list = [tag.replace("--", ".") for tag in fast_dict[s_book]]

Of course, it would be better if it was configurable. So, what do you think? 30 minutes to add a checkbox, store the preference and check it when doing the above?

[DaltonST]

fast_list = [tag.replace("--", ".") for tag in fast_dict[s_book]]

The FAST Tags have no "--". You got that false notion from the user's "small enhancement" request, that was incorrect in the base case. He was wrong, and you assume that he was correct. No. Both of you are wrong.

FAST Tags have no "--" at any time, anywhere, in LC, so your code is wrong too.


I have decided to add new functionality to LC related to its tag-like custom columns, LCEAD and FAST, in order to facilitate hierarchies, but I guarantee you it will be nothing like you or the original user suggested.

I am also going to add a new 5th Tag Rules table to the Job Spy "Scrub Tags" Tool to allow both prefixes and/or suffixes to be added to any Tags or Tag-Like custom columns using regular expressions.



DaltonST

[DaltonST]

Library Codes users who wish to modify either the LCEAD Tags or the FAST Tags should see this post: https://www.mobileread.com/forums/sh...5&postcount=23


For example, if you want to replace any "--" with a "." for #fast tags, use the Tag String Replacement Rules table to do so.




DaltonST

[davidfor]

Originally Posted by DaltonST

The FAST Tags have no "--". You got that false notion from the user's "small enhancement" request, that was incorrect in the base case. He was wrong, and you assume that he was correct. No. Both of you are wrong.

FAST Tags have no "--" at any time, anywhere, in LC, so your code is wrong too.

That seems very weird as @knobunc posted what appears to be log results here, and contains three examples containing "--" ('Universities and colleges--Faculty', 'Death--Psychological aspects' and 'Amyotrophic lateral sclerosis--Patients'). And your post announcing the addition of FAST tags includes the example "Civilization--Japanese Influences". And when I tested the code change I made, of a small library with some random books in it, I saw plenty of example.

Or did you think I meant that the Library Code plugin was adding the "--" somewhere along the way? It is clear from the code it isn't. The code for this is extremely simple. It just grabs the tags from the result of the API call, puts them in a list and later copies that list to the metadata of the book. No fiddling with the actual tag values, no adding anything extra, just straight copies of data retrieved.

But, it is clear from everything I can find on the web, that the FAST tags can include "--" and that treating these tags as a hierarchy split at those characters is not a dumb thing to do.

And just for the record, I did have a little play with http://classify.oclc.org/classify2/a.../classify.html to see what sort of results came back for some books. And some of the FAST tags in those results have "--" in them

Originally Posted by DaltonST

I have decided to add new functionality to LC related to its tag-like custom columns, LCEAD and FAST, in order to facilitate hierarchies, but I guarantee you it will be nothing like you or the original user suggested.

Yes, it is obvious that it won't produce the requested results. And it escapes me as to what useful result it would give. It is simply adding a fixed value to the beginning of each tag. And as each tag type is in a separate column, and all the tags are replaced each time they are fetched, I'm not sure how that would be useful. I'll have to test it later. Maybe when I see some examples, it will come to me.