Lookup Templates (user definable)

[akirot]

This is one for IM2021.

Basically the requested "Lookup Templates" (the name already defines the purpose) are an enhancement of Metadata templates.

There are many metadata fields that are related one to one (or many to one). Entering one value you already know the value of several other fields.

What I want to achieve (when filling in the metadata) is:

After hitting a specific key (or shortcut) a (predefined) metadata entry is taken as a lookup value and several other metadata fields are filled in automatically based on the contents of this specific lookup value.

A simple example:

Assume "City" is filled with "Frankfurt" the invoked lookup template fills in automatically:
"State/Province": Hessen
"Country": Germany
"Countrycode": DEU

An example using Darwin core:

"Vernacular name" is filled with "Hund" or "dog", the invoked lookup template fills in automatically:
"Scientific Name": "Canis"

A further example addresses the metadata fields for artwork according to Dublin core:

You enter the title of the artwork - the values for artist, material, dimensions, date of creation etc. are filled in automatically.

The idea is using "global attributes" to define the lookup tables. (All implemented locally by the user, no connection to data providing external services as e.g. geonames)
The user defines and fills in these lookup tables. This is similar to maintaining a thesaurus.

The Metadata templates need a mechanism to define the metadata tag to look for plus the definition of the lookup table and columns where to search for the attributes to be filled in. Analogue to the current behaviour of the Metadata templates the tags in scope are filled with the found attributes according to the definition the user has made.

This could also be used for translations.

[bekesizl]

+1

[lbo]

see also these recent threads:

https://www.photools.com/community/index.php?topic=11115.0 "Predefined keyword sets". Rene also suggested automatic additions in post 6.

https://www.photools.com/community/index.php?topic=11122.0 "Extend thesaurus synonyms to universal links". In the course of the discussion, I tended to display suggestions instead of auto-filling fields.

Beyond the fixed relations you describe, a suggestion system would remind the user about possible (but not mandatory) properties to add and even offer a selection, e.g. if the thesaurus entry has sub-elements: A road has a surface to be selected from concrete, asphalt, cobblestone etc.

An interesting question is the direction of the links. Should road link to surface or surface to road?

Oliver

[bekesizl]

It has similiar purpose, but when I look at this suggestion with the glass of a programmer, this one seems to be manageable easier than the others suggested.

[akirot]

My feature request is not about keywords (but not excluding them) - I wouldn't touch this already high sophisticated implementation.
The idea is to have a generic solution for ALL metadata tags managed by IMatch.
E.g. a similar mechanism already exists in the context of locations which are found based on given coordinates.
It would be a real timesaver and would raise quality of assigned tags because typos and errors resulting of (stupid) repetitive work are avoided.
No AI involved - KISS Keep It Simple and Stupid, just some lookup tables the user implements and maintains to his/her liking.

[sinus]

This is one for IM2021.

Basically the requested "Lookup Templates" (the name already defines the purpose) are an enhancement of Metadata templates.

All your example we can do already now with Metadata Templates. Easy.
But you think not to create only 10, 20 or 50 Metadata Templates, you want after hitting a key a kind of table pops up with a list, e.g.

Apple
Dog
England
Fred
Table
Palm Beach
Romania
...

And this list you could manage and fill out every time, you like.
Means, in case of Table there will be entries in different metadata tags and for Fred maybe other metadata tags and so on.

And then you will see this list and the entries, before you choose the correct line.
In this list above you would choose Fred, because this Fred is a relative of you and hence there is some information stored about Fred in different metadata fields.
If you enter another Fred, what is not a relative, you would simply not choose this line, but write Fred and enter other values.

And this list could have hundrets of entries, like the thesaurus.

Is this correct, do I understand this right?

[akirot]

All your example we can do already now with Metadata Templates. Easy.

You are wrong.

The current Metadata Templates handle/manipulate data already assigned to the image and/or insert (more or less) hardcoded values (exception: locations looked up based on coordinates).

