Attributes with multiple values

[stahl]

Hello,
I am not quite sure if I fully understand how to best use attributes: Say I want to keep the original file name of an image ("DSC00815.jpg") in an attribute, and I want to have two alternative titles, a public one ("a birthday cake") and a private one ("look what I got!").

So, I will have two rows ("items", as far as I get it) in the attribute panel, with the two columns "original_name" and "title". In the second row, the cell for "original_name" will be empty, because obviously there is only one original name. Or should I copy over the data from the first row?

And apart from that, how will I actually know in which row the title will be that I want to use for a given purpose? Maybe I want to add even a third title to some of my images, for my own records, "Pete's classic chocolate cake", which seems to make things even more complicated.

The thing that is puzzling me is that in IM3, a property had a single value, that was it. But an attribute can have many values – so, which is the right one in a given situation?

How do you deal with this? Or am I thinking of attributes "wrongly"?
Thanks, Stef

[Mario]

You are looking at this from a wrong perspective.

An Attribute Set with Attribtues named "file name" and "Notes" can be created. But it does not make a lot of sense. As you correctly explained, you may want to store multiple notes (rows) per file, but only one file name. Mixing both Attributes into one set is then the wrong way to do it.

You can do it this way, but then obviously the file name will be contained in one row only, and when you add 10 notes, you will have 9 rows with an empty file name and a filled note. Not really good.

Better to create an Attribute set "Original File Name" with one text attribute to hold the original file name.
And one set "Notes" with a 'Note' text attribute or more.

This way you can write any number of Notes for each file, but keep the file name attribute set at zero or one two per file.

[sinus]

Hey Stef
Unlike Mario I could not follow you exactly, what you are trying to do. If you have more info, would be nice, if you could share it.

[stahl]

Thanks, Mario! That has helped clarifying some things already.

Markus, I am just wondering how I best work with multiple entries for one attribute. Multiple titles e.g. to be copied into xmp caption depending on the target group of the image on a specific occasion: stock photo catalogue, a photo book "weekend trip to Vienna" or a single image to be sent to my buddies.
How will I know later know which item is for what purpose, or rather, how can I later have a script pick the right item with wich to replace the xmp entry?
I suppose I can't, as far as I get it by now. I need to use separate attributes, not seperate items of the same attribute to achieve this. Essentially like we both have done so far with alternative file names in IM3 properties name_short, name_long und name_kunden, I suppose.

Cheers, Stef

[Mario]

I'm still not quite sure that I understand what you want to achieve.

To manage different sets of metadata for the same file, and later copy them to XMP for 'publishing' use, Attribute Sets and either a Metadata Template or a custom script are ideal. Probably you can do this with a standard metadata template easily, without any script.

An attribute set with

Type | Caption

for example allows you to specify the type (book,stock photo catalogue,vacation) and the associated caption. This way you can store any number of caption types for each file.

If you always use the same caption types, setup a global attribute set which holds these types and then make Type in your per-file set a reference. This gives you a drop-down list to choose from, and then you just add the corresponding caption. See the attributes help, which has many examples.

Once you have added your data to attributes, you can access it from everywhere via variables or scripts. It's much more powerful and easier than the properties we had in IMatch 3.

[sinus]

I'm still not quite sure that I understand what you want to achieve.

I am not Stef  ... but I try to explain, what Stef wants to achieve. I hope, it is this, what Stef means. I guess so, specialy because he mentioned a system, what I did use in IM3 (Stef: Essentially like we both have done so far with alternative file names in IM3 properties name_short, name_long und name_kunden, I suppose.)

We have a file, with a nice filename like:

2016-01-05_11-23_marriage.jpg

But maybe we want not send for a client such a (long) filename.
One of my client for example wishes specific filenames, like "4.356.12_marmelade-honey-110gram.jpg".
Or if we send this file to a friend, we want maybe rename it and call it "Peter-at-marriage.jpg".

But in our database, as the correct and good filename we want have the main filename.

Now we could simply copy such files with different filenames. But to store the same file with different filename makes not real sense.
That is why I (and I think, also Stef) worked in the old days with IM3 with different propertys.
I created some property-fields to hold these alternative filenames, for example:

name_short: 2016-01-12
name_long: Peter-and-Mary-at-marriage

A short script changed the wished files with such a filename. Then we could send the files and after all was done, renamed the files again with the main-filenames.

So far so good, and I guess, Stef tries now to find a good way to do this also clever in IM5.
He wants also know, what files he has sent to a client, or a friend with what filename.

So he came on the idea to do so with Attributes. As you pointed out, Mario, this can be a very good way.

