fail to export catgories - what am I doing wrong?

[ChrisMatch]

Hi

I tried to export a few categories and import them into a new database
BUT: the export contains NO categories!?

What I do is:
- select three categories (see screenshot ...004)
- drag and drop them into the export modul
- select the options (see screenshot ...000)
- iMatch states that it has exported 3 categries (see screenshot ...001)

What I get is an 'empty' file looking like:

Code Select Expand

<?xml version="1.0" encoding="utf-8" ?>
<category_schema xmlns:ptrm='http://schemas.photools.com/category_schema.xsd' vendor='photools.com' version='1.0'>
<categories>
</categories>

</category_schema>


What am I doing wrong?

Thanks
chris

[attachment deleted by admin]

[Mario]

The problem is that you are trying to export child categories of the special @Keyword category.
The child categories of @Keywords are special because they are dynamically created from the actual keywords in your files..

Every database you create with IMatch 5 has the special @Keywords category. And this category create it's child categories automatically, based on the keywords used for the files in that database. This is why it makes no sense to export/import @Keyword child categories.

This is similar to child categories of data-driven categories, which are also not exported.
When you re-import the data-driven category into another database, IMatch re-creates the children automatically, using the actual data in the new database.

[ChrisMatch]

Thanks for you explanation, Mario.

I just noticed that I don't understand the concept completely (although I have already read this part of the help file).

Note: This categories have been created manually not from the files!

I don't understand in which cases it makes sense to create categories manually within @Keywords (and why one is allowed to do that).
If I import the existing categories from files during indexing of the files and now have a nice hirarchical structure to start with... Now my next step would be to enhance the hierarchical structure by adding some new keywords or slightly adjust them.
BUT: Now this would add categories manually that are not assigned to any file (yet) or at least are only assigned to few files - and I can't reuse this enhanced structure in a new DB!?

Should I instead take the structure/keywords generated out of the files and transfer them into 'normal' iMatch categories - is there a way to do that?

Hope you can help me out of my confusion.
Thanks

[Mario]

Don't mix the concepts of keywords stored in your files and normal IMatch categories, stored only in your database.

The @Keywords category has been added to visually represent keywords in your files and to include them seamlessly in the IMatch category concept. This, for example, allows you to work with keywords like you would work with regular categories.

Initially, @Keywords was just a special data-driven category which automatically mirrored the keywords in the files. The user was not able to change @Keywords or its child categories. As a result of discussions with early testers, this concept was enhanced to allow users to create and delete categories under @Keywords. When you create a category under @Keywords, think about it as a slot. You can later assign files to that slot to add the corresponding keyword to these files.

Using @Keywords in that way (adding child categories manually, dragging and dropping files between @Keywords categories etc.) may be more convenient when you need to clean up keywords in masses of files, or do other tricky things. But in general, @Keywords should be considered as an automatic mirror for the actual keywords in your files. Another way to visualize and utilize them.

Don't think of @Keywords as a a replacement for the Thesaurus in IMatch. The thesaurus is the right place to do setup your own keyword hierarchy. It offers a multitude of features not available for the @Keywords category, and is also directly integrated into the Keywords Panel. If you add or remove keywords in the Keywords Panel, @Keywords will be updated automatically.

In short:

• Setup your keyword hierarchy / vocabulary in the IMatch 5 Thesaurus
• Consider @Keywords as an automatic mirror of the keywords in your files, for easier visualization and navigation
• @Keywords is great to see how many files contain a specific keyword
• @Keywords allows you to quickly see which files share a specific combination of keywords (just select the keywords you are interested in)
• @Keywords allows you to use keywords in category formulas
• @Keywords allwows you to use keywords in the @Builder
• You can alias  keywords to make them show up in different parts of your category tree
• Using the category filter for @Keywords make it easy to hide/show files with specific keywords (or combinations) in a file window
• ...

[Richard]

Hi Chris,

I have not tested this with IMatch 5 but I see no reason why it would not work.

In IMatch 3 when I added categories I would copy IMatch Categories to Keywords.
In IMatch 3 I also had IMatch import Keywords as Categories. Thus my Categories and Keywords were the same
In IMatch 3 I would create a tiny transfer.jpg and assign it to all of the categories that I wanted to include in a new database.
I would tell relatives who have IMatch how to set IMatch so that Keywords became Categories and send them a copy of the JPEG.
When they added my JPEG to their database, IMatch generated the desired Categories.

