Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .


On Wednesday, January 19, 2011 12:04 PM, Herbert J. Bernstein wrote:
>   That was very helpful.  You want to maintain one dictionary that will dynamically act as a DDL1, DDL2 or DDLm dictionary. Fair enough.  But then shouldn'e the information on what alias is intended for what style of output simply be in the alias tags.  It is not really a matter of which dictionary it come from, but of which of several alternate styles of tags it conforms to.
>
>   Right now the alias category has 2 tags,
>
>   _alias.definition_id
>   _alias.dictionary_uri
>
>We could both do what we need to do without conflicting if there were a third tag
>
>   _alias.tag_style
>
>which would simply be a character string, such as DDL1, DDL2, DDLm, my_new_style, ... which could be used to tie together the style of tags to be used for a particular dictionary use, both for validation of input and for generation of output.  If no particular style had been specified, the save frame name would win.  This would bring the data on which are DDL1 names and which are DDL2 names for the core values neatly together on one core dictionary without having to know if any other dictionaries were DDL1 style and which are DDL2 style.  The DDLm dictionary would have all the information right there and would not even need to refer to the older dictionaries on most cases to work with DDL1 and DDL2 data files.

_alias.tag_style seems redundant to me.  For one thing, _alias.definition_id will inherently exhibit the tag style.  Moreover, the "tag style" in the DDL-version sense is both well known and electronically available, given _alias.dictionary_uri, at least for official and registered dictionaries.  A program that cared generically about tag type could use either or both of those to determine it dynamically while processing the dictionary.  Moreover, there is in general no particular reason to expect not to find multiple aliases of the same tag type, whether defined in the same or in different dictionaries.

If you want to select, for instance, Core data names vs. mmCIF data names then then _alias.dictionary_uri gives you that directly.  It works even among multiple alternative names for the same concept defined in different dictionaries using the same data name convention.  Moderately clever software could even make selection by dictionary URI work for merged dictionaries, provided it was given information about the constituent dictionaries.

There does, however, appear to be a possible need for a tag by which to nominate a preferred alias among several defined in the same external dictionary.  The preference doesn't matter when reading CIF input, but it does potentially matter when choosing a tag for output.  We could rely on order of appearance in the alias list, but until now loop packets have been order-independent.

>   For my work, this would be just as effective as the import ... as ... or my method_alias suggestion in allowing me to use CIF1 tags that are >illegal under CIF2 without requiring us to allow those names as valid tags in DDLm dictionaries.
>
>   Could you accept _alias.tag_style, and perhaps allowing _alias.dictionary_uri to be omitted when not really needed?  This would be a big help >to me in then making a DDLm imgCIF dictionary that could not only replace the DDL2 dictionary, but could also, for the first time provide a DDL1 >version of all imgCIF tags.  I could even then automatically produce valid DDL1 and DDL2 dictionaries from the DDLm dictionary source, making thr >DDLm dictionary the only version that I would have to maintain.

For this particular purpose, how about defining a URI to represent the hypothetical DDL1 imgCIF dictionary, and using that with _alias.dictionary_uri to achieve your objective?  The resulting dictionary would even be more informative about the nature of the aliases than a tag style could make it.  That approach would be no harder to code for, as it simply substitutes one data name and set of constants for another.


Regards,

John

--
John C. Bollinger, Ph.D.
Department of Structural Biology
St. Jude Children's Research Hospital


Email Disclaimer:  www.stjude.org/emaildisclaimer

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links