In case you're not aware, much has been done around EXIF, IPTC, and XMP in 
Apache Tika which uses the Drew Noakes library [1] for some of its work and 
there's a parser which wraps ExifTool [2].

Perhaps there's some opportunity to combine efforts?

Regards,

Ray

[1] http://www.drewnoakes.com/code/exif/
[2] https://github.com/Alfresco/tika-exiftool


On Jul 8, 2012, at 8:59 PM, Farrukh Najmi wrote:

> 
> There are two specs:
> 
> 1. IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
>   IPTC Extension Specification Version 1.0
>   Document Revision 2
>   
> <http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf>
>   (IPTC-PhotoMetadata-2008 spec)
> 2. IPTC - NAA Information Interchange Model Version 4
>   <http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf> (IIM spec)
> 
> 
> The IPTC-PhotoMetadata-2008 spec suprecedes the IIM spec from what I have 
> read. We should therefor be implementing the IPTC-PhotoMetadata-2008 (the 
> spec) and not the IIM spec.
> 
> The TODO comment is about the properties that are in IIM spec but not in 
> IPTC-PhotoMetadata-2008. I have chosen to leave them there for now. All the 
> IptcTypes.name field values are aligned with the XMP property id values from 
> the spec. That was the main change in the patch. I think we should change 
> IptcTypes.name field to IptcTypes.propertyId field and perhaps later add a 
> name field that aligns with the Name field values from the spec. BTW, I would 
> be happy to have a skype (skype id: farrukh_najmi) call to discuss this if 
> you would like.
> 
> 
> On 07/08/2012 11:34 AM, Damjan Jovanovic wrote:
>> You ask "TODO: What to do about properties not seen in
>> IPTC-PhotoMetadata-2008 (e.g. "Record Version"))"
>> 
>> Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
>> Scroll down to "IPTC ApplicationRecord Tags"
>> Those names seem to resemble what is in
>> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
>> onwards.
>> 
>> The names in your patch differ from that list.
>> 
>> ?
>> 
>> On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
>> <farr...@wellfleetsoftware.com> wrote:
>>> Oops. Here is the correct file this time.
>>> 
>>> 
>>> On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
>>>> Hi Farrukh
>>>> 
>>>> Your patch is just an empty file.
>>>> 
>>>> Regards
>>>> Damjan
>>>> 
>>>> On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
>>>> <farr...@wellfleetsoftware.com> wrote:
>>>>> Hi Damjan,
>>>>> 
>>>>> Attached is the patch for implementing the proposed change outlined in
>>>>> bullets below.
>>>>> Please review and then commit if satisfied or discuss further. Thanks.
>>>>> 
>>>>> 
>>>>> On 07/06/2012 02:29 PM, Farrukh Najmi wrote:
>>>>>> 
>>>>>> An example of a metadata property that has no IIM mapping defined is
>>>>>> Name:
>>>>>> Scene Code, XMP property id: Scene (page 15 of 55 in spec)
>>>>>> 
>>>>>> 
>>>>>> On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
>>>>>>> Hi Damjan,
>>>>>>> 
>>>>>>> Thanks for the +1. As I started on this patch I made some observations
>>>>>>> in
>>>>>>> the IPTC-PhotoMetadata-2008.pdfspec:
>>>>>>> 
>>>>>>>    * Not all metadata properties have an IIM mapping defined. For these
>>>>>>>      we will have to invent a type code. I propose we assign codes
>>>>>>>      starting at 10000 arbitrarily in such cases
>>>>>>>    * Every field does have an XMP property id at present. I am not sure
>>>>>>>      if there is any guarantee that future fields will have an XMP
>>>>>>>      property id. I think we should continue with XMP property id for
>>>>>>>      IptcTypes.name field but if in future versions there is no XMP
>>>>>>>      property id then the backup would be to use the Name field from
>>>>>>>      the spec
>>>>>>> 
>>>>>>> The only other alternative I can think of for IptcTypes.name field
>>>>>>> issue
>>>>>>> is to use the Name field from the spec which is guaranteed to be
>>>>>>> present,
>>>>>>> will never be translated but has the issue that it has white space in
>>>>>>> its
>>>>>>> content. My preference is to do what is proposed in bullets above.
>>>>>>> 
>>>>>>> Comments? Thanks.
>>>>>>> 
>>>>>>> 
>>>>>>> 
> 
> -- 
> Regards,
> Farrukh
> 
> Web: http://www.wellfleetsoftware.com
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to