[KPhotoAlbum] order criteria for a family photo collection

[Heinz Kohl]

Am Mittwoch 07 Februar 2007 22:51 schrieb jedd:
>  On Thursday 08 February 2007 3:57 am, Heinz Kohl wrote:
>  ] I was doing some such actions using some regular expression hack
> directly ] modifying the index.xml file and was adding some categories in
> that manner. ] But that's not enough.
>
>  Note that there's a plan to shift away from the XML backend, and into
>  a database proper, at which point your scripts become a lot easier
>  and useful (I'd imagine) to do this semi-automated shifting of meta
>  data.  Regexps should be easy to pick up the number from your files,
>  particularly if you've stuck with \-[0-9].\.  (is that right?) all
>  the way through your scanned set.

Oh, I took some other information from the file names. My "but that's not 
enough" was related to "I will/would have to do more such jobs".

For mass data execution, to use a database is obviously the better way.

But:
- it's easy and possible to use a XML structure, this will make porting easy 
- for albums, which are not as big, XML is the better solution

KPA should therefore hold the possibility to make XML output.

>  ] Sorry - KPA is forcing to drive only one single archive.
>
>  I still don't see why this is the case.  If you have lots of disparate
>  sets of data that happen to share similar keywords, then it would
>  be easier to separate them into discrete chunks (and discrete
>  index.xmls) but that would be the only limitation I think. 

KPA 3.0 may have new methods.
But in KPA 2.2 a command line call is necessary.
Enough for me to say 'one single archive'.
Let's explain.

I'm also teaching non computer scientist students, which are freshmen on the 
PC, at their 'very first' PC sessions.
1997: there were a lot of students needing assistence in tasks, how to edit a 
text or how to write a mail, but most were knowing the basic commands.
2007: all students were fit in editing, mailing, surfing, but many haven't  
heard before of crazy things like 'command line' or 'text window'.

If avoidable, I'm also tired in using such prehistoric technics. Things like
'Open a command window'
'Type in stupid text lines including cd, man ...'
'Read a crazy unstructured man text to remind the parameter values'
'Type another stupid text, don't forget the & or crash the program when wiping 
the text junk from the window'

It's very nice to comply with ancient customs in operating on a command line,
Programs of today should also comply with the customs of today.

>  ] And it is lacking a method to implement other than explicitely defined
>  ] enumeration data.
>  ] That's not the right way to build a complete taxonomy.
>
>  I'm not sure Jesper's original goal was to build a complete taxonomy.

I don't expect a complete taxonomy.
I would be over glad, when KPA would conserve additional entries KPA is not 
knowing.
Maybe KPA 3.0 is doing that -
KPA 2.2 is removing all unknown data, even a XML style link.

If you're wanting, you will soon see my ideas.
I'll announce my prototype program 'pico 0.00' soon, I think next week, it 
will show my most basic ideas, hoping, it will give some suggestions.

>  I'd suggest most KPA users (and yes, the ones that don't use it may
>  have been driven away by perceived short-comings as you're now
>  describing) don't want a complete taxonomy.  Or rather, they can
>  build a perfectly functional, sensible, manageable taxonomy via
>  the existing toolset.
>
>  I'd really encourage you to try a paradigm shift away from date-as-key
>  and put a modest number of images (say a hundred or so) into a dev
>  system, then manually enter all the relevant meta-data .. use it for
>  a while, and then make an evaluation.

The complexity of human operations on an unsorted album is in all but simple 
cases growing at least with O(n log n), I think, to reach O(n*n) isn't easy, 
together with dates with unsafe ordering it will grow faster.
It is just the problem that I'm needing EDV to get order into the unsorted 
data, and up to now I got additional disorder.
Its all but sure, that to start with a lower number of entries will help in my 
case.

My prototype is promising to help making quick editing operations, even
if I don't expect to find the best possible compromise in the very beginning.
I'll hoping, it will also help in ordering.

I think, it's too complicated to explain what I've really intended with my 
remarks about date, I hope, it will be seen more clearly with my prototype.

H. Kohl