Table of Contents

[Zearin]

I’ve got all the *Pedia applications, and my most heavily used are BookPedia and DVDPedia.

Both of these, as well as CDPedia, would really benefit from the ability to add a “Table of Contents”. I can’t think of a way to simulate this using custom fields, because (AFAIK) they do not support things like lists and hierarchical data.

For each *Pedia, the “Table of Contents” might have a slightly different name:

• Bookpedia
  • “Table of Contents”
• DVDPedia
  • “Table of Contents” or “Chapters”
• CD Pedia
  • “Track Listing” (maybe “Table of Contents” for AudioBooks on CD?)

The Pedias have a very loyal and inventive community of users, and I don’t doubt that someone could probably come up with a workaround of some sort. (And if anybody does, I’d be very interested—so please let me know!)

However, even the best workarounds are still workarounds. Nothing would be nicer than to have this natively supported in the *Pedias!

I welcome comments, questions, feedback, etc. from anybody. (And Bruji—if you decide to put this on your ToDo list, I would be delighted to know! )

[Conor]

How would you use the table of contents? I am not quite clear what the final advantage would be?

[Zearin]

How would you use the table of contents? I am not quite clear what the final advantage would be?

Couldn’t that be asked about a bunch of other data stored by the *Pedias? Like “Pages”, “Dimensions”, “Tags”, or “Features”? I was under the impression that the whole point of the Pedias is to have an efficient, usable, and complete database of one’s books, CDs, DVDs, and video games. Does every single piece of data in every single Pedias has a “final advantage”?

Okay, so, off the top of my head…

I would use the Table of Contents for a variety of things, including search (“I know there was a chapter in one of my books named <blah>—which book was it again…?” or “What was the name of that song on my Radiohead album…?”) and to have the data available for exporting and processing (for example, with XSLT or XProc).

And as with many of the *Pedias’ current metadata, I’m fairly certain I would discover other uses simply by exploring the data and playing around. Not the sort of thing one anticipates.

…

I apologize if I have come off somewhat callous in this post. I just thought it was a little weird that I had to justify a “final advantage” when the *Pedias seem to already store plenty of data which has no obvious “final advantage” to me. But I’m glad that it’s there in case I need that information for whatever reason, or if I simply want to play around with the apps to see if I can figure out a way to use the Pedia’s very comprehensive data in other workflows.

…

Edit: On another reread, I think I’m stressed out and it’s making me grouchy. I tried to edit down some of the grouchiness, but some might have escaped me. Sorry for any unpleasantness. (I expect to feel better after I take care of some other Life Stuff™ that needs doing in the near future.)

Thanks for some great apps—really!

[Conor]

Thank you for the explanation. I was just confused and must have misread the original post. I understood it to be a table of contents built on the fly from the information already present the Pedias. A table of contents for a collection, I thought you were asking for more a specific view of the attributes of a collection and books than an extra field named "table of contents". It must have been the fact that you extended the request to encompass the other programs, including a track listing for CDpedia, when CDpedia already has a track listing.

Thank you for the field request. It will make it into the next major version; if not as an actual named field, there certainly will be new custom fields that handle returns and tabs, like the comments and summary.

[sjk]

…, there certainly will be new custom fields that handle returns and tabs, like the comments and summary.

Cool. I welcome a good place to write arbitrary comments.