Delimited Keywords

[ferdinand-paris]

When you are thinking iMatch hierarchical categories, that is a totally different thing from keywords.

Yes ... and no. If that is the case how come I have an image with an iMatch hierarchical category of "Who.Family.Jean" and in the IPTC keyword field there is "Jean"?

Keywords for me is explicitly the IPTC keyword field where I think hierarchical keywords are completely wrong.

I agree with this. Strongly.

F_P

[afx]

When you are thinking iMatch hierarchical categories, that is a totally different thing from keywords.

Yes ... and no. If that is the case how come I have an image with an iMatch hierarchical category of "Who.Family.Jean" and in the IPTC keyword field there is "Jean"?

Keywords for me are single words as specified by ITPC.
You can derive them form hierarchical categories and depending on the program that is more or less easy, but I consider them completely unrelated unless the user establishes a custom link.

cheers
afx

[tstoddard]

... if you include the iptc extension standard (which ASP opts to ignore) there are no less than three different places in which you could store geographic information about the content of the image in the iptc namespace.

Which ones?

The iptc standard was expanded in 2010 to include a "Core" schema and an "Extension" schema. Here is a link to a document that explains and defines the standard. You are obviously aware of the fields in the Core schema where location metadata belongs. In the Extension schema there is a property named "Location Shown in the Image" inside which location details can be placed and there is a property named "Location Created", which also hold location details. The Extension standard uses a data structure to hold the location data but it contain basically the same fields (Country, Province or State, City, etc...).

One reason that I put geographic information in my keywords is because I use a program that enables me to map keywords to iptc fields and to cascade that mapping functionality. As I explained earlier, when properly configured, Photo Supreme or IDImager (and I think iMatch) will enable you to populate a multitude of iptc fields just by assigning one keyword. This is tremendously time saving and much less error prone than manually populating iptc fields.

So you duplicate information in a non standard way and rely on non standard behavior in software.

In the Overview section of the "standard" it states: "This allows users to decide whether ...
- ... to use only the IPTC Core schema that has a higher backward compatibility, but less refined metadata
- ... or to use the IPTC Core and the IPTC Extension schema with refined and specialised metadata, but restricted backward compatibility."

Not a good idea.
As that stuff is application specific you should not expect it to be transparent for other applications.

So what you're really saying is that I shouldn't expect applications to update themselves to support new standards.

As long as there is no real standard for hierarchical keywords and the quasi standard is what LR does, I would not use anything but what LR uses.

I have already conceded that it is not a good idea to write delimited keywords out to the iptc keywords field. My argument refers to using hierarchical labels inside the DAM application that I'm using. I think my mistake was to refer to the hierarchical category/label structure used by my DAM software as "hierarchical keywords". I think that is what is causing some of the confusion here. As in iMatch, Photo Supreme maintains a separate database that stores the categories and labels that get assigned to images. What gets written to the iptc fields, including the iptc "keywords" field is completely up to the user. In fact, one option that Photo Supreme offers is to write "LR Hierchical Keywords" to the file as well as its own hierarchical structure. The problems I've been having are a result of the options I selected for what I wanted Photo Supreme to write out to the file and how ASP interprets what is written. However, what is written to raw files is only written into the xmp sidecar file so now we need to discuss xmp standards if we want to understand how ASP interacts with data written by Photo Supreme. That is an entirely different animal. Grubernd has already begun that conversation.

I'll have to get to that subject in a subsequent response.

[afx]

One reason that I put geographic information in my keywords is because I use a program that enables me to map keywords to iptc fields and to cascade that mapping functionality. As I explained earlier, when properly configured, Photo Supreme or IDImager (and I think iMatch) will enable you to populate a multitude of iptc fields just by assigning one keyword. This is tremendously time saving and much less error prone than manually populating iptc fields.

So you duplicate information in a non standard way and rely on non standard behavior in software.

In the Overview section of the "standard" it states: "This allows users to decide whether ...
- ... to use only the IPTC Core schema that has a higher backward compatibility, but less refined metadata
- ... or to use the IPTC Core and the IPTC Extension schema with refined and specialised metadata, but restricted backward compatibility."

I was referring to your hierarchies, not the IPTC standard.

Not a good idea. As that stuff is application specific you should not expect it to be transparent for other applications.

So what you're really saying is that I shouldn't expect applications to update themselves to support new standards.

There is no hierarchical keyword standard. I was definitely not referring to updated IPTC standards that have more specific fields.

As long as there is no real standard for hierarchical keywords and the quasi standard is what LR does, I would not use anything but what LR uses.

I have already conceded that it is not a good idea to write delimited keywords out to the iptc keywords field. My argument refers to using hierarchical labels inside the DAM application that I'm using.

Inside is the key word here. Do not expect this to be portable.

cheers
afx

[ferdinand-paris]

There is no hierarchical keyword standard. I was definitely not referring to updated IPTC standards that have more specific fields.

The field XMP:HierarchicalSubject is used by Adobe applications and others that seek to interoperate with Adobe products. I think it's correct to say that it's not part of the standard, although I can't be sure. But that doesn't alter the fact that this field is in increasingly common usage.