In an existing IMatch 5 database it should be easy to do something similar by assigning the transfer file to any or all Keywords in @Keywords. When that transfer file is added to a different IMatch 5 database, the Keywords will be added.

[ChrisMatch]

Thanks for your clarification.
If have re-read some of the help sections and played around with the thesaurus.

I think I now understand how it should be used:
- I can import all of my images into the database (flat keywords)
- use drag&drop within the @Keywords branch to build a hierarchy
- go to the thesaurus and import the keywords from the database
-> Now I have a nice hierarchical structured list

What I still don't understand is when to use the normal iMatch categories. 
I understand the difference between 'stored in the files' and 'stored in database only'.

But from a pragmatical view: In which situation would I use a normal iMatch category for my images?
In the help file I can see 'Location' created as a normal category!?

What are the decision criteria to choose between @Keywords and normal categories
from a concept point of view (not a technical one)?

Thanks again
chris

[Mario]

I understand the difference between 'stored in the files' and 'stored in database only'.

Keywords form a simple, hierarchical structure.

Categories offer you a lot of additional features, like formulas or data-driven categories which automatically group your files based on metadata.
Also, Categories work for all file formats, not just for image files which support XMP or IPTC metadata.

IMatch 5 supports standard flat keywords like used in IPTC and XMP, plus the non-standardized hierarchical keywords introduced by Adobe LR. Naturally, IMatch 5 supports automatic migration between all keyword storage schemes.

In addition, and that is what may confuse you, IMatch inlines the keywords stored in your file into the unique IMatch 5 categories via the special @Keywords category.

If this confuses you, just ignore it for now. There is a lot to learn about IMatch 5.
Work with your keywords in the Keywords Panel. Use the Thesaurus to setup your keyword hierarchy. This gives you everything (and much more) you may know from other DAM products.

When you had time to gather more experience with IMatch 5, you should see the benefits of having an automatic mirror of the keywords in your files in @Keywords. And if all you ever need are normal keywords, this is perfectly OK.

A share of the IMatch 5 user base will never need more. For other IMatch user groups, categories are indispensable. They work with file formats which don't support embedded keywords. And they need the data-driven categories and advanced category formulas to make use of their file collection and to manage hundreds of thousands of files.

[ChrisMatch]

I understand the difference between 'stored in the files' and 'stored in database only'.

What I still don't understand is when to use the normal iMatch categories

Mario, thanks for your explanation and patience - but this time you explained the part that (I think) I already understood (I do understand the technical difference!).

