quotation <\/strong>itself. Roughly speaking, a quote has an author, the text itself, and a citation. It might, optionally, have some keywords for searching purposes. <\/p>\nThe middle level is the citation. In theory, all quotes have a citation (the name of a book, article, whatever); in practice, many do not (or I can’t find it). I worry about citations a lot, and a lot of my work on WIST over the past few years (when I work on it) has been establishing citations for quotes. Frankly, I’ve probably done more work on that than anyone else I know.<\/p>\n
At any rate, there are enough gaps in the data that actually creating that middle level is not really worth the effort. I like to group\/sort the quotes by citation, but too many citations would be “unknown\/attributed” to be worthwhile.<\/p>\n
So we have a two-level hierarchy. And, coincidentally, that matches the basic two-level hierarchy of MT: categories <\/strong>and entries<\/strong>.<\/p>\nSo, consider something like this:<\/p>\n
\n- Set up categories for authors.\n
\n- One category for each author.\n
- Use the category description <\/em>for the biographical information.\n
- Issue: I currently have over 1,700 authors. Is there a functional limit on categories?\n
- Issue: How are names to be sorted? I have an internal sort order used for the database that is (very roughly) lastname, firstname, but that’s not necessarily how I might want to present it. So I might include the desired “presentation” name in the category description. But that implies embedding some basic character formatting in the description block, which would need to be maintained. I’m essentially going from twelve fields in my Access DB to one. Some of those twelve are to handle different cases (born, died, flourished, contemporary), but it’s still a slightly discomforting flattening of the data. That argues to maintaining the overall DB separately and populating the blog periodically through the import function. That’s sub-optimal process-wise, but may be best functionally.\n
- Issue: Searching for biographical info. Is that necessary?\n
\n- Well, it might be for pseudonyms (e.g., if you were looking for Clemens and I wanted you to see that was Mark Twain, that might not be immediately visible in a normal MT-based search, since i would be in the category description.\n
- Alternately, would I want to have the pseudonyms generated as their own categories (with the description pointing back to the “real” name)? Can I do that programmatically? And I note that the category will come up empty (no category archive generated) if there’s not something for that person (i.e., if it’s just a pointer). <\/p>\n
Unless … we duplicate the categories for an entry, i.e., each Twain quote appears with categories “Mark Twain” and “Samuel Clemens.”<\/p>\n
- Would I want the pseudonyms\/akas to come out as subcategories? Probably not.<\/p>\n
- There’s some verbiage in this field (“a\/k\/a” and “pseud. for”) that I would need to clean up if I used the field for extra categories.<\/p>\n
- Alternately still I could use Google as the search engine, rather than MT. I’d rather not, but it would solve some of the issues above. To be considered.<\/ol>\n
\n<\/ol>\n<\/p>\n
- Set up entries for quotes.<\/p>\n
\n- One entry for each quote.\n
- The entry’s category <\/em>is the author. (See above for pseudonym\/a.k.a. issues).\n
- The entry body <\/em>is the quotation itself.\n
- Keywords <\/em>aren’t used (currently), but could be.\n
- The citation info for the quote is stored in the … hmmmm.\n
\n- Do it by sub-category? That’s just crazy talk, given the length of the citation info and the number of places it’s missing. Plus subcategory handling in MT is not as clean as I’d like it to be; too many places where it flattens out to all the categories.\n
- Well, it could be formatted and stored in the extended entry<\/em>. That’s easy. But that wouldn’t allow me to sort the quotes by the citation data.<\/p>\n
- I could use the entry title <\/em>field for the citation. <\/p>\n
Can you sort a category by entry title? I think so. You can sort entries by “title,” “status,” “modified_on,” “author_id,” and “excerpt.”<\/p>\n
Is there a limit on title size? Need to look that up.<\/p>\n
As citation info is refined, the titles for posts would change. Is that a problem? <\/p>\n
Well, if I want persistent links, I might want to go to an entry ID <\/em>nomenclature for the files (rather than a dirified title name). (If you have a dirified title filename and you change the title, does it update the post filename? Or does that happen only on the original build?)<\/p>\nCan title be blank? No. And many quotes don’t have a title. That may be a showstopper for this.<\/p>\n
- I could use the excerpt <\/em>field for the citation. That would let me sort as well, without worrying about the title field oddities (but begging the question of what should go in the title <\/em>field). I think this is the way to go.\n<\/ol>\n<\/p>\n
- What should go in the title <\/em>field? Something has to be there. It doesn’t have to display. <\/p>\n
I could use some sort of serial number\/quote ID. But I’d need to be able to generate that on the fly, and there isn’t a built-in function for doing that.<\/p>\n
If I’m not displaying it, every entry could have the same (or a made-up\/random) title. I just hate to waste the field like that.<\/p>\n
Pondering.<\/p>\n
- Fields not being used (maybe): extended entry, title?, secondary categories?, keywords, basename.<\/ol>\n
- Special authors:<\/p>\n
\n- The “~sigs” category is a bunch of one-liners\/slogans\/etc. My thought would be to have them all in a single entry under the “~sigs” author, and not worry about breaking them into individual entries.\n
- The “~other” category is for non-author entries, mostly, e.g., “Spanish proverb” — or where the author is so trivial it didn’t seem worth tracking separately. I’d keep these as individual entries under that same category.\n<\/ol>\n<\/p>\n
- Pages:<\/p>\n
\n- Main page (index): Flat text, explaining the site? Or the most recent added quotes? Or the most recent updated quote (using the last updated plug-in)?\n
- Individual archives: A single quote. (Notes above on filenames — probalby want to use the entry id <\/em>format rather than dirified titles).<\/p>\n
- Categoriy archives: Quotes for a given author.<\/p>\n
- Archive index: List of authors (categories). Don’t really need to maintain date archives? Can’t imagine why.<\/ol>\n
- Comments and trackbacks? Why not?<\/p>\n
- QotD: There are MT plug-ins that will choose a random entry, I believe. I could use something like that to a quote-of-the-day, which I could then use for my WIST mailing list. Maybe.<\/p>\n
- Looking at the above, the big question is, could this all be single-source in MT? I.e., once I have the data into MT, would I need to maintain it separately?<\/p>\n
The biggest issue is where I’m conflating different fields from my WIST DB into a single MT field. That’s happening in two cases:<\/p>\n
\n- In the author table, I track (besides the author_key internal field):\n
\n- author_key (database key field)\n
- title (Lord, King, etc., stuff that should display sometimes but not be sorted by)\n
- lastname (usual sort key 1)\n
- suffix (Jr., III, “of Hippo”)\n
- firstname (usual sort key 2)\n
- displayname (if the above fields don’t produce a normal name, e.g., “Robert Cecil, Lord Salisbury”)\n
- aka (pseudonyms and a\/k\/a’s. Pen names, alternate translations, maiden names, birth names, pre-title days, etc. Messy RL stuff)\n
- other-aka (as above, but stuff I don’t usually display. Usually pedantic inclusions of middle names, etc.)<\/ul>\n
\n- born (not necessarily numeric; may include “c.” or “?”)\n
- died (ditto)\n
- contemporary (T\/F, in case I don’t know the actual birth\/death dates)\n
- flourished (again, in case I don’t know the actual birth\/death dates)<\/ul>\n