Benutzerdefinierte XMP-Metadatendefinitionen

OMN liest und schreibt XMP-Metadaten, die auf Basis einer Reihe von XMP-Eigenschaftsdefinitionen in Assets eingebettet sind. Zusätzlich zu den mit OMN ausgelieferten Definitionen können Sie eigene benutzerdefinierte XMP-Eigenschaften registrieren — zum Beispiel, um projektspezifische Felder zu lesen oder zu schreiben.

In OMN6 wurden benutzerdefinierte XMP-Eigenschaften registriert, indem ein JAR mit Spring-Beans erstellt und dem Classpath hinzugefügt wurde. Dieser Mechanismus wurde in OMN7 entfernt. Benutzerdefinierte Eigenschaften werden nun in einer einzigen JSON-Datei definiert. Unter Migration von OMN6 erfahren Sie, wie Sie bestehende Definitionen konvertieren.

Die Datei xmp-custom.json

Benutzerdefinierte Definitionen werden aus einer einzigen Datei gelesen:

/usr/local/omn/config/xmp-custom.json

Das Verzeichnis ist ${OMN_HOME}/config; OMN_HOME ist standardmäßig /usr/local/omn.
Binden Sie die Datei in beide Container ein, den web- und den sync-Container — beide laden die Definitionen.
Nur diese eine Datei wird ausgewertet. Ihr Inhalt ist ein einzelnes JSON-Array von Definitionsobjekten.

Definitionsformat

Jeder Eintrag im Array beschreibt eine benutzerdefinierte XMP-Eigenschaft:

Feld Erforderlich Beschreibung

Feld	Erforderlich	Beschreibung
`identifier`	ja	Eindeutiger Bezeichner in der Form `prefix:Name` (z. B. `custom:MyField`). Wird als Schlüssel verwendet; ein Eintrag, der den Bezeichner einer integrierten Definition wiederverwendet, überschreibt diese.
`namespace`	ja	Die XMP-Namespace-URI, zu der die Eigenschaft gehört (z. B. `http://ns.apollon.de/custom/1.0/`).
`name`	ja	Der Eigenschaftsname innerhalb des Namespace.
`type`	ja	Der Werttyp, in Großbuchstaben geschrieben. Einer der `MetaDataXMPType`-Werte: `STRING`, `BOOLEAN`, `INTEGER`, `LONG`, `DOUBLE`, `DATE`, `CALENDAR`, `BASE64`, `BAG`, `SEQ`, `LANG_ALT`.
`description`	nein	Freitextbeschreibung der Eigenschaft.
`struct`	nein	Name der übergeordneten Struktur; nur für Eigenschaften, die zu einem strukturierten (verschachtelten) XMP-Typ gehören.

identifier

Eindeutiger Bezeichner in der Form prefix:Name (z. B. custom:MyField). Wird als Schlüssel verwendet; ein Eintrag, der den Bezeichner einer integrierten Definition wiederverwendet, überschreibt diese.

namespace

Die XMP-Namespace-URI, zu der die Eigenschaft gehört (z. B. http://ns.apollon.de/custom/1.0/).

name

Der Eigenschaftsname innerhalb des Namespace.

type

Der Werttyp, in Großbuchstaben geschrieben. Einer der MetaDataXMPType-Werte: STRING, BOOLEAN, INTEGER, LONG, DOUBLE, DATE, CALENDAR, BASE64, BAG, SEQ, LANG_ALT.

description

nein

Freitextbeschreibung der Eigenschaft.

struct

nein

Name der übergeordneten Struktur; nur für Eigenschaften, die zu einem strukturierten (verschachtelten) XMP-Typ gehören.

Das folgende Beispiel registriert eine einzelne String-Eigenschaft custom:MyField:

[
  {
    "namespace" : "http://ns.apollon.de/custom/1.0/",
    "identifier" : "custom:MyField",
    "type" : "STRING",
    "name" : "MyField",
    "description" : "Example custom XMP field"
  }
]

Einen benutzerdefinierten Namespace verwenden

Eine benutzerdefinierte Eigenschaft, deren Wert über die OMN-Benutzeroberfläche bearbeitet und gespeichert wird, muss einen eigenen Namespace verwenden (zum Beispiel http://ns.apollon.de/custom/1.0/). Verwenden Sie nicht ein kontrolliertes Adobe-Schema wie exif oder tiff erneut: Beim Speichern durchläuft der Wert einen internen XMP-Round-Trip, und eine Eigenschaft, die unter einem kontrollierten Adobe-Namespace geschrieben wurde, geht beim erneuten Einlesen verloren.

Änderungen anwenden

Starten Sie die web- und sync-Container neu, um eine geänderte xmp-custom.json zu laden.
Fehlt die Datei, startet OMN normal und verwendet nur die integrierten Definitionen.
Kann die Datei nicht geparst werden, protokolliert OMN einen Fehler und fährt nur mit den integrierten Definitionen fort — prüfen Sie das Container-Log, falls eine benutzerdefinierte Eigenschaft nicht erscheint.

Migration von OMN6

In OMN6 war jede benutzerdefinierte Eigenschaft eine Spring-Bean in META-INF/omn/spring/xmp-definitions.xml, verpackt als JAR. In OMN7 werden dieselben Felder als ein JSON-Objekt pro Eigenschaft ausgedrückt. Die Feldnamen sind identisch, sodass die Konvertierung mechanisch erfolgt.

OMN6 (xmp-definitions.xml):

<bean class="com.meylemueller.xmp.XmpMetaDataDefinition">
    <property name="namespace" value="http://ns.apollon.de/custom/1.0/"/>
    <property name="identifier" value="custom:MyField"/>
    <property name="type" value="STRING"/>
    <property name="name" value="MyField"/>
    <property name="description" value="Example custom XMP field"/>
</bean>

OMN7 (xmp-custom.json):

[
  {
    "namespace" : "http://ns.apollon.de/custom/1.0/",
    "identifier" : "custom:MyField",
    "type" : "STRING",
    "name" : "MyField",
    "description" : "Example custom XMP field"
  }
]

Zur Migration:

Erstellen Sie für jede <bean> ein JSON-Objekt und übernehmen Sie die Werte für namespace, identifier, type, name und description.
Fassen Sie alle Objekte in dem einzigen Array in /usr/local/omn/config/xmp-custom.json zusammen.
Entfernen Sie das alte JAR — es wird in OMN7 nicht mehr geladen.
Wenn eine migrierte Eigenschaft über die Benutzeroberfläche bearbeitet wird und einen kontrollierten Adobe-Namespace (z. B. exif) verwendet hat, verschieben Sie sie in Ihren eigenen Namespace (siehe Einen benutzerdefinierten Namespace verwenden).