To achieve the advantages Dublin Core and Darwin Core offer you need the possibility to fill metadata tags automatically by looking up the desired entries based on the value(s) in one (or even more?) other tag(s).

Following your approach would mean to have a template for each(!) animal, flower, work of art etc. - i.e. hundreds if not thousands of templates.

This is not what the current implementation of Metadata Templates is made for. Neither would it be the proper approach to speed up metadata entry.

Your milage may vary.

[sinus]

All your example we can do already now with Metadata Templates. Easy.

You are wrong
....

OK, so then I didn't understand what exactly you want.
That's why I asked if I had understood you correctly (this is probably due to my not very good knowledge of English.

[jmsantos]

A simple example:

Assume "City" is filled with "Frankfurt" the invoked lookup template fills in automatically:
"State/Province": Hessen
"Country": Germany
"Countrycode": DEU
...

+1

[mastodon]

+1 I don't want to make metadata templates for every city

[Mario]

+1 I don't want to make metadata templates for every city

You would not make MD templates for this, but locations.
Or let IMatch automatically reverse geocode your files, and avoid all typing. Which is what I do. I use locations for anything that is fixed, e.g. studio or venues or halls.

[sinus]

+1 I don't want to make metadata templates for every city

You would not make MD templates for this, but locations.
Or let IMatch automatically reverse geocode your files, and avoid all typing. Which is what I do. I use locations for anything that is fixed, e.g. studio or venues or halls.

Exactly, what I do.

[jmsantos]

I wish I could rely on automatic reverse geolocation, but the tests I've done with different systems don't satisfy me.

I have tried with Map integrated in Lightroom (Google), Geonames with Imatch and OpenStreetMap as LR plugin. None provides the same result or satisfactorily solves the administrative divisions of Spain: Country, Autonomous Communities, provinces and municipalities, that is, 4 divisions that must be included in 3 metadata fields (Country, State/Province and City). How do you do in Germany, with your Länder, Regierungsbezirk, Kreis and Gemeinde?

[Mario]

I have tried with Map integrated in Lightroom (Google), Geonames with Imatch and OpenStreetMap as LR plugin. None provides the same result or satisfactorily solves (...)

Different geo-coding services have different purposes.
Google is mostly interested in monetizing things by marketing and hence lacks in off-road terrain.
OpenStreetMap and GeoNames.org are volunteer-driven projects and usually have more detailed maps for off-road terrain, bikers and hikers. If not, you can add your locations to improve these systems for everybody.
HERE is owned by the automotive industry in Germany and focuses on highly-detailed and up-to-date street maps.

If the precision of all these services are not sufficiently good for your requirements, using IMatch locations (if you often geo-code the same place) or doing it manually or copying it from a 'master' image are good work-arounds.

I'm not adverse to the idea of setting up a complex system of inter-related tags as suggested in this FR (this comes up once or twice every year), or something resembling the powerful keyword links in the IMatch thesaurus (were assigning one keyword can assign 5, 20 or 50 other keywords). I have pondered this several times, but was always unsure if this would really be needed...

I wonder how many users will ever use this. If you have only 10, 20 or 30 cities, IMatch locations ("Frankfurt") or metadata templates (if you also need to fill non-location tags) or a combination of both (metadata template which assigns a location and also fills metadata tags) will do the job nicely.

And they are available already, today.

You can assign favorites to these templates to apply them with a single click or keyboard shortcut.
You can even combine multiple of your metadata templates in an Automation Favorite to apply them all at once, and do other things as well.

if you take photos at the same locations often, use locations.
If you take photos at a spot only once (e.g, vacation) select all files and fill in the data once in the Metadata Panel.

[sinus]

I wish I could rely on automatic reverse geolocation, but the tests I've done with different systems don't satisfy me.

