Custom XMP - addititional observations and questions

[PhilBurton]

I've been doing more experiments with custom fields, and here is what I have observed. I'm doing this post so that people with more experience can correct me if necessary. Also, for anyone interested in adding custom fields, this thread may prove useful.

1. Creating a custom field makes that field available to all images in the catalog, even though that were in the catalog before that custom field was created.
2. The XMP file for an image will have a line item for that custom field, e.g. icd:customfield, only if that custom field is non-blank.
3. If there are four custom fields defined, but only two have data, then only those two fields will have XMP file entries. The others will not. All images without any custom field data will have no icd:customfield entries in their XMP files.
4. Custom fields can be added to a catalog by importing an image containing custom field definitions. The result is the same as if those fields had been added to an image already in the catalog.

My questions:
1. Is there any way to force icd:customfield output into an XMP file, even if the field is blank?
2. Is there a way to directly connect Microsoft Access with the PSu SQLite database and use Access as a "front end" for custom fields?
3. Can a custom field be removed from a catalog?

Thanks,

Phil

[Hert]

Custom XMP is like any XMP, no difference except that they're written in the ics scheme, just like any other field writes to their own name.

1. That is how XMP works
2. Never do so as you won't know what related tables need updating when writing XMP to the database. You could end up ruining your database or resulting in unexpected behavior of the application. Never ever ever (did I say never?) update the database with 3rd party tools.
3. You can clear the field, just like any other field.

In general I get the impression that you think that custom XMP differs from defined XMP, they are not. The great thing about XMP is that it is extensible and hence there's no such thing like "standard XMP" or "custom XMP". In PSU we use the term custom XMP to talk about fields that you created your own. Custom XMP is a PSU term, not a XMP term.

[PhilBurton]

Custom XMP is like any XMP, no difference except that they're written in the ics scheme, just like any other field writes to their own name.


2. Never do so as you won't know what related tables need updating when writing XMP to the database. You could end up ruining your database or resulting in unexpected behavior of the application. Never ever ever (did I say never?) update the database with 3rd party tools.

I would like to have drop-down menus control allowable inputs to certain custom fields, and I can do that in Access. If I should not do a direct connection between Access and the PSu SQLite database how should I approach what I want to do?

[fbungarz]

Hi Phil,
I agree that it would be very convenient to be able to fill-in fields from a third-party database, but unfortunately, as far as I know, does not exist.
As far as I know, the import from CSV script is currently the only option to import data from an external source:
http://repository.idimager.com/openreso ... D96EA3BFD6

Personally, I do not find it particularly useful though, because the only way it works is by matching the file name with the spreadsheet data. In a previous version of the script written for IDI it was possible to match the spreadsheet data also with some metadata in a particular XMP field. Now it only works by using the filename. This of course is extremely limiting the versatility of the script, because you typically have several photos of the same object in an external database and not the other way round - several objects in one and the same photo.

Much more elegant would be an option to directly access fields from an external database (perhaps via ODBC - perhaps something for a Mantis feature suggestion? I would definitely support this!). In theory directly modifying the SQLite database on which PSu runs should also be possible, but of course it requires an intricate understanding how the PSu catalog database is built. As Hert rightly points out, if you do not know what you are doing, you can easily ruin your PSu catalog that way...

BTW - are you aware that PSu allows you to fill in entire sets of metadata fields by assigning only one single label? Right click the label and look at Details - Metadata Settings - Apply Detail Profile. It is a very powerful way of quickly filling in a whole set of metadata fields by applying a single label only. In my case I am using it to simply apply a locality acronym as a label and have it fill in all GEO-data as well as the country, state/province, etc. etc. of a particular locality...

Perhaps that helps.

Cheers,
Frank

[sanphotgn]

I would like to have drop-down menus control allowable inputs to certain custom fields, and I can do that in Access. If I should not do a direct connection between Access and the PSu SQLite database how should I approach what I want to do?

The autocomplete in PSU basically works as a drop-down menu. I have a few custom fields that contain very specific data. Start typing and the relevant entries appear as choices.

Autocomplete.png (4.19 KiB) Viewed 5873 times

[fbungarz]

And you can even edit these lists. look in your PSu directory in the folder called "Vocabularies"...
[Not the same as a limited list drop-down menus, but pretty close].

[vlad]

As Hert rightly points out, if you do not know what you are doing, you can easily ruin your PSu catalog that way...

FWIW, I fully agree: messing around with the database outside PSU is simply asking for trouble. You've been warned!

BTW - are you aware that PSu allows you to fill in entire sets of metadata fields by assigning only one single label? Right click the label and look at Details - Metadata Settings - Apply Detail Profile. It is a very powerful way of quickly filling in a whole set of metadata fields by applying a single label only. In my case I am using it to simply apply a locality acronym as a label and have it fill in all GEO-data as well as the country, state/province, etc. etc. of a particular locality...

In addition, you could simply map a label to one or more metadata fields, including custom fields.

[PhilBurton]

I was not aware that a label could map to multiple metadata fields. That's awesome!

And yes, I am not going to try a direct interface between MS Access and the PSu database. I have been warned.

Phil