Closed rowlesmr closed 1 year ago
Could something like this work?
_pd_phase_block.short_id
- PD_PHASE_BLOCK
is described as "A table of phases relevant to the current data block.". It is a Loop
category. Its value would be a code._pd_phase_block.short_id
with _pd_phase_block.phase_id
to create a reference between a short id and a full id_pd_refln.phase_id
to link with _pd_phase_block.short_id
. (maybe even rename to _pd_refln.short_id
, although that might be a little too far)#/#CIF_2.0
data_xye_files\576460-mac-001_reb_0003.xye_0
_pd_diffractogram.id xye_files\576460-mac-001_reb_0003.xye_0
loop_
_pd_phase_block.short_id
_pd_phase_block.phase_id
_pd_phase_mass.percent
1 ALUMINA_A_BIG_LONG_STRING_THAT_IS_GLOBALLY_UNIQUE 72.11
2 SILICON_ANOTHER_STRING_THAT_IS_SUPPOSED_TO_BE_ALONE 27.89
loop_
_refln.index_h
_refln.index_k
_refln.index_l
_pd_refln.phase_id
_refln.d_spacing
0 0 12 1 1.082702
1 0 -14 1 0.905365
2 2 0 2 1.920168
3 1 1 2 1.637525
#...
loop_
_pd_meas.2theta_scan
_pd_proc.intensity_total
_pd_calc.intensity_total
_pd_proc.intensity_bkg_calc
5.001 43.364 25.994 25.991
5.004 38.007 26.200 26.200
5.007 38.318 26.404 26.403
#...
A bit more of a radical idea: revert PD_PHASE_BLOCK
and PD_BLOCK_DIFFRACTOGRAM
to just deal with block id values; nothing at all to do with the new phase and diffractogram_id. Create PD_PHASE_LIST
and PD_DIFFRACTOGRAM_LIST
to deal with cases when we need to loop phase and diffractogram ids.
Both would be Loop
categories. Both would have two data items.
PD_PHASE_LIST
. Loop
keyed on _pd_phase_list.id
_pd_phase_list.id
. Acts as the Key
for the category. Is an arbitrary code identifying a _pd_phase.id
*._pd_phase_list.phase_id
. Acts as Link
back to _pd_phase.id
(which should be unique in the entire world). PD_DIFFRACTOGRAM_LIST
. Loop
keyed on _pd_diffractogram_list.id
_pd_diffractogram_list.id
. Acts as the Key
for the category. Is an arbitrary code identifying a _pd_diffractogram.id
*._pd_diffractogram_list.diffractogram_id
. Acts as Link
back to _pd_diffractogram.id
(which should be unique in the entire world).In this world, the new data item _pd_refln.phase_list_id
would be linked to _pd_phase_list.id
, and _pd_refln.phase_list_id
would be aliased with _pd_refln_phase_id
, and become a category key for REFLN
, instead of _pd_refln.phase_id
(which gets deprecated).
Furthermore, categories that have _categoryname.phase_id
and/or _categoryname.diffractogram_id
will also get _categoryname.phase_list_id
and/or _categoryname.diffractogram_list_id
to be able to take advantage of this.
#/#CIF_2.0
data_xye_files\576460-mac-001_reb_0003.xye_0
_pd_diffractogram.id xye_files\576460-mac-001_reb_0003.xye_0
loop_
_pd_phase_list.id
_pd_phase_list.phase_id
1 ALUMINA_A_BIG_LONG_STRING_THAT_IS_GLOBALLY_UNIQUE
2 SILICON_ANOTHER_STRING_THAT_IS_SUPPOSED_TO_BE_ALONE
loop_
_pd_phase_mass.phase_list_id
_pd_phase_mass.percent
1 72.11
2 27.89
loop_
_refln.index_h
_refln.index_k
_refln.index_l
_pd_refln.phase_list_id
_refln.d_spacing
0 0 12 1 1.082702
1 0 -14 1 0.905365
2 2 0 2 1.920168
3 1 1 2 1.637525
#...
loop_
_pd_meas.2theta_scan
_pd_proc.intensity_total
_pd_calc.intensity_total
_pd_proc.intensity_bkg_calc
5.001 43.364 25.994 25.991
5.004 38.007 26.200 26.200
5.007 38.318 26.404 26.403
#...
* Do these arbitrary codes need to be unique within the entire container, or just in the block?
This has wandered a bit off course. I'll try again.
OK, interesting ideas. Note in your initial example that if each data block contains only a single phase, then the long complicated phase id is only provided once in the file, and all other values are then obtained from that value, so I don't see long complicated names as being an issue. I think we can simply instruct the pdCIF creator to ensure that all phase_id values will be unique within the data set.
if each data block contains only a single phase, then the long complicated phase id is only provided once in the file, and all other values are then obtained from that value
? I don't understand how this works? How can you refer to other things without their (long) key?
data_phase1
_pd_phase.id PHASE_ONE_ID
# phase 1 information goes here
data_phase2
_pd_phase.id PHASE_TWO_ID
# phase 2 information goes here
data_diffpat1
_pd_diffractogram.id DIFFPATT_WITH_PHASE_1
loop_
_pd_phase_mass.phase_id # what else goes here but a _pd_phase.id?
_pd_phase_mass.percent
PHASE_ONE_ID 72.11 # I don't know, the rest is amorphous...
# other diffractogram info goes here
data_diffpat2
_pd_diffractogram.id DIFFPATT_WITH_PHASE_2
loop_
_pd_phase_mass.phase_id # what else goes here but a _pd_phase.id?
_pd_phase_mass.percent
PHASE_TWO_ID 37.33 # I don't know, the rest is amorphous...
# other diffractogram info goes here
can we take this to #74? its a better version of the description of PD_PHASE_LIST
and PD_DIFFRACTOGRAM_LIST
.
? I don't understand how this works? How can you refer to other things without their (long) key?
I misspoke, I meant provided once per data block, not per file. Let us move to #74
From the end of https://github.com/COMCIFS/Powder_Dictionary/pull/39#issuecomment-1371739998
In the original pdCIF dictionary (or at least the one converted to DDLm),
PD_PHASE
was aLoop
category, and_pd_phase_id
served only to link between_pd_phase_block_id
and_refln_phase_id
. See also description in §3.3.6.1 in Vol. G.We no longer have that ability to use a short, block-level identifier.
I think we make something like
_pd_phase.short_id
and_pd_diffractogram.short_id
, which have block-scope (ie not necessarily globally unique, only locally) to link between things like_pd_refln.phase_id
,_pd_pref_orient_March_Dollase.diffractogram_id
, etc. so that we don't have to have huge, UUID-like values everywhere.For example involving phase id, from the CIF1.1 version of things, you would do:
With the current dictionary, you would have to do:
which is not very pretty.