tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TIKA-1607) Introduce new arbitrary object key/values data structure for persistence of Tika Metadata
Date Tue, 11 Aug 2015 04:50:46 GMT

    [ https://issues.apache.org/jira/browse/TIKA-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681240#comment-14681240

Chris A. Mattmann commented on TIKA-1607:

Ray this is the exact approach we took in OODT. It's fully back compat. We used "/" as a group
and path prefix (and/or "_") and then supported a wide array of functions for back compat.

See: http://svn.apache.org/repos/asf/oodt/trunk/metadata/src/main/java/org/apache/oodt/cas/metadata/Metadata.java

> Introduce new arbitrary object key/values data structure for persistence 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.11
>         Attachments: TIKA-1607v1_rough_rough.patch, TIKA-1607v2_rough_rough.patch, TIKA-1607v3.patch
> 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:  Object
> {code}
> Where Object could be a Collection<HashMap<String/Property, 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

View raw message