Dear Herbert,
I suggested earlier that we could easily add the style tag you
suggest. In some cases where an earlier dataname has already been
superceded by a second dataname it would be necessary to indicate which
is the proper (i.e., later) name that should be used on writing since
all datanames that have ever been approved must appear in the alias
list. With the style tag the _alias_uri would not be as important and
could be omitted.
There are a number of reasons why your import scheme would have made
life considerably more complicated. The first is that the old tags do
not conform to CIF2 syntax and therefore would have to be insulated
within the routines that manipulates the data under DDLm CIF-dictionary
control. The second is that DDLm has a much tighter heirarchical
category structure that is desinged to simplify the merging and
updating of the dictionaries. This was introduced to overcome some of
the weaknesses of the earlier file structures. Allowing the DDL1 and
DDL2 datanames to be defined in save frames within the DDLm dictionary
would lead to incompatibilities that would prevent many of the newly
introduced features in DDLm being used. For
example in DDLm the category and object parts of the datanames are
defined independently and represent the two components out of which the
dataname is constructed at run time. The dataname in the save_
statement is, by convention, a composite of these two components, but
it is not the definition of the name. Since it is not
possible with the older datanames to separate them into a
catagory and object component without in some cases misnaming the
category, their presence would effectively mean that the tighter
features of DDLm could not be used either in programming or in updating
and merging. One should not try to put new wine into old wine skins.
Anyway it sounds as if we have agreement on at least something. and
knowing that DDLm can achieve compatibility with the earlier archive by
using the aliases on reading and writing, and proper DDLm names
otherwise, should simplify the discussions on syntax.
Herbert J. Bernstein wrote:
Dear David,
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.
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.
Thank you again. That was really very helpful.
Regards,
Herbert
=====================================================
Herbert J. Bernstein, Professor of Computer Science
Dowling College, Kramer Science Center, KSC 121
Idle Hour Blvd, Oakdale, NY, 11769
+1-631-244-3035
yaya@dowling.edu
=====================================================
On Wed, 19 Jan 2011, David Brown wrote:
Herbert,
I have copied below the DDLm entry for the item you suggest. Notice
that
it has a different name in the DDLm CIF-dictionary. The input file
includes all the information needed to calculate this item but
_diffrn_standards.decay_% is not present in the input and we require to
add
it. The values we need in the input file are read in and associated
with
the new DDLm datanames (is this what you call a tag?). The user must
make
some decision what information he requires and must emter this into the
program in the form of a dataname. There are many ways this could be
done,
but this is a programming decision, not a dictionary one. The
information
mau be supplied as '_diffrn_standards.decay_percent' or
'_diffrn_standards.decay_%'. Either way the instruction is converted
(via
the alias) to '_diffrn_standards.decay_percent' which is the name that
would be used in the method. Note that changing a dataname does not
require any change in the value of the item. After execution of the
method
this item would be populated. The user must also decide what output is
needed, say mmCIF (i.e. a CIF2 datafile). The program locates the
correct
output name '_diffrn_standards.decay_%' in the alias list and writes
the
mmCIF file using this name. Note that the name
'_diffrn_standards.decay_%'
does not correspond to the CIF2 syntax, but the input and output parts
of
the program recongnize when it is working with CIF1 syntax.
The reason this is cleaner is that only one method is needed since all
manipulations between reading the input and writing the output are
carried
out using the DDLm CIF-dictionary including the DDLm CIF-dictionary
tags.
If we need different methods for different standards we would end up
with
three different dictionaries and we would loose the abitlity e..g., to
read
in a CIF1 data file and write out a CIF2 datafile. Writing, and more
to
the point maintaining, the kind of dictionary you envision would be a
nightmare.
Best wishes
David
------------------------------------------
save_diffrn_standards.decay_percent
_definition.id '_diffrn_standards.decay_percent'
_definition.update 2008-06-09
_description.text
; The percentage decrease in the mean
intensity of the set of standard reflections measured at
the
start of the measurement process and at the finish.
This
value
usually affords a measure of the overall decay in
crystal
quality during the diffraction measurement process.
Negative
values are used in exceptional instances where the final
intensities are greater than the initial ones. If no
measurable decay has occurred, the standard uncertainty
should
be quoted to indicate the maximum possible value the
decay
might have. A range of 3 standard uncertainties is
considered
possible. Thus 0.0(1) would indicate a decay of less
than
0.3% or an enhancement of less than 0.3%.
;
_description.common 'DiffrnStandDecay%'
_name.category_id diffrn_standards
_name.object_id decay_percent
_type.purpose Measured
_type.container Single
_type.contents Real
_enumeration.range :100
loop_
_description_example.case
_description_example.detail
'0.5(1)'
; represents a decay between 0.2% and 0.8%
;
'-1(1)'
; the change in the standards lies between a decay
of
2% and an increase of 4%'
;
'0.0(2)'
; the change in the standards lies between a
decay of 0.6% and an increase of 0.6%.
;
loop_
_alias.definition_id
_alias.dictionary_uri
'_diffrn_standards_decay_%' cifdic.c91
'_diffrn_standards.decay_%' cif_mm_1.0.dic
save_
Herbert J. Bernstein wrote:
Let's take a concrete example: Suppose we want to use a DDLm method to
populate _diffn_standards.decay_% in an mmCIF dictionary from the
actual measured reflections (or, more elegantly as a long-term goal
directly from the data in a scan of image frames).
That tag cannot be used directly in a dREL method. Under David and
John's proposed use of the alias mechanism, what aliases would have
appear where and to what should be method itself refer, and in what
save frame would it be defined. Ideally, we would like to be able to
have this all gathered into one dictionary, and the dictionary merge
mechanism allows us to do that, so whatever we propose should not
depend on the name or type of the dictionary.
I can see how the alias mechanism can be used to validate the value. I
don't yet see how it can be used to generate the value using the
illegal tag. If I understand the DDLm docuemnt correctly, to generate a
value for a tag, the method has to be in the same frame defining that
tag, but we seem to have barred this tag from being the name of a save
frame in a CIF2-style DDLm dictionary. If we were to go back to
allowing all the valid CIF1 tags as tags in DDLm dictionaries, then
this particular problem would go away with a little jiggering either of
the alias mechsnism or by adding the import ... as ... to the methods.
I think the import is cleaner, but I msay be wrong and look forward to
seeing the alias solution. I am not sure I see any simple solution if
we don't relax the tag restriction back to CIF1 rules, but again, I may
be wrong.
Regards,
Herbert
=====================================================
Herbert J. Bernstein, Professor of Computer Science
Dowling College, Kramer Science Center, KSC 121
Idle Hour Blvd, Oakdale, NY, 11769
+1-631-244-3035
yaya@dowling.edu
=====================================================
On Wed, 19 Jan 2011, Bollinger, John C wrote:
On Wednesday, January 19, 2011 7:37 AM, Herbert J. Bernstein wrote:
If the CIF1 interoperability with DDLm is an absolute given, we should
be a
ble to work things out. That may or may not require changes in CIF2,
but I
am fairly sure it will require some new hooks in dREL and DDLm to be
able to work fully with CIF1 tags. Perhaps I've missed those hooks.
I trust those here having more practical experience with DDLm and dREL
to c
orrect me where I am wrong, but as far as I can tell, DDLm's alias
system p
rovides all the needed hooks. Here are some implied details that might
cla
rify matters:
1) Each dREL method appearing in a DDLm data dictionary refers to CIF
items
exclusively in terms of those items' data names (not aliases), as
defined in the dictionary in which the referenced items and the
method's item all a
ppear.
2) Where necessary, DDLm aliases bind the data names actually used in
input
data CIFs to the corresponding names defined in the dictionary. This
alia
sing is transparent to dREL methods and to data validation procedures.
3) When needed, a DDLm-based system can automatically select an output
data
name for an item, based on the name of the dictionary in which the
user ex
pects the output name to be defined. If the chosen dictionary is not
the D
DLm dictionary itself then the given dictionary name is used to select
the appropriate alias from among those defined for the item in
question. This activity also is transparent to dREL, if not outside
dREL's scope altogethe
r.
All of that depends heavily on the content of the dictionary, but it
appear
s fully supported by DDLm and dREL as presently defined. None of those
oper
ations inherently depend on details of CIF syntax.
It is possible that part of the problem here is a disagreement over the
mea
ning of "CIF1 interoperability". The above description explains CIF1
inter
operability over the full breadth of DDLm / dREL design goals as I
perceive
them, but Herbert has expressed an interest in embedding script in
data fi
les, and perhaps his concerns arise from that direction. As far as I
can t
ell, that would be outside dREL's design parameters, but dREL could
conceiv
ably still be applied in such a context. Details and any semantic
differen
ces would need to be defined in the appropriate data dictionary,
however, n
ot in that dictionary's DDL (whether DDLm, DDL2, or DDL1). As
stimulating as a discussion of that topic might be, I think at the
moment it would go r
ather too far afield.
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
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group
|
