[Cif2-encoding] Addressing Simon's concerns

[James Hester]

Some comments on Simon's concerns as raised last week:

Simon wrote:

I have been developing a new docx template which the IUCr editorial office
is shortly to release for use by
authors. The template will be packaged with some tools to extract data from
CIFs
and tabulate them in the Word document, e.g. open an mmCIF, click a button,
and standard
tables populated with data from the CIF will be included in the document,
acting as
table templates for the author to edit as appropriate for their manuscript.

Inclusion of the mmCIF tools is part of an unofficial policy to 'coax'
biologists to start using/accepting mmCIF
as a useful medium, rather than as a product of their deposition to the PDB,
and to encourage them to become comfortable
with passing mmCIFs between applications, and even to edit the things (in
the same way as the core-CIF community
treats CIFs). For example, our perception is that there is no reason why an
author should not feel free to take an mmCIF
that has been created by e.g. pdb_extract and populate it using third-party
software before uploading to the PDB for
deposition.

This cause would not be furthered by effectively invalidating an mmCIF if it
were not to be encoded in one of
the specified encodings.

This cause would also not be furthered if the PDB or other colleagues are
unable to figure out what the symbols in the text were without hassling the
provider of the CIF (think of a phone conversion "OK, try this, now send it
again....no, what about trying this format and send it again...that works,
except that the Greek characters don't come out....")  I think a rough
equivalent of what you are saying is "We would alienate biologists if they
are unable to submit manuscripts in their native language".  However,
scientists are used to making some extra effort in order to achieve
international communication.  Furthermore, are there any macromolecular data
exchange formats that allow characters from the Unicode range to be
interchanged reliably?  Isn't there a carrot as well as a (small) stick
here?

So although I am uneasy about a specification that propogates uncertainty,
I'm also uneasy about alienating users,
especially when we are struggling to change their mindset as in the case of
the biological community
(my perception of the biological community's attitude to mmCIF is based on
feedback from authors/coeditors to
IUCr journals).

Granted this may not be the most compelling argument in favour of 'any
encoding', but recognizing the hurdles that
may have to be overcome once we move beyond ASCII whatever the CIF2
specification, I support 'any encoding'
as 'a means to an end'.

Just to make sure that I understand, you are concerned that third party
software may take a UTF8 mmCIF template provided by the IUCr and populate it
with further information, and at some stage transcode to a different
encoding.  By mandating UTF8, we are therefore forcing biologists to jump
through more hoops than they would otherwise have to.  I don't see how that
last sentence follows: surely those writing third party software are the
ones that will be dealing with encoding issues, and as long as we say right
now, at the beginning, that the encoding is UTF8/16, the software will be
written as intended and biologists will be oblivous to the encoding.

all the best,
James.


-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://scripts.iucr.org/pipermail/cif2-encoding/attachments/20100929/54b18a8d/attachment.html