Yes, taking the easy route on naming the “K Day” post. There’s enough thinking in this one I don’t feel bad about it.
Yesterday I looked at the data types available in calibre for custom columns , and made a few notes about how I might handle column definition. Time to see how they can meet my needs.
From yesterday’s notes, I see the following attribute types.
- Primitive types: string, number (integer or floating point), date, date/time (timestamp), boolean.
- Complex types: name (display and sort values), link (display value and URL), tag (perhaps: display value, possibly sort value, possibly description explaining the tag meaning).
- Lists: An array of almost any primitive or complex type, but it might be best to stick to homogeneous types (i.e. all strings, or all dates, etc.).
- References: Any entity type could be defined to have references to any other type of entity.
- Hierarchies: Entities might be hierarchical, but individual values likely are not.
I see the following attribute modifiers.
- Heading: Default heading to use for the field.
- Mandatory: the attribute must be populated.
- Cardinality: Lower and upper bound on the number of values for the attribute (‘mandatory’ might in fact be implemented as {1,1} cardinality).
- Normalized: Indicates the attribute values are not stored in the entity, but are stored once and referenced. Probably used mostly for strings, and may need a different name.
- Format: How to present the attribute (could be a format string, or special formatting mode such as ‘stars’ — used by ratings — or or checkmark/X or identify a markup language such as HTML
- Input Mask: Related to ‘format’, constrains how values can be input.
- Sort Rule: How to reformat a name for sorting: title sort, (last name, first name) sort, replace roman numerals with arabic numbers, etc… might even allow calculation via related attribute.
- Constrained: Only specific values or a range of values allowed.
- Delimiter: How items in a list are separated (often commas or ampersands).
- Formula: Used by fields derived from other fields, has an type from above. Derived fields of complex types might need multiple formula values, such as a link using a book title as display value and an identifier field to build the URL.
I suspect I could conceivably display any attribute in the entity browser and in the ‘tag browser’. I am not certain if that should be defined as part of the entity attribute definition, or in configuring the ‘tag browser’ (such as ‘show upload date, hierarchically by YYYY/MM/DD’).
How are the calibre data types defined in these terms?
| Calibre Column Type | Implementation |
| Text, column shown in the Tag browser | String. |
| Comma separated text, like tags, shown in the Tag browser | ‘Purest’ tag implementation might be “list of strings, comma-separated, normalized”. Could be a many:many reference to a tag entity (especially if I want to have a sort attribute, or attach a description to the tag value). |
| Long text, like comments, not shown in the Tag browser | String (‘text’), with format rule. |
| Text column for keeping series-like information | Reference to a ‘series’ entity, with series_index as a floating-point attribute. |
| Text, but with a fixed set of permitted values | String, constrained, and probably normalized. |
| Date | Date, of course. |
| Floating point numbers | Number (floating point) |
| Integers | Number (integer) |
| Ratings, shown with stars | Number (integer or floating point), probably with input mask and/or constrained. |
| Yes/No | Boolean, with format. |
| Column built from other columns | Primitive or complex type, with formula… need to think about how to capture, perhaps multiple formula definitions? |
| Column built from other columns, behaves like tags | Primitive type (not sure a complex type is feasible), with formula and non-singular cardinality? I’ll need to think about this some more. |
Okay, looks like many of these things work, or can be made to work. Tomorrow, we’ll look at how various entities might be defined.