I have tried with Map integrated in Lightroom (Google), Geonames with Imatch and OpenStreetMap as LR plugin. None provides the same result or satisfactorily solves the administrative divisions of Spain: Country, Autonomous Communities, provinces and municipalities, that is, 4 divisions that must be included in 3 metadata fields (Country, State/Province and City). How do you do in Germany, with your Länder, Regierungsbezirk, Kreis and Gemeinde?

It depends of course, for what I want use some informations.
GPS-data is for my business not important, means my clients does not use it.

Hence the gps-data is finally only for me, therefore it must not be totally correct.
I know, sometimes the information is even wrong.

See my attachements, one for Switzerland, one for Tenrife (I am not in Germany).
Switzerland is correct, I think.
Tenerife is surely not very correct, but for me is is good enough. 

[akirot]

The idea is to have a generic solution for ALL metadata tags managed by IMatch.

Locations are just an easily understandable example.

Think of controlled vocabularies (e.g. artwork, flora and fauna - you name it) where various entries depend on the (key) value of another tag.
(The IMatch location concept - however good it is - does not and can not address this.)

This would add value and make IMatch really unique from an Asset Management point of view.

[Mario]

Assume "City" is filled with "Frankfurt" the invoked lookup template fills in automatically:
"State/Province": Hessen
"Country": Germany
"Countrycode": DEU

What about the location tag (street or similar)?
What if I have multiple locations for the same City? How to deal with that?
I assume we would need a feature to link multiple 'sets' of tag values (each with tag key and the value) to any other value in a thesaurus, for any tag.
This would get quite complex, I guess...

Think of controlled vocabularies (e.g. artwork, flora and fauna - you name it) where various entries depend on the (key) value of another tag.

This is usually done via keywords, and using keyword links allows you to exactly this. You enter the English or Latin keyword, and the keyword link adds all related keywords, from any level or section of your thesaurus.

[akirot]

I assume we would need a feature to link multiple 'sets' of tag values (each with tag key and the value) to any other value in a thesaurus, for any tag.
This would get quite complex, I guess...

Yes, that's what the feature request is for, see my original request and idea for an approach to that:

The idea is using "global attributes" to define the lookup tables. (All implemented locally by the user, no connection to data providing external services as e.g. geonames)
The user defines and fills in these lookup tables. This is similar to maintaining a thesaurus.

The Metadata templates need a mechanism to define the metadata tag to look for plus the definition of the lookup table and columns where to search for the attributes to be filled in. Analogue to the current behaviour of the Metadata templates the tags in scope are filled with the found attributes according to the definition the user has made.

This could also be used for translations.

Yes, agreed, implementation might be a challenge - but basically it's a core/basic database function.

This is usually done via keywords, and using keyword links allows you to exactly this. You enter the English or Latin keyword, and the keyword link adds all related keywords, from any level or section of your thesaurus.

Unfortunately the IMatch keyword links are restricted to keywords only.

This FR is far ahead of keywords. Keywords are just one! metadata tag filled with multiple entries.

This FR is for handling ALL possible tags (including attributes) even future and not yet (by "standards") existing ones.
The user has to define the individually needed tags and the intended relationships - if IMatch only provided the mechanism for it ;-) .

[hluxem]

+1

For me this could be helpful for location data like country-state-city-location. I tried to use the location feature, but with as many locations I needed that wasn't efficient for me. I find using favorites with metadata templates for the location data for most cases the easiest. I do have a lot of templates, but once they are defined it's ok. I also use copy and paste from a custom metadata panel layout.

When I saw this request first, I thought it wouldn't help me much because I would have to define this for each location. I changed my mind recently when I was using the thesaurus with import from database feature. I think it could be done so you only have to define the relationship between the tags and then the values can be read from the database. I don't use keywords, so I don't know how the hierarchy feature works for keywords, but maybe this could be expanded to use for all metadata tags.
It sure would be nice to only select the location from a thesaurus and have the city, state and country filled automatically.  If there would be an option to define a thesaurus with a hierarchy/link for geodata with city, state and country (or any other tag), other tags could be filled automatically when the location is selected from the thesaurus. I think for me this would be straight forward as every location is unique. I would be fine to just pick the first entry to use for the thesaurus if the values are not unique, but that may be not enough for others.

