MobileRead Forums - View Single Post - Sony collections and custom fields: how to handle duplicates?

chaley · 08-31-2010, 07:23 AM

I am (finally) getting around to implementing custom field support for file name templates and collections, and have reached a point where choices must be made. I am looking for guidance.

The question: what do I do if two fields being used for collection generation contain the same value? For example, I might have a tag 'Fiction' and a #genre 'Fiction'. If I name the collection 'Fiction', then books with either the tag or the #genre will end up in the same collection, even if they mean something different in the context of their field.

The question becomes more complicated if one of the two (or three or ...) is a series. Imagine I have a tag 'Foo' and a series 'Foo'? They will both end up in the same collection, named 'Foo'. How should the collection be sorted? If by series_index, then what index do I use for books that are tagged 'Foo', but are members of the series 'Bar'? (This can happen today, and the results are strange.)

I can imagine several ways forward.
1) Have a single category name and put everything into it, regardless of where the value comes from. Live with the strange sorting and the meaning collisions.
2) Add the field lookup value to the category, thereby creating multiple categories. In this case and using the above examples, we would have categories:
- "Fiction (tags)" and "Fiction (#genre)"
- "Foo (tags)" and "Foo (series)"
3) As in #2, but reversed: "(tags) Fiction" and "(#genre) Fiction.
4. As in #2 or #3, but using the column name: "Fiction (Tags)" and "Fiction (Genre)"
5: As in #2-#4, but using something like colon separation, e.g., Foo:tags
6: Refuse to do anything, saying that there is a name conflict.
7: Let the first one win, and ignore all the rest.

Anyone care to discuss? Or provide other ideas? Speak now, or forever hold your peace.

My choice would be #4, or possibly its #5 equivalent.

It is worth noting that user-defined categories make this problem even worse. These categories have no provenance (no source field), but can conflict with categories that come from metadata fields. This happens today with series, but I have a hack in the code to detect that conflict. In the end, I may need to refuse to allow custom-field categories if the 'Metadata Management' option is set to 'Manual'.

08-31-2010, 07:23 AM	#1
chaley Grand Sorcerer Posts: 11,740 Karma: 6997045 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	Sony collections and custom fields: how to handle duplicates? I am (finally) getting around to implementing custom field support for file name templates and collections, and have reached a point where choices must be made. I am looking for guidance. The question: what do I do if two fields being used for collection generation contain the same value? For example, I might have a tag 'Fiction' and a #genre 'Fiction'. If I name the collection 'Fiction', then books with either the tag or the #genre will end up in the same collection, even if they mean something different in the context of their field. The question becomes more complicated if one of the two (or three or ...) is a series. Imagine I have a tag 'Foo' and a series 'Foo'? They will both end up in the same collection, named 'Foo'. How should the collection be sorted? If by series_index, then what index do I use for books that are tagged 'Foo', but are members of the series 'Bar'? (This can happen today, and the results are strange.) I can imagine several ways forward. 1) Have a single category name and put everything into it, regardless of where the value comes from. Live with the strange sorting and the meaning collisions. 2) Add the field lookup value to the category, thereby creating multiple categories. In this case and using the above examples, we would have categories: - "Fiction (tags)" and "Fiction (#genre)" - "Foo (tags)" and "Foo (series)" 3) As in #2, but reversed: "(tags) Fiction" and "(#genre) Fiction. 4. As in #2 or #3, but using the column name: "Fiction (Tags)" and "Fiction (Genre)" 5: As in #2-#4, but using something like colon separation, e.g., Foo:tags 6: Refuse to do anything, saying that there is a name conflict. 7: Let the first one win, and ignore all the rest. Anyone care to discuss? Or provide other ideas? Speak now, or forever hold your peace. My choice would be #4, or possibly its #5 equivalent. It is worth noting that user-defined categories make this problem even worse. These categories have no provenance (no source field), but can conflict with categories that come from metadata fields. This happens today with series, but I have a hack in the code to detect that conflict. In the end, I may need to refuse to allow custom-field categories if the 'Metadata Management' option is set to 'Manual'.