But IM5 give us of course also other possibilities.
I now speak from me, not from Stef, but is is the same "problem" behind this:

I use for holding such alternatives filenames some Metadata-fields, what are seldom used.
Then I fill in this metadata-field the alternative filename and if I must use this, I change the real filename also with this alternative filename, with help from the renamer. Easy and quick.
At the end I do the same, rename these files again with the main-filename.

Now, after a while, I forgot, if I have sent the files to my friend.
Or my client does reorder the files, because he has deleted them 

That is why, I guess, Stef wants to mark somehow, what files he has sent with what filename.
I personally use also for this Metadatas (mostly Dublin core). If I want  not sent them to someone, it is easy to strip them out.

For example, I have a field, when I have delivered a file to a friend, or when they are online.
For clients, because this happens often, I do use a pin.
Since I have a custom File Window, I have also for each of these fields an own icon. So I can see quickly, if I have delivered a file to a client (pin), to a friend and so on.

That is why I love the File Windows and the possibilty to use icons.

With attributes, we can also use such icons. I use attributes only for these stuff:

- bills
- special remarks

I choosed this way, because special remarks and bills are not that often in use here (in contrary to a delivered-status), hence I use Attributes.
Why? To be honest, I find it much more convenient to add something into the metadata-panel as in the Attributes.
But for example for numbers (calculating) are Attributs ideal. Or for large comments.

So these are my 2cents.

[stahl]

Mario and Markus,
thanks for your thoughts, help and interpretation! I'm back to the forum just now.

Actually, I simply wanted to see what one can do with attributes, so I could get ideas what I might want to use them for. And obviously I also had a misconception, which the both of you helped clarify:

I like working with alternative captions (and file names) from which I can choose when I copy a file. Now, I thought these alternative captions are best stored as several items of the very same attribute:

Code Select Expand


attribute   alternative_title   alternative_name
item 1      a birthday cake     a09876543.jpg
item 2      yummie! :-)         bday_543.jpg
...

But, as I understand now, this is not so, and such alternative values are better stored in separate attributes in a one-item attribute set:

Code Select Expand


attribute   public_title      private_title   name_short      name_customers
item 1      a birthday cake   yummie! :-)     a09876543.jpg   bday_543.jpg



Markus, that's an interesting concept to put alternative names into obscure metadata fields, "hijacking" them. Which ones do you use?
I suppose I prefer to keep alternative, private titles apart from metadata, though, to be on the safe side.

[sinus]

Hi Stef

You are correct, with attributes you are on the safe side, because they will stay in the DB.

In my case I store also some things in the attributes, what I do not want, that they are stored in the images itself.
But my alternative filenames are not sensitive.

I know, that I hijack some metafields, but they do no harm, I think.
And with IMatch, I can always - on native way or with a script - move some fields into another or from Metafields into Attributes. No problem.

Hence I store my filenames and some other stuff into metadata-fields.

(I have just deleted now values from my old DB, what I do not more use, easy).

I do now use these fields for special cases:

{File.MD.XMP::photoshop\TransmissionReference\TransmissionReference\0} for alternative filenames
{File.MD.XMP::photoshop\Category\Category\0} for some status of the Meta-entries
{File.MD.XMP::dc\relation\Relation\0} whith what name images are stacked
{File.MD.XMP::dc\identifier\Identifier\0} privat deliverd to who (or whom? merde, my English  )
{File.MD.XMP::dc\type\Type\0} for projects-names (flyers or so)
{File.MD.XMP::dc\language\Language\0} when a file is online
{File.MD.XMP::dc\coverage\Coverage\0} reserve-field, if I must/want hijack another field 

That's it, not more.
In Attributes I put some numbers (Anzahl Bilder, zu je xx Fr., wieviel geliefert, LS-Nummern usw ...)
and some personal fields, like (client was stupid, nice, info about location and so on)

But finally I try not to put too many things into a file, because all takes time.
But what I have "created" is a kind of "info-master", what is in the same time the master of a stack. Only this info-master does hold these attributes, not all other files in the stuff. This info-master does also hold some special icons, categories and so on. If I see this (stacked) info-master, I can see quickly, what files are hidden by the stack, how many, are they private images also, must I do something (deliver some images for a client, friend...), must I send a bill, is it already billed and so on.

In the first time, I thought, so many icons like I have, this would be a problem for the speed. But IMatch does all very good and quickly, no problem.

So I would say, you can buy IMatch with a good conscience ... oh, of course, it's Stef, you bought IMatch long time ago and are almost an IMatch-veteran.  ... of course I know this.