[KPhotoAlbum] order criteria for a family photo collection

[Robert L Krawitz]

   Date: Wed, 7 Feb 2007 15:09:19 +0100
   From: Tero Tilus <tero.tilus at jyu.fi>

   2007-02-07 11:05, Heinz Kohl:

   > To have no (unique) primary key is resulting in "will only work
   > suboptimal" - and that's the case not only when "navigating using
   > the date bar".

   KPA has unique primary key, a hash calculated from image date,
   which is used as image identity.

Right.  There's nothing wrong with having multiple keys to a table --
there can be only one primary key (KPhotoAlbum has chosen image
identity, as defined by MD5 hash, as its primary key), but there can
be multiple secondary keys -- timestamp, keywords, etc.  The primary
key really has to have unique values for each row (image, in this
case).  KPhotoAlbum is very flexible in allowing the user to define
other keys.  But as I said earlier, there's a lot of confusion
surrounding grouping (identity) and sorting (ordering).  Timestamp is
a good candidate for sorting; there's a natural ordering function.
Defining something else that has good sorting properties is a lot
harder; it's certainly possible to sort alphabetically, but aside from
the fact that the sort order may differ by locale, it's also somewhat
arbitrary.

The primary key (MD5 checksum) is a horrible candidate for a sort key
in this case, because the MD5 checksum carries no information about
interesting attributes of the image (hash values or serial numbers are
often used as primary keys precisely because they are unique).

   > Most collections are having own inherent primary keys - to sort
   > plants with main respect to photo date instead of Linne's ordering
   > system would be as crazy as sorting family pictures in respect to an
   > ordering scheme for animals.

   You _can_ build Carl von Linné's (Carolus Linnaeus) taxonomy
   (Linnaean taxonomy) using KPA and "sort" (in KPA terminology it's
   called categorization) images using it.

   To pick some nits...  Linnaean taxonomy classifies all living into
   a _hierarchy_.  Hierarchy is _not_ a sort order, although it is
   trivial to derive partial order relation (and thus partial sort
   order) of items from the hierarchy they are organized to.

That nit is important -- you could certainly do a depth-first
traversal, say, and call it a sort, but as I said above,
categorization is not sorting (and sorting is not a general
categorization, either).  How useful that kind of sort order is is
another matter.

   > I think, a program like KPhotoalbum is by far too complicated to be
   > restricted to such a small spectrum

   I think you haven't really looked into KPA.  :)

KPA probably has a bit more of a learning curve than other image
management tools, but it can just plain *do* a lot more.

   The default taxonomy in KPA is well-suited for family photography,
   but KPA is by no means restricted to that.  You can build any
   taxonomy you want.

   As far as I can see you seem to want KPA to derive some metadata
   from file names of your images.  Is that the case?

That's what it sounded like to me.  One potential way to do this would
be to use an external program to extract the metadata and somehow hand
it off to KPA.  The database back end, with a well-defined schema,
would make that a lot easier to accomplish.