Let's try to make my question simpler:
Assume we talk about images (not other file types that don't support XMP sidecar files) and we don't talk about 'formulas or data-driven categories' - just simple image files and normal categories.
After all the information I got I think in the case of image files there is no need for normal categories.
And my question is if this is correct and according to the concept.

In IMatch 3 I also had IMatch import Keywords as Categories. Thus my Categories and Keywords were the same

@Richard: thanks for your thoughts and ideas

I wonder if there would be any benefit in iMatch 5 if one tries to mirror the @Keywords into a branch of normal categories.

thanks again
chris

[Ferdinand]

Assume we talk about images (not other file types that don't support XMP sidecar files) and we don't talk about 'formulas or data-driven categories' - just simple image files and normal categories.
After all the information I got I think in the case of image files there is no need for normal categories.
And my question is if this is correct and according to the concept.

In my opinion this is true, if:

(i) you always want them stored in the image file (or perhaps in the sidecar, depending on you Metadata2 settings).  Not everybody wants everything stored in the file.

(ii)  your keyword hierarchy is very stable.  Sure you can rearrange it, but this will typically lead to a LOT of rewriting to files.

I think it's fair to say that even the long-term beta testers are still in the process of deciding to what extent to use categories and to what extent to use keywords.  I expect to use both and the division still isn't clear to me.

F.

[cytochrome]

From many former discussions on Categories/keywords I gained the impression that categories are most useful when organized as a coherent tree around the famous Where, When, Who, etc and when the tree is kept simple (not over ramified) so a look at the tree structure is a good reminder of what categories are available for a new image.

And (flat) keywords take care of extras, not worth creating a new sub category that would remain quasi empty.

I organize my catalog along these lines. But now with @Keywords I am at a loss. After importing my IM3 data I have now under @Keywords all the location (or sublocation depending on your metadata dialect) that my test images are assigned to. How comes?

Francis

[Ferdinand]

But now with @Keywords I am at a loss. After importing my IM3 data I have now under @Keywords all the location (or sublocation depending on your metadata dialect) that my test images are assigned to. How comes?

Because at some stage in the past you wrote those locations into IPTC keywords.  @Keywords shows what's actually in the file and I assume that those locations are.

Note also that there are options under Metadata preferences about importing and exporting keywords, although this mostly relates to the hierarchical case and how to match up flat and hierarchical keywords.

F.

[Mario]

To check, open the Keywords Panel and select one of these files. I'm sure the location is contained in the file as a keyword.

[Richard]

Hi Chris,

My main interest in IMatch was organizing files that pertain to genealogy. The best way to achieve this organization is with Categories.

In my extended family there was one women who recorded every bit of information she had about a photograph on the back. This wealth of information is valuable to a genealogist. Far more common were family photos that had no information. Or worse yet, wrong information. As I gathered family photos I was determined to include all I knew about a photo. When I discovered IPTC this became my means of, in effect, writing all I knew about an image on the back of the image. The advantage of IPTC was that it became part of each file for each digitized photo. If I attached a photo to an email to a family member, they could open that file in most image applications and see not just the image but they could also see the IPTC data.

If the family member also had IMatch, IPTC would not have been as important but only a few have IMatch. For those who do have IMatch, keywords in IPTC became a means of including my IMatch Category labels and file assignments in the image file. This allowed a degree of synchronization between family members. If we all used the same labels for IMatch Categories, it cut down on confusion. It is this file sharing that made keywords important for me. If it were not for file sharing, I would not bother using keywords. For many applications a keyword like: "USA.North Dakota.Fargo" would have had to been entered as three flat keywords unrelated to the hierarchical Categories in IMatch. There are fields in IPTC to record location data and thus keyword entries for WHERE are not needed unless those keywords can generate hierarchical Categories in IMatch.

The main feature that drew me to IMatch was Categories. With Categories one can do far more than what can be done with keywords. As I have said, if it were not for file sharing, I would not have bothered with keywords. With the introduction of hierarchical keywords, the advantages of Categories over  keywords became less distinct. Now with the @Keywords Category that difference is even less distinct however Categories still have many advantages over keywords. How important those advantages are will vary from on IMatch user to the next.

One way for each of us to clarify whether to use keywords or Categories might be to ask ourselves why we are using a DAM. The answer for me is to be able to organize my files in multiple ways and, for me, Categories make that possible. With IMatch 5, Mario has added a lot of possibilities for what can be accomplished with keywords but keywords still do not compare to what can be accomplished with Categories. I would recommend that all IMatch 5 users read the Category and keyword topics in the help files. Understanding what can be done with each will help us decide when and where to use them.

[ChrisMatch]

Thanks for your replies - they help me (and others) to get a better feeling for what to do 

I think it's fair to say that even the long-term beta testers are still in the process of deciding to what extent to use categories and to what extent to use keywords.

Fine, I take this as a hint that the decision is not that clear at all - no right, no wrong - very depending on ones needs.

Now with the @Keywords Category that difference is even less distinct however Categories still have many advantages over keywords. How important those advantages are will vary from on IMatch user to the next.

Personally I prefer the information to 'travel with the files' (using the sidecar XMP) so other applications and persons can make use of this information too.
@Richard: I would be very interested in your opinion about which advantages the normal Categories have over the keywords in iMatch 5 (other than not rewriting to files).

So for now I would decide like that:
*) For information that is used to categorize the image itself (project, location, person,...) I use the @Keywords.
*) For information that are more temporary and are not needed outside of iMatch (e.g. to organize the workflow - something like workflow.status.needs_retouching) I will use Categories.

Thanks - finally I have a plan 

[BenAW]

There is a lot of information that "travels with the image": all the information that the camera manufacturers store in the image when you press the shutter. This info can be used to setup eg. a multilevel datadriven category showing Camera Make, with sublevels for Camera Model, again with sublevels for Lenses used etc. etc.
So the normal categories have a lot more power than the simple keywords.

[cytochrome]

To check, open the Keywords Panel and select one of these files. I'm sure the location is contained in the file as a keyword.

Yes, it is In fact the whole location (country, Province, etc) is in the keywords. It is only for some folders, and I was not aware of it. At a time I played with some scripts, must be a left over... Doesn't do any harm.

