page 25
IIM Urgency is 2:10 not 2:09
--
Patrick Peccatte
www.softexperience.com
www.pixpalace.com

At 11:52 AM 5/11/2008, Angela Murphy wrote:
>Cultural heritage organisations often use the information from their
>VRACore4 'Title' field as the short display caption on a website -
>with their contextual information going in a separate 'Description'
>field. I hope that your User Notes will add a cultural heritage type
>example (eg painting) to the existing photographic examples - and
>that you will confirm that the current definition stands.

Angela:

  From first glance, I would think that the VRACore4 "Title" is more
in alignment with the IPTC Core "Headline" field than "Title" in the
use you have described above.

IPTC Core "Headline" definition was: "A headline is a brief
publishable synopsis/summary of the contents of the photograph. The Headline
term should not be confused with the Title term."

http://www.iptc.org/std/Iptc4xmpCore/1.0/documentation/Iptc4xmpCore_1.0-doc-Cpan\
elsUserGuide_13.pdf
or
http://tinyurl.com/qw25p

David

--
David Riecks (that's "i" before "e", but the "e" is silent)
david@...  http://www.riecks.com/
Midwest/Chicago ASMP

First of all - congratulations to everyone who has worked so hard to put this
spec
together. Some of the changes that have been made are crucial to the use of
these
headers by many image providers - not least cultural heritage institutions.

I have a few comments which I hope are relevant - some have a particular
relevance to
cultural heritage usage. First I have a general comment - and then specific
detailed
comments on particularly important properties, including a few minor comments,
e.g.
typos etc.  Forgive me if I have misinterpreted any of the document.

IPTC Core schema 1.1

General
My first comment concerns the overall philosophy behind these proposed changes
to IPTC,
especially where they relate to the transfer of complex cultural metadata. I
very much
welcome the extensions that will make it possible to transfer core information
about
cultural heritage images within image headers. However, I am concerned that, in
the
process, IPTC has become too complex. As far as cultural heritage institutions
are
concerned, IPTC can never be a complete solution for the transfer of metadata
between
systems. Cultural heritage information is usually extraordinarily rich
(sometimes
overwhelmingly so) and the providers of this information either want to transfer
this
information wholesale (e.g. via XML or csv or excel files) - or they want to
transfer just
core information and ensure that interested image users will be driven back to
the original
databases where the most up-to-date information will be held. Once images have
left
their original source, the IPTC information is necessarily static and not the
result of the
latest research, rights transfers, licensing restrictions etc.

I therefore see this new complexity as a disadvantage in the instances where it
may imply
to image users that the information is complete - or even not likely to change.
Original
caption information for images is often necessarily brief (whether it is 1938 or
2008) and
the same obviously applies to works of art. When they add information,
collections holding
the original works may add considerable value to images. This is in parallel to
the many
concerns of originators re orphan works and the over-writing of credits etc. I
recognise
that a lot of work is going into ways in which creators can be referenced and I
hope that
this will also emphasise the importance of original source material.

Unfortunately, by trying to embrace so much information within image headers,
image
suppliers may set up unrealistic expectations in users about the currency of
this
information - whether it is copyright, credit or contextual information.

Given the many changes in the life of an image to its copyright status
(assignments etc),
agency status, and the instant redundancy of most contact details, it would seem
a more
realistic course to direct users to 'home' databases and/or Rights registries.
Digital images
may well get separated from the route to their source and rights information.
All the more
reason then to send potential users a message that this research must be
undertaken
before use

Is there a way of highlighting this - and date-stamping information - not just
the image ?
And, if this already exists, can it be made more evident ?

Specific comments
page 10
Headline - The use and definition of this field is clear in the IPTC Core
specification
document "Iptc4xmpCore_1.0-spec-XMPSchema_8.pdf" and Implementation Guidelines
"Iptc4xmpCore_1.0-doc-CpanelsUserGuide_13.pdf" which is downloadable from
<http://www.iptc.org/IPTC4XMP/>. However, this seems to be a much misinterpreted
field which is currently being used in a variety of ways (e.g. for collective
job names etc).

As described in this document and in your new draft spec, this is a very useful
field in
which to enter the title of a painting or other work of art (e.g. Édouard Manet,
A Bar at the
Folies-Bergère (Un Bar aux Folies-Bergère), 1881-2  or Ada King, Countess of
Lovelace,
1840) - or the short description of an object (e.g. Stephenson's 'Rocket', 1831
or
`Discovery' Space Shuttle at Kennedy Space Center, Florida, USA, May 1995).
[N.B. This is
'Title' as defined in the VRACore4 metadata schema]. As I understand it, this
would
complement the IPTC definition of usage.

Cultural heritage organisations often use the information from their VRACore4
'Title' field
as the short display caption on a website - with their contextual information
going in a
separate 'Description' field. I hope that your User Notes will add a cultural
heritage type
example (eg painting) to the existing photographic examples - and that you will
confirm
that the current definition stands.

page 10
Intellectual genre - Could this also include photographic genres e.g.
documentary, record,
portrait, etc ?

pages 8-13
Location, City, Country, Province or State, Sublocation - Your User Notes refer
to the
locations in IPTC Extended i.e. 'Location Created' and 'Location in the Image'.

I have a problem with the use of the English language here. 'Location Created'
is fine, but
'Location in the Image' does not sound right. No doubt you discussed this, but
could I
suggest ' Location of Subject' instead. This would also help CH users to
interpret this field
more clearly as this information would be derived from the Subject field in
VRACore4 i.e.
Element: Subject; subelement subject term type attribute: geographicPlace .

page 14
Date Created : XMP implementation: XMP namespace: 's' missing in photoshop

page 18
Credit Line
Definition: Suggest changing to "Expresses the person or organisation that must
be
credited for this content" and so on ...
User Notes: Spelling - "definition". Suggest following rephrase to clarify
meaning
" This element was named 'Provider' in IPTC Core 1.0 and this field was widely
used to hold
the Credit Line. We therefore suggest that this field is renamed 'Credit Line'."

page 19
Source
User Notes: The information in this field is important as it assists users to
identify the
holder of the moral rights in the image (who has a legal right to be
identified). This
persists even if the copyright is assigned elsewhere.
XMP implementation notes: Could rephrase this as "The information in this field
should
not be changed so that the image holds a permanent record of the first
rights-holder in
the image.  This also identifies the holder of the Moral Rights  (i.e. the right
to be
identified)."

page 20 Address (contact info detail)
Photo Help Text: Should include reference to "person or organisation that
created this
image"
To maintain consistency, this should also be added to other descriptors.

page 28
As above 'Location in the Image' might be renamed 'Location of Subject' or
'Location of
Image Subject' (?)

Model Age
Should we advise people to enter 'Under 18 years at time of photograph".

Name of organisation in the image
Rename as "Name of organisation of Image subject" ???

page 30
Digital Source File Type
Required CV: Would strongly recommend including digital negatives here (i.e.
Adobe
DNG).

page 31
Image supplier
Would it be correct to say (for clarity)  "Identifies the most recent supplier
of the image,
not necessarily the owner or creator"


page 32
Location Created
User Notes: In order to clarify this I would like to suggest that you add:
'This may be the same as or different from "Location of Image Subject"  Both
fields should
be filled.'

pqge 34
Minor Model Age Disclosure
Repetition of User Notes in this spec.
If this information should not be displayed to the public, then it should not be
included
here, but there could be a reference back to information kept in a separate
offline
database. Change User notes ?

page 37
Copyright Notice: Once more does this schema only allow for one copyright holder
?
This rights information is presumably tied to a particular point in time - and
perhaps this
could be clarified in the User Notes.

N.B. If I am interpreting the meaning of 'Cardinality' correctly, the schema
only allows for
one occurrence of an art work or object. How does this account for images which
portray
multiple objects ?

I hope that these comments are helpful and look forward to your response.

with best wishes

Angela Murphy
Consultant

--- In iptc-photometadata@yahoogroups.com, "Michael Steidl (IPTC)"
<mdirector@...> wrote:

> I had to get back to my files of the development work in 2004: The
issue is that the old IIM
> representation of Creator in the image header does not hold more
than one entry. So if one
> adds a second creator by a custom panel only the XMP version of the
metadata holds the
> second one, while the IIM representation does not.
>
> To summarize:
>
> - at the level of XMP one to many creators may be applied, how this
is displayed to the user
> is up to the maker of the user interface (Adobe custom panels have
them in a single field,
> separated by a comma or a semicolon, other user interfaces may have
more than one field.)
>
> - but the Adobe synchronisation engine synchronises only the first
entry in a sequence back
> to the IIM metadata - while the IIM specifications would allow for
more than one. But as
> multiple creators are not supported by the Adobe user interface for
IIM metadata only
> (Photoshop versions prior to 7.1) this is in practice irrelevant.

Perfect
It could be interesting to write this explanation in the photometadata
document because Photoshop implementation is leading (even if IPTC
would prefer to stay "implementation-neutral" I suppose...)
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

--- In iptc-photometadata@yahoogroups.com, "Michael Steidl (IPTC)"
<mdirector@...> wrote:
> > At least in Photoshop, the full sequence is displayed, not only the
> > first occurrence
>
> Regarding Adobe's Custom Panels you are right, Pattrick, but: how
multiple occurrences of a
> property are displayed by a user interface is out of the scope of
the IPTC Schemas as we
> know the Adobe Custom Panels are only *one* solution among *others*.

I understand Michael, but:
- Adobe is the creator of XMP *and* the creator of custom panels
- IPTC Core custom panels are provided by IPTC on
http://www.iptc.org/IPTC4XMP/
this gives to custom panels a kind of "privilege" over other
implementations

I do not understand very well why it could be allowed to code multiple
authors in Seq and not to be allowed to display all these authors.
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

Minor typos in page 29 (GUID):
particularely -> particularly
propably -> probably
identifer -> identifier
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

--- In iptc-photometadata@yahoogroups.com, "Michael Steidl (IPTC)"
<mdirector@...> wrote:

> - but for the display by the user interface only the first
occurrence in the sequence should be
> used - see the XMP access note: "dc:creator/*[1]

At least in Photoshop, the full sequence is displayed, not only the
first occurrence

> For that reason I'm highly inclined not to change the cardinality
specification but to add more
> language in a note to better explain this compromise.
>
> Can we compromise on that?

Yes, and explanations could point the fact that implementations do not
always follow specifications ;-)
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

--- In iptc-photometadata@yahoogroups.com, Carl Rambert <crambert@...>
wrote:
>
> Correction:
>
> Page 17, Creator, Cardinality
> 0..unbounded --> should be --> 0..1
> to match the Implementation Note(s) and the XMP access Note(s)
>
> Carl Rambert, Pound Hill Software

However, if you type "Carl; Patrick" in Photoshop's Author field, this
generates the following XMP segment:

   <dc:creator>
    <rdf:Seq>
     <rdf:li>Carl</rdf:li>
     <rdf:li>Patrick</rdf:li>
    </rdf:Seq>
   </dc:creator>

which is a true "Seq"

And in IIM, there is only "Carl"

--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

Correction:

Page 17, Creator, Cardinality
0..unbounded --> should be --> 0..1
to match the Implementation Note(s) and the XMP access Note(s)

Carl Rambert, Pound Hill Software

p. 17 Creator
"Aligning with IIM notions IPTC Core intents to have only one creator
for this news object [etc.]"
It seems that IIM By-line (#80) is repeatable, so the sentence does
not refer to IIM notions directly but refers to habitual
implementation like Photoshop.
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

> Our document is a *specification* document of IPTC metadata schemas.
We are aware that
> there are many more schemas and we acknowledge that Exif is of
essential value for
> capturing data at the time of shooting a photo - but we don't want
to make anybody think Exif
> is part of IPTC specifications now as this is not the fact. Thus we
moved talking about
> specific other metadata schemas to the addendum.

OK, I understand

> What we could make is to add a clear recommendation to use the data
from Exif/GPS fields
> for mapping in a name of the "Location the image was created"
(Location Created)

It is a good idea to refer to Exif/GPS for "Location the image was
created"

> > page 14: according to Implementation note(s) for "Date Created", IIM
> > mapping must be "2:55 Date Created + 2:60 Time Created"
> >
>
> See the Implementation note of Date Created - do you think this is
not sufficient?

It is sufficient, yes, but as far as I understand, the exact mapping
is "2:55 Date Created + 2:60 Time Created"
Just a detail...

> At the IPTC we have taken a general decision for all our standards
to use namespace URIs
> which do not correspond to a specific version, and we recommended to
use a date. The
> reason is obvious for IPTC Core 1.1: actually we would have to align
the URL, but this would
> invalidate all IPTC 1.0 implementations which would be wrong.

OK, I understand and agree

> We discussed this use case and found two solutions:
>
> - if you want to assert this photo is part of a Reportage then the
Genre field should be used -
> with the value "Feature" - this may require further discussion.
>
> - if you want to identify a specific Reportage then the JobId field
should be used: "Reportage-
> 20080428a"

This could be very useful to give this explanation in implementation
note. Because it seems actually not clear for many French agencies
which are using non standard fields in IIM to store "reportage name".
Actual sitation is very confused.
Assuming use of XMP technology and IPTC Core/IPTC Extension become
wider in the future, it will be very interesting to read IPTC
recommandation in an official paper to know what to do with "reportage
names".

Kind regards
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

Dear Patrick

thank you for your input - please see my replies below:

On 28 Apr 2008 at 10:21, Patrick Peccatte wrote:

> Dear Michael and all,
>
> My couple of observations:
>
> page 6: Exif and GPS/Exif are not explicitly mentionned in "Technical
> metadata" section; they are the most well know tech metadata and are
> widely used, it could be interesting to mention them in this paragraph
> and not only in Addendum 1.

Our document is a *specification* document of IPTC metadata schemas. We are
aware that
there are many more schemas and we acknowledge that Exif is of essential value
for
capturing data at the time of shooting a photo - but we don't want to make
anybody think Exif
is part of IPTC specifications now as this is not the fact. Thus we moved
talking about
specific other metadata schemas to the addendum.

What we could make is to add a clear recommendation to use the data from
Exif/GPS fields
for mapping in a name of the "Location the image was created" (Location Created)

> page 14: according to Implementation note(s) for "Date Created", IIM
> mapping must be "2:55 Date Created + 2:60 Time Created"
>

See the Implementation note of Date Created - do you think this is not
sufficient?

> page 26: why a date (2008-02-29) appears in URI namespace for IPTC
> Extension instead a version number ? Why not to choose a structure
> similar to IPTC Core URI namespace, i.e. something like:
> http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/

At the IPTC we have taken a general decision for all our standards to use
namespace URIs
which do not correspond to a specific version, and we recommended to use a date.
The
reason is obvious for IPTC Core 1.1: actually we would have to align the URL,
but this would
invalidate all IPTC 1.0 implementations which would be wrong.

> In French newspapers, different photos can belong to an image set
> called "Reportage". This is an editorial concept widely used and very
> different to Event (page 30), because an event can produce many
> "reportages" and one "reportage" is not always connected to an event
> (in magazine for exemple). Is there a possibility to add this notion
> in IPTC Exteions ?

We discussed this use case and found two solutions:

- if you want to assert this photo is part of a Reportage then the Genre field
should be used -
with the value "Feature" - this may require further discussion.

- if you want to identify a specific Reportage then the JobId field should be
used: "Reportage-
20080428a"

Kind regards

Michael


>
> With best regards
> --
> Patrick Peccatte
> www.pixpalace.com
> www.softexperience.com
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at  http://www.iptc.org

Dear Michael and all,

My couple of observations:

page 6: Exif and GPS/Exif are not explicitly mentionned in "Technical
metadata" section; they are the most well know tech metadata and are
widely used, it could be interesting to mention them in this paragraph
and not only in Addendum 1.

page 14: according to Implementation note(s) for "Date Created", IIM
mapping must be "2:55 Date Created + 2:60 Time Created"

page 26: why a date (2008-02-29) appears in URI namespace for IPTC
Extension instead a version number ? Why not to choose a structure
similar to IPTC Core URI namespace, i.e. something like:
http://iptc.org/std/Iptc4xmpExt/1.0/xmlns/

In French newspapers, different photos can belong to an image set
called "Reportage". This is an editorial concept widely used and very
different to Event (page 30), because an event can produce many
"reportages" and one "reportage" is not always connected to an event
(in magazine for exemple). Is there a possibility to add this notion
in IPTC Exteions ?

With best regards
--
Patrick Peccatte
www.pixpalace.com
www.softexperience.com

Carl

thank you for your valuable detailled input. See a few replies below:

On 25 Apr 2008 at 17:33, Carl Rambert wrote:

> IPTC Extension Specification Version 1.0 Document Revision 2, dated
> 2008-04-25
>
> Page 30, Digital Source File Type, Required CV is detailed as literal
> values.
> - - Does this imply that the XMP Type should be Closed Choice Text
> instead of URI?
> - - Or do you intend the Values to be encoded as URIs?

Right, IPTC's CVs are base on URIs to comply with RDF.

> Page 34, Licensor, XMP Value Type
> - - should read "Bag LicensorDetail", not "struc LicensorDetail"

Right, to be fixed.

> Page 40, Country ISO-Code, Required CV -- no entry
> - - Should this be the combination of ISO 3166-1 alpha-2 and 3166-1
> alpha-2? as described for Iptc4XMPCoreCountryCode?

Right, this addition is currently still missing.

> Page 44, References
> - - It might be useful if the "Adobe XMP" reference (September 2005)
> had a note that it severs as the authority for the photoshop
> (Photoshop) and dc (Dublin Core) XMP schema definitions. It could be
> implemented as two more rows in the table, both with duplicate Source.

Well, there is a couple more schema definitions in the Adobe document. We'll
consider this -
and not to overload the reference section.

> - - PLUS - it might be best to reference a specific version of PLUS.
> The current version is 1.2.0 Revision 2, published in 2008-01-29,
> however, it deprecated the plus:ImageSource field referenced at the
> bottom of Page 31. So, this specification must refer to one of the
> Version 1.1.0 Revisions, perhaps Revision 6 dated 2007-12-24?

We will align the final IPTC specs with the latest PLUS specs.

> Page 30, Digital Image GUID, Implementation Note(s) (continued from
> Page 29), Last sentence refers to Exif/technical metadata. Are there
> specific fields that should be documented

There is a field for a unique identifier in the Exif specs, we currently
investigate how it is
actually used before we recommend to map it into the IPTC schema.

>
> Page 31 Image Registry Id, Implementation Note(s). (I figured it out
> from the Cardinality fields) Each Image Registry Id entry must be a
> complete matching pair.

We'll clarify this.

Michael

> Carl Rambert, Pound Hill Software
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at  http://www.iptc.org

IPTC Extension Specification Version 1.0 Document Revision 2, dated
2008-04-25

Page 30, Digital Source File Type, Required CV is detailed as literal
values.
- - Does this imply that the XMP Type should be Closed Choice Text
instead of URI?
- - Or do you intend the Values to be encoded as URIs?

Page 34, Licensor, XMP Value Type
- - should read "Bag LicensorDetail", not "struc LicensorDetail"

Page 40, Country ISO-Code, Required CV -- no entry
- - Should this be the combination of ISO 3166-1 alpha-2 and 3166-1
alpha-2? as described for Iptc4XMPCoreCountryCode?

Page 44, References
- - It might be useful if the "Adobe XMP" reference (September 2005)
had a note that it severs as the authority for the photoshop
(Photoshop) and dc (Dublin Core) XMP schema definitions. It could be
implemented as two more rows in the table, both with duplicate Source.
- - PLUS - it might be best to reference a specific version of PLUS.
The current version is 1.2.0 Revision 2, published in 2008-01-29,
however, it deprecated the plus:ImageSource field referenced at the
bottom of Page 31. So, this specification must refer to one of the
Version 1.1.0 Revisions, perhaps Revision 6 dated 2007-12-24?

Page 30, Digital Image GUID, Implementation Note(s) (continued from
Page 29), Last sentence refers to Exif/technical metadata. Are there
specific fields that should be documented?

Page 31 Image Registry Id, Implementation Note(s). (I figured it out
from the Cardinality fields) Each Image Registry Id entry must be a
complete matching pair.

Carl Rambert, Pound Hill Software

Dear michael, all,

I have passed the document to my people at the alinari picture archive office
and so far no comments have been issued.

From my side I can propose to have a link to download this document to the
public from our research page http://eu.alinari.it

I can also promote it and look for feedback in malta during the mile european
project meeting.

Thanks to let me know if those 2 proposals sound ok with you.

Regards.
Andrea
Sent from my BlackBerry® wireless device

-----Original Message-----
From: "Michael Steidl (IPTC)" <mdirector@...>

Date: Fri, 25 Apr 2008 12:00:05
To:iptc-photometadata@yahoogroups.com
Subject: [SPAM]  Re: [iptc-photometadata] IPTC Photo Metadata draft 2008: review
and comment please


Richard


  great idea, yes please, add the document. We are eager to see comments from
parties beyond our "regulars".


  thank you


  Michael






  --------------------------------------------------
  On 25 Apr 2008 at 10:46  richard clark wrote:


  Michael
  Are you happy for this document to be added as a liaison document to the JPEG
committee document register for comment?
  Regards
  Richard Clark:
  <mailto:richard@...> richard@...
  Elysium Ltd, Crowborough, UK - JPEG Editor and WebMaster
  "Let standard-authors, thus, like trophies borne
  Appear more glorious as more hacked and torn" ;<{)
  Alexander Pope (1688-1744), The Dunciad


  Michael Steidl (IPTC) wrote:
  Group:


  In June 2007 the IPTC published its Photo Metadata White Paper 2007 (can still
be obtained from
  <http://www.iptc> http://www.iptc .org/goto?phmdwp2007) with a set of
recommended metadata properties. As not all of them were part of a metadata
standard the IPTC Photo Metadata Working group with members from news
photography and stock photography companies and their organisations started to
create standard specifications for these "orphan properties".


  A draft specification "IPTC Photo Metadata 2008" is publicly available for
review now and the IPTC invites you to send comments on this draft to this
iptc-photometadata Yahoo group by 15 May 2008 by the latest.


  You can download the draft document from



  <http://www.iptc> http://www.iptc .org/std-dev/PhotoMetadata/
2008/specification/IPTC-PhotoMetadata- 2008_2.pdf


  (If you have problems with a line-wrapped URL use



  <http://www.iptc> http://www.iptc .org/std-dev/PhotoMetadata/
2008/specification/


  and click on the only document in the folder.)


  The IPTC Photo Metadata 2008 are split into two formal specifications:


  - the IPTC Core schema of properties, this is a version 1.1 of the IPTC Core
which already exists since 2005. The changes of v 1.1 are minor and aim at
fixing issues which came up since the standard is in wide use.


  - the IPTC Extension schema of new properties which complements and extends the
IPTC Core properties.


  Thank you for your input


  Michael




  ======================================= ===========
  Sent by:
  Michael Steidl
  Managing Director of the IPTC <mdirector@...>
  International Press Telecommunications Council
  "Information Technology for News"
  Visit us on the web at 
  <http://www.iptc> http://www.iptc .org  
   



  ==================================================
  Sent by:
  Michael Steidl
  Managing Director of the IPTC <mdirector@...>
  International Press Telecommunications Council
  "Information Technology for News"
  Visit us on the web at  http://www.iptc.org
      	 	 	 	 	 	 	 	  The following section of this message contains a file
attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    ---- File information -----------
      File:  DEFAULT.BMP
      Date:  4 Nov 2007, 20:21
      Size:  358 bytes.
      Type:  Unknown

On 25 Apr 2008 at 10:46  richard clark wrote:

Michael
Are you happy for this document to be added as a liaison document to the JPEG committee document register for comment?
Regards
Richard Clark: richard@...
Elysium Ltd, Crowborough, UK - JPEG Editor and WebMaster
"Let standard-authors, thus, like trophies borne
Appear more glorious as more hacked and torn" ;<{)
Alexander Pope (1688-1744), The Dunciad


Michael Steidl (IPTC) wrote:

Group:

In June 2007 the IPTC published its Photo Metadata White Paper 2007 (can still be obtained from http://www.iptc .org/goto?phmdwp2007) with a set of recommended metadata properties. As not all of them were part of a metadata standard the IPTC Photo Metadata Working group with members from news photography and stock photography companies and their organisations started to create standard specifications for these "orphan properties".

A draft specification "IPTC Photo Metadata 2008" is publicly available for review now and the IPTC invites you to send comments on this draft to this iptc-photometadata Yahoo group by 15 May 2008 by the latest.

You can download the draft document from

http://www.iptc .org/std-dev/PhotoMetadata/ 2008/specification/IPTC-PhotoMetadata- 2008_2.pdf

(If you have problems with a line-wrapped URL use

http://www.iptc .org/std-dev/PhotoMetadata/ 2008/specification/

and click on the only document in the folder.)

The IPTC Photo Metadata 2008 are split into two formal specifications:

- the IPTC Core schema of properties, this is a version 1.1 of the IPTC Core which already exists since 2005. The changes of v 1.1 are minor and aim at fixing issues which came up since the standard is in wide use.

- the IPTC Extension schema of new properties which complements and extends the IPTC Core properties.

Thank you for your input

Michael

======================================= ===========

Sent by:

Michael Steidl

Managing Director of the IPTC <mdirector@...>

International Press Telecommunications Council

"Information Technology for News"

Visit us on the web at  http://www.iptc .org  

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    ---- File information -----------
      File:  DEFAULT.BMP
      Date:  4 Nov 2007, 20:21
      Size:  358 bytes.
      Type:  Unknown

Group:

In June 2007 the IPTC published its Photo Metadata White Paper 2007 (can still be obtained from http://www.iptc.org/goto?phmdwp2007) with a set of recommended metadata properties. As not all of them were part of a metadata standard the IPTC Photo Metadata Working group with members from news photography and stock photography companies and their organisations started to create standard specifications for these "orphan properties".

A draft specification "IPTC Photo Metadata 2008" is publicly available for review now and the IPTC invites you to send comments on this draft to this iptc-photometadata Yahoo group by 15 May 2008 by the latest.

You can download the draft document from

http://www.iptc.org/std-dev/PhotoMetadata/2008/specification/IPTC-PhotoMetadata- 2008_2.pdf

(If you have problems with a line-wrapped URL use

http://www.iptc.org/std-dev/PhotoMetadata/2008/specification/

and click on the only document in the folder.)

The IPTC Photo Metadata 2008 are split into two formal specifications:

- the IPTC Core schema of properties, this is a version 1.1 of the IPTC Core which already exists since 2005. The changes of v 1.1 are minor and aim at fixing issues which came up since the standard is in wide use.

- the IPTC Extension schema of new properties which complements and extends the IPTC Core properties.

Thank you for your input

Michael

==================================================

Sent by:

Michael Steidl

Managing Director of the IPTC <mdirector@iptc.org>

International Press Telecommunications Council

"Information Technology for News"

Visit us on the web at  http://www.iptc.org

 

At 10:55 AM 2/12/2008, eddyhasby wrote:
>We have website galleries photo journalist in www.kompasimages.com
>Indonesian version.
>maybe... any idea for me, about information photo metadata.

Eddy:

Can you be a bit more specific?  Are you looking for information on
Photo Metadata? If so, try starting here:

http://www.iptc.org/photometadata/
http://www.phmdc.org/
http://www.controlledvocabulary.com/imagedatabases/iptc_naa.html

If you are wanting something else, try asking another question.

David

David Riecks  (that's "i" before "e", but the "e" is silent)
Need Keywords for your database? Get the Controlled Vocabulary Solution
http://controlledvocabulary.com/products/ support for a dozen of the
most popular imaging applications from Adobe Bridge to Photo Mechanic.

I'm forwarding this from Michael Beasley, as it has some import into
how the IPTC Core is used (or misused in this case).

FYI, Picade is a new photographer portal that is using the
PhotoShelter technology for archiving and licensing their image collection.

I especially find this disturbing because the IPTC Core documentation
specifically mentions that the field may be used to store either the
2 letter or 3 letter version of the ISO codes. If they are only
recognizing the three letter variation, that is a failure of their
back end or user interface.

As a side issue, if I recall specifically, this was left open to
either standard because the official list of the three letter codes
requires developers to either purchase a copy of this ISO standard,
and/or book in order to be able to use these codes. The two letter
codes are also in use as part of the standard Internet domain country
codes, and thus more freely available. If they are only using the
three letter codes, and don't have the appropriate ISO permission,
they could be in trouble from that front as well.

Does anyone recall the specifics of this from prior discussions?

David


>Dear David,
>a major metadata handling error discovered on and reported this
>morning to PhotoShelter.
>
>You have my explicit permission to copy and forward this message.
>
>Cordially,
>Michael Beasley
>
>-----Original Message-----
>Sent: Monday, February 11, 2008 12:37 PM
>To: _PicadeOwners Maillist
>Subject: [Picadeowners] Improper PhotoShelter handling of 2
>character ISOCountry Codes in image metadata
>
>Dear Picadians,
>fellow Picadian Nick Servian has brought to my attention a
>significant bug in the handling of two (2) character ISO Country
>Codes in embedded image metadata on the PhotoShelter  site.
>
>Specifically, their code seems setup to only properly handle THREE
>(3) character ISO Country Codes, which means that in Nick's case
>they improperly were showing an image properly marked as coming from
>Australia as one coming from Saudia Arabia!!!
>
>I have entered a major bug report to PhotoShelter with "chapter and
>verse" from the appropriate standards to try and get them to fix the
>situation, but you need to be aware that there exists a significant
>error in their handling of Country Codes if you are not using the
>three character variant.
>
>My bug report to PhotoShelter follows (edited slightly because of
>huge query strings in specified URLS). I will let you know when they
>tell me they have fixed this behaviour to properly handle wither two
>or three character ISO Country Codes. You do not have to do anything
>regarding images previously uploaded, but try and use the three
>character codes for the future.
>
>Cordially,
>Michael Beasley
>
>===================== SLIGHTLY EDITED BUG REPORT ===========================
>
>One of  our PhotoShelter  MU account photographers Nick Servian has
>alerted me that one of his Australian images:
>
>"1033E00000000PERTH-WA.jpg" (http://tinyurl.com/39jdon)
>
>is showing up as in Saudia Arabia. For example in MU account editor
>image edit mode:
>City: Perth
>State/Province: W. Australia
>Country: Saudi Arabia
>Country ISO: Saudi Arabia
>
>or publicly in  image  preview:
>Location: Perth W. Australia Saudi Arabia
>
>A local copy of the image in question shows the ISO 3166 2 character
>country code of "AU" properly embedded in the image downloaded with
>unmodified metadata from our PhotoShelter MU account.
>
>The two character ISO code for Australia is "AU", the two character
>ISO code for Saudia Arabia is "SA".
>
>The three (3) character code for Australia is "AUS", and for Saudia
>Arabia is "SAU".
>
>The IPTC standard specifies (IIMV4.pdf - "IPTC - NAA INFORMATION
>INTERCHANGE MODEL Version No. 4 October 1997", page 40 ):
>
>"2:100 Country/Primary Location Code
>Not repeatable, three octets consisting of alphabetic characters.
>Indicates the code of the country/primary location where the
>intellectual property of the objectdata was created, e.g. a photo
>was taken, an event occurred. Where ISO has established an
>appropriate country code under ISO 3166, that code will be used.
>When ISO3166 does not adequately provide for identification of a
>location or a new country, e.g. ships at sea, space, IPTC will
>assign an appropriate three-character code under the provisions of
>ISO3166 to avoid conflicts."
>
>NOTE THAT THE IPTC STANDARD GENERALLY ALLOWS THE USAGE OF EITHER 2
>CHARACTER OR 3 CHARCTER ISO 3166 CODES EXCEPT WHERE A SPECIFIC 3
>CHARACTER CODE HAS BEEN ASSIGNED BY IPTC FOR "When ISO3166 does not
>adequately provide for identification of a location or a new country...".
>
>The "THREE OCTETS" specification is the total space ALLOCATED, not
>the required length.
>
>Additional documentation: ( "IPTC Core" Schema for XMP Version 1.0",
>http://www.iptc.org/std/Iptc4xmpCore/1.0/specification/Iptc4xmpCore_1.0-spec-XM\
PSchema_8.pdf
>, page 8):
>
>CountryCode
>ISO Country Code
>Property name:
>User interface label:
>Description: Code of the country the content is focussing on --
>either the country shown in visual media or referenced in text or
>audio media. This element is at the top/first level of a top-down
>geographical hierarchy. The code should be taken from ISO 3166 two
>or three letter code.
>
>The full name of a country should go to the "Country" element.
>
>Note(s): Note 1: an implementer would have to derive from the length
>of the value string whether this is the country code from the two or
>three letter scheme as no explicit indication can be provided.

--
David Riecks (that's "i" before "e", but the "e" is silent)
david@...  http://www.riecks.com/
Midwest/Chicago ASMP

At 05:20 AM 2/5/2008, tesala79 wrote:
>How can I distinguish between IPTC EnvelopeRecortTag, IPTC
>AplicationecorTags and IPTC news photo tag? How can I distinguish
>between 005destiantion or 005objectname or 020flieformat or
>020suplementalcategories???

Tesala:

I'm not aware of many applications that use the first two tags you
mention. However, the most important thing to realize is that there
are significant differences between the actual IIM schema, and what
most applications using legacy IPTC support, AND this is
significantly different from what is supported in IPTC Core (XMP).

If you are trying to discern if an application such as Coppermine is
using IPTC (legacy) or IPTC Core, you can use Jeffrey Friedl's online
Exif metadata viewer (http://regex.info/exif.cgi?) to check the
actual files online (Mr. Friedl has leveraged Phil Harvey's ExifTools
into an online app). To the best of my knowledge (and unless things
have changed recently), Coppermine only reads legacy IPTC.

If you are at all concerned about "interoperability" and backwards
compatibility, I would encourage you to take a look at the IPTC Core
Mapped Fields PDF at
http://www.controlledvocabulary.com/imagedatabases/iptc_naa.html for
a look at some of the more popular applications and which fields they support.

Hope that helps.

David




--
David Riecks (that's "i" before "e", but the "e" is silent)
david@...  http://www.riecks.com/
Midwest/Chicago ASMP