[ https://issues.apache.org/jira/browse/TIKA-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503778#comment-14503778 ]
Tyler Palsulich commented on TIKA-1607: --------------------------------------- Good idea! What if you created a subclass of {{Metadata}} ({{ExtendedMetadata}}?) which supports mapping to a {{List<Map<String, Object>>}}. Then, when populating the metadata with a phone number, you can check if {{metadata instanceof ExtendedMetadata}} and respond accordingly. Any drastic changes would be a good candidate for Tika 2.0. > Introduce new HashMap<String, Object> data structure for persitsence of Tika > Metadata > ------------------------------------------------------------------------------------- > > Key: TIKA-1607 > URL: https://issues.apache.org/jira/browse/TIKA-1607 > Project: Tika > Issue Type: Improvement > Components: core, metadata > Reporter: Lewis John McGibbney > Assignee: Lewis John McGibbney > Priority: Critical > Fix For: 1.9 > > > I am currently working implementing more comprehensive extraction and > enhancement of the Tika support for Phone number extraction and metadata > modeling. > Right now we utilize the String[] multivalued support available within Tika > to persist phone numbers as > {code} > Metadata: String: String[] > Metadata: phonenumbers: number1, number2, number3, ... > {code} > I would like to propose we extend multi-valued support outside of the > String[] paradigm by implementing a more abstract Collection of Objects such > that we could consider and implement the phone number use case as follows > {code} > Metadata: String: List<HashMap<String,String>> > {code} > Where Object could be a Collection<>HashMap<String/Property, String/int/long> > e.g. > {code} > Metadata: phonenumbers: [(+162648743476: (LibPN-CountryCode : US), > (LibPN-NumberType: International), (etc: etc)...), (+1292611054: > LibPN-CountryCode : UK), (LibPN-NumberType: International), (etc: etc)...) > (etc)] > {code} > There are obvious backwards compatibility issues with this approach... > additionally it is a fundamental change to the code Metadata API. I hope that > the <String, Object> Mapping however is flexible enough to allow me to model > Tika Metadata the way I want. > Any comments folks? Thanks > Lewis -- This message was sent by Atlassian JIRA (v6.3.4#6332)