Heiner

[Mario]

What you describe is a metadata template.

Changing the entire plumbing and workflow of the thesaurus so users can select a value for tag "A" (say, "City") and then have this tag linked in the thesaurus to a dozen values from a dozen other tag would be very hard to define and visualize in the thesaurus. I mean, a user would probably like to link "London" to 10 different values from 10 different tags, and "Paris" to 5 values from 5 other tags. How would that work?

Basically, what you want is

"I want to select a "city name", and then these n tags should be filled with these n values"

correct? Or, similar,

"I want to select an "author name", and then description, copyright, privacy statement, keywords, ..., should be filled with these values.

Which is what metadata templates do quite comfortably.

Even if such a feature would be implemented, I don't see a neat way to somehow break this into the thesaurus. A thesaurus element has no knowledge about other elements linked to other metadata tags. Each thesaurus hierarchy is linked to one specific tag only and does not know about other tags.

The feature requested here would require some kind of tabular input, where the columns indicate the tags to "sync", and rows the values for each tag and combination.
Later, selecting a value from a tag in this table would offer all matching rows of the table. And probably some extra handling when the user defined multiple tables based on the same tags and whatever. This can get complicated quite fast...



Not sure if such a feature would really something many users will ever need. We already have locations, we have metadata templates. In combination with favorites, this gives us a lot of flexibility and comfort for filling in lots of metadata automatically via a single keystroke or mouse click.

I have about 30 locations defined, for places I shot regularly. All other things I let reverse geocoding fill, or, when there are no good matches, I select the files and fill in the data by hand in the MD panel. This is usually only needed for places I visit for the first time. And, often, i only visit places once. Else I create a location or maybe a MD template.

[hluxem]

There are actually quite some responses on this topic, so it may get more use than it seems. But as said before, most users only use 5% of the functionality.

We're talking about several weeks of development effort here, by my estimate. A completely revamped Thesaurus UI with many additions (probably making it harder to use for all users who don't need this City linked to location, keywords, whatnot feature at all. A much more complex internal workflow. A much more complex processing of data entered by the user in the MD panel. New UI elements for suggestions etc. Quite a lot of work.
About a handful users has commented so far, and some of the comments are about non-related features. This does not satisfy me, sorry.

I APOLOGIZE. I've accidentally edited your post by adding my reply, instead of replying to it. Accidentally clicked modify instead of reply.
The important segment is included as a quote in my reply, though.

[Darius1968]

+1

[Mario]

You mean, something like zzis?



This is related to a feature I will introduce in the next major release of IMatch.

[akirot]

Looks promising!
Please don't restrict it to locations (as in almost all above made examples) - make it available to "all" metadata fields (meaning the same as the ones accessible by metadata templates).
The user should define (and fill in) the lookup tables according to the individual needs.

[Mario]

Like so?

[akirot]

Yes!
I already can envision the possibilities this gives for e.g. artwork and Darwin Core entries in general.
One important feature will be the user definable lookup tables - otherwise it would become a never ending support nightmare.

A comment to the user interface for the tables:
Foreseeing a lot of entries in the lookup tables a more tabularwise user interface would be appropriate (similar to the current attributes tables/rows).
Otherwise screen estate will be wasted making it difficult for the user to maintain the table(s).

[Mario]

You can copy & paste from Excel!
How many entries do you expect to use with this?

[akirot]

Just for locations I currently have about 2900 entries.

Thus the lookup tables should be fit for thousands of lines.

Coming back to the lookup tables - the screen shots of your current state of development don't show this:

The same lookup table should be usable for different mappings.
Thus the "Location" table as in your screen shot could be used for the "location taken" and the "location shown" too.

