Re: How will F-Spot recreate the tag database from photos?



Hi All,

I've been using F-Spot for a while now, and I love to be able to tag
photos, but there are a couple of limitations that frustrate me, and
this is one of them. I suspect I may be expecting too much from tags,
but here are my thoughts anyway.

On 5/18/06, Bengt Thuree <bengt thuree com> wrote:
> But since the tags name should be unique in the db, and as f-spot is
> doing some checks when creating new tags to ensure it, we can always
> find where a tags belongs.

So again, how do you do with a person called Paris, and the capital of
France, Paris.
<snip>
F-Spot wrote the tag information as XMP, F-Spot should be able to recreate
all the various tags (and its hierarchy) rather easily.
How will this work???

You could have the hierarchy implicit in the tag names, and simply
hide it from the user in the treeview. Eg. the tag "Paris, France"
will appear as "Paris" as a subtag of "France". This is also quite a
natural syntax for storage of tags in XMP and text entry (with
autocompletion).

Hopefully no-one should need to take this to multiple levels - the
number of commas you allow will always create limits somewhere, or
leave a gap for importing ambiguity.

The other thing I would like is to allow my tags to have multiple
parents - e.g. "Durham Castle" should be a child of both "Castles" and
"Durham". While I could tag the entry with "Castles" and have "Durham
Castle" as a child of "Durham", this is redundant information, as
Durham Castle is *always* a castle. I haven't worked out a solution to
this yet.

It's a fairly fundamental categorisation problem caused by having the
same object in two different categorisation hierarchies/schemes (in
this case, "Places" and "Types of object").
I can think of three basic classification schemes: Location, Event,
Subject. Any event or subject might have a fixed location, while any
event might have one or more fixed subject. However, multiple parents
within one of these schemes are unlikely to be necessary.

I don't know whether it's best to design around predictable schemes
like this, or make the tagging as flexible as possible so users can
build their own categorisation schemes.

Michael



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]