So one strategy would be to use hierarchical categories in your DAM to organise the keywords, which I personally find invaluable, and then write flat versions into IPTC:keywords & XMP:Subject, and to write the hierarchical form to XMP:HierarchicalSubject (using | as the delimiter). This is a valid approach and can be done without creating problems.

F_P

[tstoddard]

afx,

I think we have misunderstood each other. I think I understand your point and I don't disagree.

I was only trying to illustrate some of the advantages of maintaining a hierarchy inside my DAM. Like I said, I concede that using delimited keywords is not a good practice. I'm still not sure why you think that including geographical terms in my keywords as well as in iptc fields is "duplicating information in a non standard way". I think doing that can be easily justified in many instances.

I was really responding to those who have expressed the opinion that "hierarchical keywords" are more trouble than they're worth. My point is that if your DAM uses a hierarchy effectively the benefits can be substantial, especially if you are using all of the iptc fields and you can associate you category labels to those fields. The fact that the category/label hierarchy in my DAM essentially represents a "keyword hierarchy" is what seems to be confusing the issue. Since there is no established standard for keyword hierarchies, when people refer to "hierarchical keywords" I assume that they are referring to the constructs used by various software to represent a keyword hierarchy. That is why I have been referring to my category/label hierarchy in terms of hierarchical keywords. I was not trying to advocate the use of "delimited keywords".

I hope you don't take offense to me challenging you statements. This type of back and forth is how I gain a more thorough understanding of these topics and I find it extremely useful.

Thanks!

[afx]

The field XMP:HierarchicalSubject is used by Adobe applications and others that seek to interoperate with Adobe products. I think it's correct to say that it's not part of the standard, although I can't be sure. But that doesn't alter the fact that this field is in increasingly common usage.

So one strategy would be to use hierarchical categories in your DAM to organise the keywords, which I personally find invaluable, and then write flat versions into IPTC:keywords & XMP:Subject, and to write the hierarchical form to XMP:HierarchicalSubject (using | as the delimiter). This is a valid approach and can be done without creating problems.

But my understanding of this filed is that it is only one. So you only have one hierarchy in here which seems to be quite limited.

cheers
afx

[grubernd]

the classic IPTC field for hierarchies are the "Supplemental Categories". i think imatch uses that by default. right?

Adobe replicated that behaviour with the HierarchicalSubject field in the xmp.

my guess is they implemented the splitting up of their hierarchy into keywords as a fallback-strategy for software that cannot cope with hierarchies and doesnt want to show the user some superlong almost none-sensical keywords with delimiters in them while making the metadata available in some way. as we can see from the behaviour of ASP, this is exactly what happens.. the singular parts of a hierarchicalSubject are not doubled as single keywords as long as the delimiter is understood.. and for ASP the "/" is not a valid delimiter.

another great example of adobe's "we know better because we don't think ahead" approach to creating standards. adobe is able to create great software, but their record of defining sensible standards is so bad that any sane person with a little forwardthinking would reject any of those designs as "nice, but not futureproof". what happened to "with great power comes great responsibility"?

[ferdinand-paris]

But my understanding of this filed is that it is only one. So you only have one hierarchy in here which seems to be quite limited.

If you mean that you can only enter one category from your DAM = one hierarchical keyword, this is incorrect. It's a multiple entry field, like XMP:Subject.

the classic IPTC field for hierarchies are the "Supplemental Categories". i think imatch uses that by default. right?

Also incorrect, insofar as the default software is concerned. It has been the practice of quite a few users to use scripts to backup their categories into this field, and also to put flat versions of certain categories into IPTC:Keywords, but in no way can it be said to be an iMatch default. It's also an abuse of this field and clutters the IPTC, which is why I stopped doing it.

Adobe replicated that behaviour with the HierarchicalSubject field in the xmp.

Since it wasn't an iMatch default I don't think it can be said to have been replicated. The idea of hierarchies is used widely, as can be seen for example by the number of products that support David Riecks' "Controlled Vocabulary", which is *not* just for scientific users. While I'm no fan of Adobe, I think you're over-reaching to describe their motives as you did, except for their steamroller-like behaviour

My point remains that it is possible to export DAM hierarchical categories as both a hierachicy and as flat keywords in ways that are useful and do no harm.

Returning serve, IMHO if you are keywording files and are able to survive without using the organising benefits of a hierarchy, then either you don't shoot a wide variety of subject material or you don't have enough keywords.

F_P

[afx]

Returning serve, IMHO if you are keywording files and are able to survive without using the organising benefits of a hierarchy, then either you don't shoot a wide variety of subject material or you don't have enough keywords.

Actually the other way around. The more diverse the stuff I shot got, the more of a PITA hierarchical keywords turned out to be.
Which then resulted in me using them only for workflow stages and other meta info that would not make sense in the exported keywords anyway.

cheers
afx

[tstoddard]

This topic has taken many interesting and informative twists that I have learned from, but, I'd like to go back to my original post and answer my original question in order to bring closure to it. While none of the previous responses have correctly answered my original question, they have helped to lead me to the correct answer. My original question was:

