Discussion List Archives

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

Re: [ddlm-group] CIF-2 changes

Following is a short analysis of the dREL/brackets situation.

Problem: If datanames contain characters that are syntactically
meaningful in dREL, it will impossible to refer to those datanames in
dREL methods.  For example, in order to build up a nice matrix out of
the individual _atom_site.aniso_U[i][j] items now present in mmCIF, a
dREL method would have to refer to them, e.g.

_atom_site.aniso_U = [[_atom_site.aniso_U[1][1],...]

but the [1] will be wrongly interpreted as an array reference.

======================
Options for a solution:

Option 1: Ban all dREL syntactically meaningful characters from CIF2
datanames, handle CIF1 square brackets in custom conversion software
if DDLm is needed

Option 2: Add a built-in dREL function to 'quote' the contents.  If
this function is called 'dataname', then the above line becomes:

_atom_site.aniso_U = [dataname("_atom_site.aniso_U[1][1]"),...]

This function need only be used where the syntax does not permit
straighforward use of the name.

Option 3: Allow brackets in datanames, but create an additional
dataname in the relevant dictionary which is an exact alias to the
problem dataname for use in dREL methods.  So in the above example, we
might add a dataname to the dictionary called '_atom_site.aniso_U_11',
and state that it is an alias for _atom_site.aniso_U[1][1].  dREL code
would follow the alias to get the value for aniso_U[1][1]

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

I view option 2 as the elegant solution.  It is analogous to the
Python 'getattr' function.  That is, in Python the syntax xxx.yyy
refers to the yyy attribute of object xxx, but if the string 'yyy'
contains characters that are meaningful to Python (like square
brackets) you can't use the xxx.yyy syntax directly.  Instead, you can
call the built-in 'getattr' function like so: getattr(xxx,"yyy").

Regardless of what we decide in the concrete case of brackets, such a
function should in any case be included in dREL to make it more robust for
integration into other contexts.

Regarding the other options, Option 1 assumes a coupling between DDLm
and dREL, rather than viewing them (at least in a formal sense) as
independent systems.  Option 3 uses the DDLm system to work around
what I would call a deficiency in dREL, and produces extra dataitems
in order to do this.  Given that it is not too late to improve dREL, I
would prefer to fix it rather than mess with the CIF2 syntax or DDL
dictionaries

-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
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