Using two (lookup) templates and only one lookup table the user does the assignment once for the taken and once for the shown location.
(The assignment could be made as already implemented in templates - now additionally using the lookup tables as source. Additionally a lookup table could be used even partially. )

Hope the basic idea comes across.

[Mario]

How many persons create images at 3,000 locations?
This sounds all very specialized and "handful of users only"?

Location created and location shown are two different sets of tags. The feature I have implemented for IMatch 2022/2023 is tag-based, allowing for quick and definitive lookups, e.g. in the metadata panel.
This enables users to type in a few characters (e.g. par for the city tag) and get a list of all "location sets" they have created where the city name contains par.
Or they type in part of the author name and with a single click fill in a complete set of author info, rights, address data etc.

Applying the same sets of tags/values to different tags as you apparently need would make all this more complex to implement for me and less comfortable for users to use.
I think that many users won't even see a need for this new feature, because they only need a few IMatch locations and maybe a handful of Metadata templates to get things done.

There may be 1 or 5 persons out there who have to deal with 3.000 different locations...

If you need to maintain the same data for two "sets of tags" (shown/created, in your example), you can copy the modified set into the clipboard and paste all contents into the other set to make them identical again.

[hluxem]

Looks nice and is all I need. I do like the copy and paste from Excel feature!

How many persons create images at 3,000 locations?

Interesting question. Don't know at how many different places I took pictures, but certainly more than thousand. I would expect that to be rather normal.

Heiner

[Mario]

I have tested this new functionality with up to 50,000 entries for "tag sets". Works very well. Should do for 1,000 or 3,500 locations.
And locations you will need to assign again? Creating Metadata Templates, IMatch Locations or using this new feature is usually only helpful when you need to re-apply your locations often...
Still, 3,500 locations seems to be a lot. Different use-cases I guess. I'm not a travel photographer and I'm usually happy with the city name. The rest I don't need.

[akirot]

I'm not a travel photographer and I'm usually happy with the city name. The rest I don't need.

Yes, ones mileage varies.

Probably locations are a too easy example.

Apparently you implement a feature different to the original request.

[Mario]

Apparently you implement a feature different to the original request.

This feature was already mostly finished before this request was even posted.
It is related, but more universal and more tightly integrated into the Metadata Panel and other features.
I think it covers what most users who +1'd her might neede. But maybe not all extreme/edge cases.

[akirot]

Probably we weren't on the same page as far as locations are concerned.

I don't use IMatch locations  (which you possibly had in mind when responding) at all.

Instead I make heavy use of IMatch categories  - and  my locations branch there contains about 3000 entries.

The feature request is for having a (user definable ) data pool (lookup tables) which serves as a source for pushing values into (again user defined) metadata tags based on a key (lookup value).
This is a generic approach and future proof (as long as Exiftool provides access to the respective metadata.)

This feature was already mostly finished before this request was even posted.

The feature request is from March 2021!
Yes I know, in these days it has become more and more difficult to get hold of the necessary specialists to get the job done 

Thank you!

[Mario]

The feature request is for having a (user definable ) data pool (lookup tables) which serves as a source for pushing values into (again user defined) metadata tags based on a key (lookup value).

This is what my feature does. You enter (part of) a tag value (e.g. city = "France") and then you can pick from all the "value sets" you have created where the city is France. By clicking on a result, the feature files the city tag, country code, country name, location, maybe GPS coordinates, adds keywords, etc. Whatever you have configured.
This is not linked in any way to locations, it works for all tags.

The feature request is from March 2021!

There are even older feature requests. Most get no feedback at all, or maybe a handful of +1 - which reads to me as "Nice to have but not really needed.".
Posting a feature request is always good. And I keep an eye on them, and how many users react.
But I also know what implementing a feature would cost, estimate how many users would use it, if a feature request is just useful for the user who posted it etc.
I also keep an eye on telemetry to learn which features IMatch users use, and how often.

Yes I know, in these days it has become more and more difficult to get hold of the necessary specialists to get the job done 

I'm the best developer I can afford.