View Single Post
Old 07-17-2010, 04:49 AM   #21
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by slantybard View Post
One question (that may already be answered elsewhere but I haven't searched for it yet) is whether you can use the calibre custom y/n read column to have a corresponding collection on the sony that would easily update automatically with the new management system.
Can't yet use custom fields for collections or in save templates. Kovid has been waiting for 0.7 to stabilize before embarking on this journey. We seem to be arriving at that point, so I expect that custom fields + devices (and in OPF and in other places) will arrive sometime in August.

For future planning, what would you want to see on the device when using a yes/no field as a collection? One choice is to name the collection with the field name and populate it with books marked with 'yes', Another is to name the collection something like 'Read:yes' and 'Read:no', with each containing the appropriate list of books. My expectation is that there would not be a collection 'Read:undefined' made.

A similar question arises for text custom fields. Regarding multiple (tag-like) fields: should each 'tag' be a collection, or should the collection be named 'columnName:tag'? The same question applies to single value text fields. I can see arguments either way.

For example, if I have a field named Genre containing entries of Mystery, Thriller, and Science Fiction, should the collections be named Genre:Mystery, Genre:Thriller etc, or simply named Mystery, Thriller, etc. Using the first way permits the same word to appear in different field contexts and makes it clear which context is which, but the name is longer and sorts by the column name. The second will give shorter names and different sort, but opens the possibility that the same field value will be found in more than one context (such as in the custom field Genre and the standard field Tags), resulting in the two being combined into one collection. The second also opens the door to confusion because of lack of context. For example, if I have a 'Rights' field with values Free, PD, and PBook, I would need to remember my metadata structure to know what 'Free' meant. Seeing 'Rights:Free' would remind me.
chaley is offline   Reply With Quote