You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Lewis John McGibbney (JIRA)" <ji...@apache.org> on 2015/04/20 23:44:58 UTC

[jira] [Created] (TIKA-1607) Introduce new HashMap data structure for persitsence of Tika Metadata

Lewis John McGibbney created TIKA-1607:
------------------------------------------

             Summary: 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)