Still learning (and I bought IM in 1996!!!

Francis

[Mario]

Yes, it is In fact the whole location (country, Province, etc) is in the keywords.

You can select the files in question in the file window, then remove these keywords in the Keyword Panel. This will remove these keywords from all selected files at once, if you don't want them anymore.

...(and I bought IM in 1996!!!

I hope IMatch 5 can convince you to buy again this year 

[ChrisMatch]

So the normal categories have a lot more power than the simple keywords.

What 'power' is left to normal categories if we are not talking about data-driven or formula categories?
Those normal categories are very similar to Keywords in iMatch 5 - or what am I missing?

[Richard]

Hi Chris,

In many ways the @Keyword Categories are similar to normal Categories but they are not the same in many ways. I can combine Categories, to produce new results, in ways that can not be done with keywords. Or I would need to put things in as keywords that I do not want to be part of the file. Another thing against keywords is that IPTC does have limits on the number of characters that can be in keywords. As I recall it also has a limit about the overall size added to a file. Since many still rely on the legacy IPTC and do not recognize hierarchical keywords or keywords totaling over, as I recall, 64 characters, for compatibility one should stay within the IPTC standard. However, staying within that standard puts a limit on what can be done with keywords in IMatch 5.

IMatch 5 could be in beta testing for months. While it is in beta testing it should not be used for production. My point is that you have a long time before you need to decide whether to use Categories. My opinion is that folks should use this time to learn what IMatch 5 can do and then learn how to do what they want. Only by using existing features as intended can bugs be found. Another of my opinions is that a person should learn what IMatch 5 can do before asking for features. Especially features that were in IMatch 3 but are not in IMatch 5. They were not forgotten, there is a reason why they no longer exist. Most often is that they have been replaced with features that can do the same task better and easier. 

In short, we should all be reading, learning and testing during beta testing.

[ChrisMatch]

Hi Richard
Thanks for your reply.

Another thing against keywords is that IPTC does have limits on the number of characters that can be in keywords.

This is the kind of information I was hoping for - the help file can't tell us everything - and your experience and knowledge (and that of others here) is invaluable.
Thanks for sharing - it helps to make a reasonable decision.

I can combine Categories, to produce new results, in ways that can not be done with keywords.

This is something I havn't realized yet and it sounds like I have missed an important point.
As far as I found out it is possible to define formulas that combine @Keywords.
Could you please give me a hint which 'combination of catgories' you have in mind?

Another of my opinions is that a person should learn what IMatch 5 can do before asking for features.

And I would go even further and say: you should read the appropriate help file section before asking a question. I try to stick to this rule myself 

[Mario]

As far as I found out it is possible to define formulas that combine @Keywords.

Exactly. This is one of the benefits of IMatch mirroring the keywords in your files in @Keywords. Using keywords in category formulas or the @Builder would not be possible otherwise.

[Richard]

Hi Chris,

Could you please give me a hint which 'combination of catgories' you have in mind?

First let me clarify that I do have Categories that are not mirrored by keywords. Even some that are mirrored by keywords can not be combined due to the length of my labels and the limits in IPTC. Keep in mind that IPTC has been a vital part of my sharing of photos with family members. One of my family related Categories is labeled "Documents". Some files in "Documents" are scanned documents and thus image files. Others are text, copies of email, etc. My main Category is labeled "Lineage" and has a child category for each family member. Any file that I have which pertains to a person is assigned to his or her child category. If I select one of these child categories the results are a mixture of pictures of that person and documents. All documents are also assigned to the "Documents" category.

By combining "Lineage" and "Documents" in a third Category I can end up with only the pictures of the person without the clutter of documents. I can not do this with @Keywords Categories due to the fact that not all files contain keywords and thus do not appear in @Keywords. I also have a Category I will call "Private" and although files in that Category could have keywords, I do not assign keywords because I want those files excluded from my genealogy work. I have confidential information about family members that I must keep confidential yet need to store the information.

The net result is that I can combine my "normal" Categories in ways that are not available with my @Keywords Categories.  IF every file that a user has in IMatch is assigned ONLY to Categories represented by keywords then that user can do what I do with "normal" Categories. However, keep in mind that any file assigned to any keyword has that keyword in XMP. If you share that image with someone, they will also see every keyword/category to which you have assigned that image.

I feel it is far better to assign files to "normal" Categories so one can be selective about what keywords are assigned to each file. Category assignments are stored in the database and thus as private as your database. keywords are intended to be shared along with the file and include all keywords to which that file has been assigned. How any of this will pertain to any given IMatch 5 user will depend on what that user does. @Keywords Categories are Categories just as "normal" Categories are, so whether you use one or the other or a combination depends on your needs.

[ChrisMatch]

Thanks Richard
I think I see what you mean.