Hi, On Sun, Feb 8, 2009 at 4:57 PM, Jonathan Koren <jonat...@soe.ucsc.edu> wrote: > On Feb 8, 2009, at 5:55 AM, Jukka Zitting wrote: >> On Sun, Feb 8, 2009 at 6:22 AM, Jonathan Koren <jonat...@soe.ucsc.edu> >> wrote: >>> The problem with all these metadata standards is that they're all dumb in >>> the sense that they duplicate effort. >> >> Agreed. So why would we want to duplicate the effort in Tika? > > Because someone is going to be stuck doing it anyway.
Why? The metadata keys I proposed are semantically equivalent to the custom keys we use now. Why would someone need to specify custom keys when standard alternatives for the exact same concepts already exist? Note that I'm only proposing that we change the keys of the six metadata entries I listed. I have a concrete use case where doing this would be beneficial: My employer is building a digital asset management application where we plan to leverage XMP for metadata handling. Rather than explicitly mapping each individual Tika metadata key to equivalent XMP entries, it would be much easier and clearer to just map the "tiff" and "xmlDM" prefixes to appropriate XMP namespaces when importing Tika metadata. We also wouldn't need to keep updating the metadata mappings whenever new Tika versions start supporting new keys. Is there some better way for us to implement this use case? Are there clients that would be adversely affected by this change (apart from the obvious backwards compatibility issue that I don't consider too serious for a 0.x release)? BR, Jukka Zitting
