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: "I. David Brown" <idbrown@mcmail.CIS.McMaster.CA>
  • Date: Tue, 17 Mar 1998 19:46:45 GMT
	Having now spent a little time reviewing John Westbrook's
suggestions and Syd Hall's reply, and having come across a similar problem
in the imgcif discussion, where they are trying to define a generic array
that could have any kind of dimensions and any kind of unit, it is
becoming clear that physical dimensionality (e.g. distance, time), as
opposed to mathematical dimensionality (e.g. 2-D, 3-D) is a problem that
we have to deal with.  (What a horror our language can be!  Not only does
the word 'units' imply both 'units' and 'physical dimensions', but
'dimensions has two different meanings, both of which have application in
crystallography.  How can we distinguish these? phys-dimension and
math-dimension?  Any suggestions?). 

	The solutions that have been proposed have been:

1. Define a new data name for each different phys-dimension (and possibly
each different unit.  Even though we have scotched the unit definition
here, it is likely to come up in the imgCIF dictionary). 

2. Define a new attribute: _unit_construct (more properly it should be
_dimension_construct)

3. Define a way of generating the date name to reflect the
phys-dimensionality of the item using _dataname_construct.

	While Syd veers towards the conservative approach of 2, even he
seems to have caught the wind in his sails in pointing out that 3 may be
the route of the future (though he quickly caught himself in the act of
flying and brought himself back to earth).  What is clear is that some of
our data items are acquiring attributes that need to be defined in each
cif, rather than in the dictionary, since we are all agreed that defining
new data names to cover all eventualities is not the way to go.  On the
other hand, having a flexible way of defining data names (as in
_dataname_construct) surely puts a heavy load on the software trying to
check a cif against its dictionary.

	I would like to suggest a different way.  In the beginning we
treated the data name as an unparsable string that was exactly matched by
an entry in the dictionary.  However, in DDL2 we have introduced parsable
data names, since a '.' now terminates that part of the data name that
contains the name of the category.  Thus the dataname can be read as
either a single unique identifier, or it can be used to determine the
category, so that we can now list only those data items in a cif that
belong to a particular category without reference to the dictionary. 

	Would it not be possible to add a suffix in the same sense, for
example, _refine_diff_density_max@neutron.  In this case the dictionary
would only compare the string up as far as '@', but the suffix (which
could be restricted to a list enumerated in the definition of
_refine_diff_density_max) would define in an elegant way the
phys-dimensionality of the item, and by implication, its units.  There
might be other attributes that we could, in the future, add as suffixes to
the data name using different separators.  One advantage of this scheme is
that all existing files would be compatible, there being a default value
if no suffix were present.  Although this looks like the units suffix that
we discarded early in out discussions, the use of the @ separator
makes this approach quite different.

	This proposal would avoid the need to search for other data items
in the cif in order to determine the phys-dimensionality of the item,
though it would still require additional DDL terms to be defined in order
to supply the enumeration list and default.  It would also require a
change in the DDL syntax which might be more of an objection.  On the
other hand it would greatly extend our ability to handle variable
attributes without tying ourselves into knots and would point to ways in
which existing definitions might be extended in the future.

			David



*****************************************************
Dr.I.David Brown,  Professor Emeritus
Brockhouse Institute for Materials Research, 
McMaster University, Hamilton, Ontario, Canada
Tel: 1-(905)-525-9140 ext 24710
Fax: 1-(905)-521-2773
idbrown@mcmaster.ca
*****************************************************

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