Every metadata key Tika can emit is a Property constant (or, for runtime-minted names like scraped
HTML <meta> tags, a PassthroughPrefix) — there are no bare String keys. That closed/open key
space is tracked in a generated, build-gated registry, so adding a key involves one extra step beyond
writing the Java.
Add the Property to its interface as usual:
Property MY_NEW_KEY = Property.internalText(TIKA_META_PREFIX + "my-new-key");Naming conventions (frozen for 4.0):
-
Tika-coined keys use the
tk:namespace, kebab-case, no underscores. -
External-standard names are used verbatim, including the standard’s own prefix (
dc:,xmp:,cp:,extended-properties:). -
HTTP headers stay bare — no
http:namespace (Content-Type,Content-Encoding,Location).
The registry — three JSON files under tika-metadata-schema/src/main/resources/, listing every
declared key, every open-namespace prefix, and a field-provenance table — is generated from the live
Property/PassthroughPrefix declarations, never hand-edited. A committed copy is the reviewable
audit trail (a rename or dropped key shows up as a diff), and CI fails if it’s stale.
Run this after adding, renaming, or removing a Property or PassthroughPrefix:
tika-metadata-schema/regen.shIt installs the modules the change touched, regenerates all three registry files, sanity-checks the diff, and runs the gate tests. Commit the Java change and the regenerated JSON together.
Details, flags, and the traps this script exists to avoid (classpath scanning quirks, exec:java
vs. a forked classpath) are documented in tika-metadata-schema/README.md.