[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Simon wrote:
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?
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
Reply to: [list | sender only]
[Cif2-encoding] Addressing Simon's concerns
- To: Group for discussing encoding and content validation schemes for CIF2 <cif2-encoding@xxxxxxxx>
- Subject: [Cif2-encoding] Addressing Simon's concerns
- From: James Hester <jamesrhester@xxxxxxxxx>
- Date: Wed, 29 Sep 2010 12:16:07 +1000
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.
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'.
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
_______________________________________________ cif2-encoding mailing list cif2-encoding@iucr.org http://scripts.iucr.org/mailman/listinfo/cif2-encoding
Reply to: [list | sender only]
- Follow-Ups:
- Re: [Cif2-encoding] Addressing Simon's concerns (SIMON WESTRIP)
- Prev by Date: Re: [Cif2-encoding] How we wrap this up
- Next by Date: Re: [Cif2-encoding] How we wrap this up
- Prev by thread: Re: [Cif2-encoding] A new(?) compromise position
- Next by thread: Re: [Cif2-encoding] Addressing Simon's concerns
- Index(es):