Hi Howard. > I agree. We do not want _xd_ _nd_ _ed_ as in Syd's multiple definition > example. Good. > would be better as: > > ; The largest, smallest and root-mean-square-deviation values of the > difference density. The *_rms value I don't have a problem with this. > Now in >> data_refine_diff_density_ >> _units_construct (_diffrn_radiation_scat_units)_A^-3^ > > what happens to the person who does not use the A? The answer seems >obvious, I admit, but taken with > >> _example (_cell_length_unit)^3^ > > seems to mean that you are likely to find yourself having to define an >_unit item for very many data items in the whole dictionary (i.e. one >for cell length, one for bond length, one for wavelength etc). I sort of anticipated that this question when I put in the _unit_construct example. I believe that the answer is obvious... one only invokes the _units_construct approach when there are alternate units, such as in scattering. Otherwise one uses the standard _units attribute. I will expunge the _cell_length_unit example for that reason.... unless of course there is a SI move afoot to keep the picometre debate alive! By the way the multiple data name construction would work perfectly well... but why make the units definition more complicated than it needs to be. > How does >this construct take account of the powers of 10? e.g. mm and m are fine >for measuring physical lengths around the home or lab but cubed are >hopeless for volumetric measurements. Huh? don't really understand this question. > Do I understand correctly that in this approach the units are an >attribute of the data name rather than an attribute of its instance as a >numerical value? I think that the answer is NO. The "units" of scattering are specified in this instance as a data value (which has a number of data attributes... one of which is that it is a string). This particular data value may also used in the construction of the units attribute of another data value, but that may not be its only purpose. Similar applications exist for _type_construct. The typical application for this attribute is for definition of _date. This can be constructed from _day, _month and _year. But each of these items are quite independent of _date. And indeed value of _date may be provided quite independently of _day, _month and _year! However, if _date is missing from a file and a search engine requires it, this value may be constructed from _day, _month and _year using the dictionary _type_construct definition .. provided the components are present, of course. This takes us to the heart of the argument for richer dictionary languages and more powerful "methods" attributes. With a comprehensive language a file need only contain the truly "primitive"/"measured" data... all other derived data is available via the dictionary which now represents a methodology knowledge base... which may ultimately replace software as we know it. Future data access (search) tools will use the dictionary to automatically derive data items which are not directly accessible. These may range from bond lengths to difference maps to molecular plots ... and much more. Whoops... taking a bit long with this one... but its worth pointing out that these objectives are not really as difficult to achieve as they might seem. We are working on some interesting ideas about how to develop future generations of dictionaries which can invoke a object oriented toolbox somewhat like Mathematica has. And just in case someone gets concerned that the evolution of the DDL will affect the CIF archives or existing data names... be assured it won't. It may mean however that data files of the future will be smaller... and that would be nice. Cheers, Syd.
Copyright © International Union of CrystallographyIUCr Webmaster