Discussion List Archives

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

Re: Permitting new physical units?

  • To: Multiple recipients of list <coredmg@iucr.org>
  • Subject: Re: Permitting new physical units?
  • From: syd@crystal.uwa.edu.au (Sydney R Hall)
  • Date: Mon, 2 Mar 1998 14:48:18 GMT
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.

[Send comment to list secretary]
[Reply to list (subscribers only)]