I am writing my keywords in a delimited format so that a keyword might look like this: "Places/United States/Pennsylvania/Gettysburg" (all one keyword). When AfterShot Pro opens these files I end up with the following keywords: "Places/United States/Pennsylvania/Gettysburg","Places";"United States";"Pennsylvania";"Gettysburg". This would not be a concern to me if it only appeared in AfterShot Pro. However; if I output a jpg from the raw file and embed my metadata into it, which I want to do, then I get the extra keywords in my jpg. Is there some way to prevent AfterShot Pro from "flattening" the delimited keywords and then adding them along with the delimited keywords?

The correct answer is no, but not for any of the reasons given in the responses. The reason that ASP is adding "flattened" keywords to my iptc keywords field is that I had been writing Ligthroom keywords to my xmp files. This was happening because of a setting that I chose in my DAM software back when I first started experimenting with it. That program allows me to read and/or write Lightroom keywords to my files so that I can have my hierarchy in Lightroom if I choose to use both programs. I realize the error in my ways and could justify it but there's no point in wasting everybody's time with that lengthy explanation. Anyway, what my DAM does if I enable writing Lightroom keywords during synchronization is it writes a "|" delimited keyword into the xmp file as if Lightroom had put it there. Aftershot Pro then took that delimited phrase and broke it into flat keywords the same way that Lightroom would have.

While I appreciate ASP's effort to provide compatibility with Lightroom, I do wish that it would allow me the option not to read Lightroom's keywords. In other words, ASP does it whether I want it to or not. I realize that it's no big deal since I shouldn't have been doing it that way anyway and that it would be rare for somebody else to have the same experience.

I would like to respond to the statements grubernd made relating to the use of the "/" character as a delimiter.

if Photo Supreme suggests to use "/" as a delimiter, tell them it's a bug.

Photo Supreme doesn't suggest the use of "/" as a delimiter, it offers me the option to use "/" so that I can write keywords in a manner that will allow me to use my hierarchy in Windows Photo Gallery. It also offers to let me use "\", ".", or "|" if I want to.

PPS: "/" as a delimiter is a very bad idea anyway because it is heavily related to file system structures on all *nix systems, which includes Macs, and is also part of xml structural code. "|" or ";" arent without any other usages, but at least they are more neutral if that makes any sense.

I can't disagree with your logic but I can tell you that it was a decision Microsoft made years ago and still implements today. I found a blog somewhere when I was researching this where a representative from Microsoft explained their logic for using the "/" character. I don't recall the logic but suffice to say they did deliberately select it and build it into the Windows Live Photo Gallery. If you're like me you live in a home with more that one computer. Some of those computers are used by other family members who don't have DAM software installed. Their preference is to use the tools that are provided by their operating system, Windows. I chose to use the "/" character so that they could take advantage of the hierarchy that I was creating in my DAM. You may not agree with Microsoft's logic but you have to admit that Windows Photo Gallery is probably one of the widest used photo viewing and organizing tools in the world. Photo Supreme is simply offering users the ability to conform to various industry practices, not just Adobe's.

[grubernd]

interesting.

because if you look really close at my post containing the code-bits in it, your analysis is contradicting with what i found while testing ASP only. as long as the delimited keywords and the flat keywords in the xmp file match, then ASP will not import the flat ones at all. as i said.. tested with ASP-written xmp files only. maybe you can compare an xmp from Photo Supreme and and xmp from ASP (regular xmp, not the ASP format) and see what's the difference and what triggers the import of the flat keywords.

[tstoddard]

grubernd,

When I set Photo Supreme to "write Lightroom hierarchical keywords", this is the xmp that is generated:

Code: Select all

      <dc:subject>
        <rdf:Bag>
          <rdf:li>Places/United States/Pennsylvania/Home/Dillsburg</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <lr:hierarchicalSubject>
        <rdf:Bag>
          <rdf:li>Places|United States|Pennsylvania|Home|Dillsburg</rdf:li>
        </rdf:Bag>
      </lr:hierarchicalSubject>

If I don't write the Lightroom keywords it just puts the "/" delimited keywords in the <dc:subject> tag and the jpeg that Aftershot creates only includes my delimited keyword and no flat keywords.

[grubernd]

bingo.

if you use "|" then ASP will omit the flat keywords.

[tstoddard]

No, you have misunderstood. If Photo Supreme writes what it considers "Lightroom hierarchical keywords" to the xml file, using the "|" delimiter, then ASP DOES put flat keywords in my iptc field upon creating the jpeg. If I tell Photo Supreme not to write the Lightroom hierarchical keywords, but, I still include my own "/" delimited keywords, then ASP leaves them as is. In other words, ASP writes out my delimited keywords with the "/" delimiter and it DOES NOT put the flat keyword in the iptc field. This is what I wanted in the first place. My point is that the only reason ASP was adding keywords to the keywords field is because I included the Lightroom hierarchical keyword in the lr namespace in the xmp file. ASP interprets the "|" as a delimiter and it splits up the string to create flat keywords. I believe that's the way Lightroom would handle it so that's the way ASP handles it.