[
https://issues.apache.org/jira/browse/TIKA-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704880#comment-14704880
]
Ray Gauss II commented on TIKA-1607:
------------------------------------
I did see that, but I was after full URI namespaces, i.e.
{{http://purl.org/dc/elements/1.1/}}, not just prefixes.
The OODT approach looks like you'd have to shoehorn the "index" into the group
name, much like the tika-ffmpeg workaround, rather than a more strictly defined
structure.
OODT might support deeper structures in the inner {{Group}} class, but the
public methods appear to only support a single level? For example, How could
one get to something like the value of the city of the 3rd contact's 2nd
address, i.e. "p1:contact[2]/p1:address[1]/p1:city"?
We could mimic XPath syntax but the DOM approach allows us to use
{{javax.xml.xpath.XPath}} processing. From the [test mentioned
above|https://github.com/rgauss/tika/blob/trunk/tika-core/src/test/java/org/apache/tika/metadata/TestMetadata.java#L394]:
{code:java}
String expression = "/tika:metadata/vcard:tel[1]/vcard:uri";
assertEquals(telUri, metadata.getValueByXPath(expression));
{code}
The DOM approach would also allow us to leverage things like attributes to
further describe a particular metadata value in the future if need be.
We might also be able to "pass through" entire metadata structures that Tika
hasn't explicitly modeled.
It's certainly a larger change, but I think it gives us a lot more options.
> 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
(v6.3.4#6332)
