[Date Prev][Date Next][Date Index]
(61) pdCIF: category concerns
- To: COMCIFS@iucr.ac.uk
- Subject: (61) pdCIF: category concerns
- From: bm
- Date: Tue, 6 May 1997 11:58:30 +0100
Dear Colleagues After the flurry of activity in mid-March, you are probably wondering what became of the approval for the powder dictionary, which seemed so imminent. There were a number of votes in favour of the dictionary, which were accompanied by some expressions of concern at the category structure in the powder dictionary, and which I reprint below for the record. However, there was a more sustained concern from Paula, which we tried to resolve in some offline correspondence; and she has put together a substantial review of her concerns, which forms the bulk of this mailing. I would ask you to read this mailing with great care, and make any contributions to the argument as soon as possible. I am sorry that it has taken some time to get to this point, but I hope we can resolve the difficulties and objections raised in the near future. Perhaps Brian T. will be able to kick off the discussions with an early indication of the extent to which he can address the inconsistencies Paula alludes to. D61.1 pdCIF categories revisited --------------------------------- Syd Hall wrote: S> Brian: At last I have got to the COMCIFS matters. I really needed a S> dedicated period to do these justice and this simply has not been S> possible over the past two weeks. S> S> Here are my comments on the powder dictionary. Pls ignore any S> remarks that have already been made by my much faster colleagues!! S> S> (1) I note that the _category names do not correspond to the data S> names in that group. e.g. S> S> data_pd_meas_number_of_points S> _name '_pd_meas_number_of_points' S> _category pd_meas_method S> _type numb S> _enumeration_range 1: S> _definition S> ; The total number of points in the measured S> diffractogram. S> ; S> S> data_pd_meas_datetime_initiated S> _name '_pd_meas_datetime_initiated' S> _category pd_meas_method S> S> S> Has this matter been OK'd in the past? If so, I think that the S> conversion of this dictionary to DDL2 is going to be very difficult. S> See also (7) below. S> ... S> S> (7) I return to the category naming conventions. These serve to S> designate which items reside in the same lists or loops. Judging S> from the wide use of categories pd_data and pd_instr, this S> function has been abandoned? S> S> E.g. S> data_pd_proc_d_spacing S> _name '_pd_proc_d_spacing' S> _category pd_data S> _type numb S> S> data_pd_meas_counts_ S> loop_ _name '_pd_meas_counts_total' S> '_pd_meas_counts_background' S> '_pd_meas_counts_container' S> '_pd_meas_counts_monitor' S> _category pd_data S> _type numb S> S> S> S> S> All in all I am most impressed by the effort that has gone into the S> definitions, they are detailed and clear. But several of the matters S> above are of fundamental importance...and the category assignations S> in particular must be assessed carefully to avoid long term problems. Gotzon Madariag wrote: G> I essentially approve the dictionary. G> G> Really the assigned categories were a bit shocking and out of the G> current criteria used in the Core. My position in this case is closer to G> (not written) COMCIFS orthodoxy but I understand the necessary flexibility G> claimed by Brian Toby. Paula's argument now follows: - - - - - I find myself in the position of being the lone dissenting vote against COMCIFS acceptance of the CIF powder dictionary, but I feel that there are significant enough problems with the relationship of the formalism of that dictionary to the other CIF dictionaries (either approved or currently under development) that it is important to deal with these dissimilarities before formal acceptance. I have delayed writing this note summarizing these issues out of a concern that, being the sole vote against approval of the powder dictionary, I am going significantly against the opinions of the other members of COMCIFS. However, the issues that are troubling me are the same issues that others have voiced in the previous dicussions about the powder dictionary - I was hoping that others would pursue these issues to some conclusion, but it appears that my colleagues on this committee feel that greater good is being done by getting the powder dictionary approved and into use than by standing firm on issue of formalism at this point. As I say, the main issue troubling me has been raised before, and it is the lack of rigor in the category structure within the powder dictionary. It is true than when development of the powder dictionary began, there was only a loose category organization for the core, and that the need for a more formalised category structure has become clear only in more recent times. But the development of the mmCIF dictionary, and particularly of the software to validate and implement that dictionary, have made absolutely clear that a formal category structure is imperative. In ordering my thoughts on this subject, I found it was extremely useful to deal with specifics rather than generalities. So bear with me while I become extremely specific about what I feel are the problems with the powder dictionary. My first step was to reduce the powder dictionary to its essentials - the data names, their category specifications, the designation of whether they belong to a list, and, if so, what the identifier for that list is. That table follows. #......................... Block/Dataset names '_pd_block_[pd]' category_overview '_pd_block_diffractogram_id' pd_proc '_pd_block_id' pd_block #......................... Measured Diffractogram Information '_pd_meas_[pd]' category_overview '_pd_meas_2theta_fixed' pd_meas_method ---- '_pd_meas_2theta_range_min' pd_meas_method ---- '_pd_meas_2theta_scan' pd_data yes '_pd_meas_angle_chi' pd_data both '_pd_meas_counts_total' pd_data yes '_pd_meas_datetime_initiated' pd_meas_method ---- '_pd_meas_detector_id' pd_data yes ---- '_pd_meas_info_author_address' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_email' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_fax' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_name' pd_meas_info both ---- '_pd_meas_info_author_phone' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_intensity_total' pd_data yes ---- '_pd_meas_number_of_points' pd_meas_method ---- '_pd_meas_position' pd_data yes '_pd_meas_rocking_angle' pd_data ---- '_pd_meas_rocking_axis' pd_meas_method both '_pd_meas_scan_method' pd_meas_method ---- '_pd_meas_special_details' pd_meas_method ---- '_pd_meas_step_count_time' pd_data both '_pd_meas_time_of_flight' pd_data yes '_pd_meas_units_of_intensity' pd_meas_method ---- #........................... Calibration Information '_pd_calib_[pd]' category_overview '_pd_calib_2theta_offset' pd_calib both '_pd_calib_detector_id' '_pd_calib_detector_id' pd_calib yes '_pd_calib_detector_response' pd_calib yes '_pd_calib_detector_id' '_pd_calib_std_external_id' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_mass_%' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_name' pd_calib both '_pd_calib_detector_id' '_pd_calibration_conversion_eqn' pd_calibration ---- '_pd_calibration_special_details' pd_calibration ---- #............................ Specimen parameters '_pd_spec_[pd]' category_overview '_pd_spec_description' pd_spec ---- '_pd_spec_mount_mode' pd_spec ---- '_pd_spec_mounting' pd_spec ---- '_pd_spec_orientation' pd_spec ---- '_pd_spec_preparation' pd_spec ---- '_pd_spec_shape' pd_spec ---- '_pd_spec_size_axial' pd_spec ---- '_pd_spec_special_details' pd_spec ---- #............................ Instrument parameters '_pd_instr_[pd]' category_overview '_pd_instr_2theta_monochr_pre' pd_instr both '_pd_instr_beam_size_ax' pd_data ---- '_pd_instr_cons_illum_flag' pd_instr no '_pd_instr_cons_illum_len' pd_instr no '_pd_instr_dist_src/mono' pd_instr both '_pd_instr_divg_ax_src/mono' pd_instr both '_pd_instr_divg_eq_src/mono' pd_instr both '_pd_instr_geometry' pd_instr ---- '_pd_instr_location' pd_instr ---- '_pd_instr_monochr_pre_spec' pd_instr both '_pd_instr_slit_ax_src/mono' pd_instr both '_pd_instr_slit_eq_src/mono' pd_instr both '_pd_instr_soller_ax_src/mono' pd_instr both '_pd_instr_soller_eq_src/mono' pd_instr both '_pd_instr_source_size_ax' pd_instr ---- '_pd_instr_special_details' pd_instr ---- '_pd_instr_var_illum_len' pd_data yes #............................. Processed Diffractogram '_pd_proc_[pd]' category_overview '_pd_proc_2theta_corrected' pd_data yes '_pd_proc_2theta_range_min' pd_data ---- '_pd_proc_d_spacing' pd_data yes '_pd_proc_energy_incident' pd_data both '_pd_proc_info_author_address' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_email' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_fax' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_name' pd_proc_info both '_pd_proc_info_author_phone' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_data_reduction' pd_proc_info ---- '_pd_proc_info_datetime' pd_proc_info both '_pd_proc_info_excluded_regions' pd_proc_info ---- '_pd_proc_info_special_details' pd_proc_info ---- '_pd_proc_intensity_net' pd_data yes '_pd_proc_number_of_points' pd_proc_info ---- '_pd_proc_recip_len_Q' pd_data yes '_pd_proc_wavelength' pd_data both #......................... Least Squares (Profile/Rietveld fit) parameters '_pd_proc_ls_[pd]' category_overview '_pd_proc_ls_background_function' pd_proc_ls ---- '_pd_proc_ls_peak_cutoff' pd_proc_ls no '_pd_proc_ls_pref_orient_corr' pd_proc_ls ---- '_pd_proc_ls_prof_R_factor' pd_proc_ls ---- '_pd_proc_ls_profile_function' pd_proc_ls ---- '_pd_proc_ls_special_details' pd_proc_ls ---- '_pd_proc_ls_weight' pd_data yes #............................. Calculated Diffractogram '_pd_calc_[pd]' category_overview '_pd_calc_intensity_net' pd_data yes '_pd_calc_method' pd_calc ---- #......................... Peak Table '_pd_peak_[pd]' category_overview '_pd_peak_2theta_centroid' pd_peak yes '_pd_peak_id' '_pd_peak_d_spacing' pd_peak yes '_pd_peak_id' '_pd_peak_id' pd_peak yes '_pd_peak_intensity' pd_peak yes '_pd_peak_id' '_pd_peak_pk_height' pd_peak yes '_pd_peak_id' '_pd_peak_special_details' pd_peak_method ---- '_pd_peak_wavelength_id' pd_peak yes '_pd_peak_id' '_pd_peak_width_2theta' pd_peak yes '_pd_peak_id' '_pd_peak_width_d_spacing' pd_peak yes '_pd_peak_id' #............................ Crystalline Phase Assignments '_pd_phase_[pd]' category_overview '_pd_phase_block_id' pd_phase yes '_pd_phase_id' '_pd_phase_id' pd_phase yes '_pd_phase_mass_%' pd_phase yes '_pd_phase_id' '_pd_phase_name' pd_phase both '_pd_phase_id' #............................ Peak Reflection Identification '_pd_refln_[pd]' category_overview '_pd_refln_peak_id' refln yes '_refln_index_h' '_pd_refln_phase_id' refln yes '_refln_index_h' '_pd_refln_wavelength_id' refln yes '_refln_index_h' #............................. Sample Preparation Information '_pd_prep_[pd]' category_overview '_pd_prep_conditions' pd_prep ---- '_pd_prep_cool_rate' pd_prep ---- '_pd_prep_pressure' pd_prep ---- '_pd_prep_temperature' pd_prep ---- #............................. Characterisation Information '_pd_char_[pd]' category_overview '_pd_char_atten_coef_mu_obs' pd_char ---- '_pd_char_colour' pd_char ---- '_pd_char_particle_morphology' pd_char ---- '_pd_char_special_details' pd_char ---- - - - - - One sees instantly that there are more categories than there are category overviews, but given that DDL 1.4 does not demand a category overview for each category, we will ignore that. One thing that DDL 1.4 does specify, however, is that items in different categories cannot appear in the same list. Hence I have resorted the list in alphabetical order by category, with a secondary sort on data name within each category. In the second list, I have taken the liberty of converting those cases where the value of list is not specified to "no", which is the default in DDL 1.4 - - - - - '_pd_block_id' pd_block both '_pd_calc_method' pd_calc no '_pd_calib_2theta_offset' pd_calib both '_pd_calib_detector_id' '_pd_calib_detector_id' pd_calib yes '_pd_calib_detector_response' pd_calib yes '_pd_calib_detector_id' '_pd_calib_std_external_id' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_mass_%' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_name' pd_calib both '_pd_calib_detector_id' '_pd_calibration_conversion_eqn' pd_calibration no '_pd_calibration_special_details' pd_calibration no '_pd_char_atten_coef_mu_obs' pd_char no '_pd_char_colour' pd_char no '_pd_char_particle_morphology' pd_char no '_pd_char_special_details' pd_char no '_pd_calc_intensity_net' pd_data yes '_pd_instr_beam_size_ax' pd_data no '_pd_instr_var_illum_len' pd_data yes '_pd_meas_2theta_scan' pd_data yes '_pd_meas_angle_chi' pd_data both '_pd_meas_counts_total' pd_data yes '_pd_meas_detector_id' pd_data yes '_pd_meas_intensity_total' pd_data yes '_pd_meas_position' pd_data yes '_pd_meas_rocking_angle' pd_data no '_pd_meas_step_count_time' pd_data both '_pd_meas_time_of_flight' pd_data yes '_pd_proc_2theta_corrected' pd_data yes '_pd_proc_2theta_range_min' pd_data no '_pd_proc_d_spacing' pd_data yes '_pd_proc_energy_incident' pd_data both '_pd_proc_intensity_net' pd_data yes '_pd_proc_recip_len_Q' pd_data yes '_pd_proc_wavelength' pd_data both '_pd_proc_ls_weight' pd_data yes '_pd_instr_2theta_monochr_pre' pd_instr both '_pd_instr_cons_illum_flag' pd_instr no '_pd_instr_cons_illum_len' pd_instr no '_pd_instr_dist_src/mono' pd_instr both '_pd_instr_divg_ax_src/mono' pd_instr both '_pd_instr_divg_eq_src/mono' pd_instr both '_pd_instr_geometry' pd_instr no '_pd_instr_location' pd_instr no '_pd_instr_monochr_pre_spec' pd_instr both '_pd_instr_slit_ax_src/mono' pd_instr both '_pd_instr_slit_eq_src/mono' pd_instr both '_pd_instr_soller_ax_src/mono' pd_instr both '_pd_instr_soller_eq_src/mono' pd_instr both '_pd_instr_source_size_ax' pd_instr no '_pd_instr_special_details' pd_instr no '_pd_meas_info_author_address' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_email' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_fax' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_info_author_name' pd_meas_info both '_pd_meas_info_author_phone' pd_meas_info both '_pd_meas_info_author_name' '_pd_meas_2theta_fixed' pd_meas_method no '_pd_meas_2theta_range_min' pd_meas_method no '_pd_meas_datetime_initiated' pd_meas_method no '_pd_meas_number_of_points' pd_meas_method no '_pd_meas_rocking_axis' pd_meas_method both '_pd_meas_scan_method' pd_meas_method no '_pd_meas_special_details' pd_meas_method no '_pd_meas_units_of_intensity' pd_meas_method no '_pd_peak_2theta_centroid' pd_peak yes '_pd_peak_id' '_pd_peak_d_spacing' pd_peak yes '_pd_peak_id' '_pd_peak_id' pd_peak yes '_pd_peak_intensity' pd_peak yes '_pd_peak_id' '_pd_peak_pk_height' pd_peak yes '_pd_peak_id' '_pd_peak_wavelength_id' pd_peak yes '_pd_peak_id' '_pd_peak_width_2theta' pd_peak yes '_pd_peak_id' '_pd_peak_width_d_spacing' pd_peak yes '_pd_peak_id' '_pd_peak_special_details' pd_peak_method no '_pd_phase_block_id' pd_phase yes '_pd_phase_id' '_pd_phase_id' pd_phase yes '_pd_phase_mass_%' pd_phase yes '_pd_phase_id' '_pd_phase_name' pd_phase both '_pd_phase_id' '_pd_block_diffractogram_id' pd_proc yes '_pd_proc_info_author_address' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_email' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_fax' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_name' pd_proc_info both '_pd_proc_info_author_phone' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_data_reduction' pd_proc_info no '_pd_proc_info_datetime' pd_proc_info both '_pd_proc_info_excluded_regions' pd_proc_info no '_pd_proc_info_special_details' pd_proc_info no '_pd_proc_number_of_points' pd_proc_info no '_pd_proc_ls_background_function' pd_proc_ls no '_pd_proc_ls_peak_cutoff' pd_proc_ls no '_pd_proc_ls_pref_orient_corr' pd_proc_ls no '_pd_proc_ls_prof_R_factor' pd_proc_ls no '_pd_proc_ls_profile_function' pd_proc_ls no '_pd_proc_ls_special_details' pd_proc_ls no '_pd_prep_conditions' pd_prep no '_pd_prep_cool_rate' pd_prep no '_pd_prep_pressure' pd_prep no '_pd_prep_temperature' pd_prep no '_pd_spec_description' pd_spec no '_pd_spec_mount_mode' pd_spec no '_pd_spec_mounting' pd_spec no '_pd_spec_orientation' pd_spec no '_pd_spec_preparation' pd_spec no '_pd_spec_shape' pd_spec no '_pd_spec_size_axial' pd_spec no '_pd_spec_special_details' pd_spec no '_pd_refln_peak_id' refln yes '_refln_index_h' '_pd_refln_phase_id' refln yes '_refln_index_h' '_pd_refln_wavelength_id' refln yes '_refln_index_h' - - - - - Given all of that setup, here are some questions. - - - - - '_pd_phase_block_id' pd_phase yes '_pd_phase_id' '_pd_phase_id' pd_phase yes '_pd_phase_mass_%' pd_phase yes '_pd_phase_id' '_pd_phase_name' pd_phase both '_pd_phase_id' Is the intent really that _pd_phase_name can, if desired, appear by itself as a non-looped data item? If used in that that way, it could not be grouped with _pd_phase_block_id, _pd_phase_id and _pd_phase_mass_%, all of which must appear in looped lists. - - - - - '_pd_proc_info_author_address' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_email' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_fax' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_author_name' pd_proc_info both '_pd_proc_info_author_phone' pd_proc_info both '_pd_proc_info_author_name' '_pd_proc_info_data_reduction' pd_proc_info no '_pd_proc_info_datetime' pd_proc_info both '_pd_proc_info_excluded_regions' pd_proc_info no '_pd_proc_info_special_details' pd_proc_info no '_pd_proc_number_of_points' pd_proc_info no Here I raise a question of style - aren't these really two different categories - the author information, which can be either looped or individual, and the experimental information. If we break this into two different categories, as least in a virtual sense, then we have, for the experimental data items: '_pd_proc_info_data_reduction' pd_proc_info no '_pd_proc_info_datetime' pd_proc_info both '_pd_proc_info_excluded_regions' pd_proc_info no '_pd_proc_info_special_details' pd_proc_info no '_pd_proc_number_of_points' pd_proc_info no The question then arises as to how one would meaningfully use _pd_proc_info_datetime, and only that data item, by itself in a looped list. - - - - - '_pd_meas_2theta_fixed' pd_meas_method no '_pd_meas_2theta_range_min' pd_meas_method no '_pd_meas_datetime_initiated' pd_meas_method no '_pd_meas_number_of_points' pd_meas_method no '_pd_meas_rocking_axis' pd_meas_method both '_pd_meas_scan_method' pd_meas_method no '_pd_meas_special_details' pd_meas_method no '_pd_meas_units_of_intensity' pd_meas_method no Same question here - how would one meaningfully use _pd_meas_rocking_axis by itself in a looped list. - - - - - '_pd_instr_2theta_monochr_pre' pd_instr both '_pd_instr_cons_illum_flag' pd_instr no '_pd_instr_cons_illum_len' pd_instr no '_pd_instr_dist_src/mono' pd_instr both '_pd_instr_divg_ax_src/mono' pd_instr both '_pd_instr_divg_eq_src/mono' pd_instr both '_pd_instr_geometry' pd_instr no '_pd_instr_location' pd_instr no '_pd_instr_monochr_pre_spec' pd_instr both '_pd_instr_slit_ax_src/mono' pd_instr both '_pd_instr_slit_eq_src/mono' pd_instr both '_pd_instr_soller_ax_src/mono' pd_instr both '_pd_instr_soller_eq_src/mono' pd_instr both '_pd_instr_source_size_ax' pd_instr no '_pd_instr_special_details' pd_instr no Here we have two groups of data items, those that can be either looped or not, and those that may not be looped. Looking carefully at the data items, I find that it makes sense that a given instrument can have only one geometry and location, but any number of slits (for example), but that doesn't prevent me from thinking that these data really belong in two different categories, one that is not looped, and one that may be looped if needed. - - - - - '_pd_calib_2theta_offset' pd_calib both '_pd_calib_detector_id' '_pd_calib_detector_id' pd_calib yes '_pd_calib_detector_response' pd_calib yes '_pd_calib_detector_id' '_pd_calib_std_external_id' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_mass_%' pd_calib both '_pd_calib_detector_id' '_pd_calib_std_internal_name' pd_calib both '_pd_calib_detector_id' Another seeming lack of consistency - _pd_calib_detector_response must appear in a list, but _pd_calib_2theta_offset, _pd_calib_std_external_id, _pd_calib_std_internal_mass_%, and _pd_calib_std_internal_name can be either looped or not. - - - - - And then there is pd_data. '_pd_calc_intensity_net' pd_data yes '_pd_instr_beam_size_ax' pd_data no '_pd_instr_var_illum_len' pd_data yes '_pd_meas_2theta_scan' pd_data yes '_pd_meas_angle_chi' pd_data both '_pd_meas_counts_total' pd_data yes '_pd_meas_detector_id' pd_data yes '_pd_meas_intensity_total' pd_data yes '_pd_meas_position' pd_data yes '_pd_meas_rocking_angle' pd_data no '_pd_meas_step_count_time' pd_data both '_pd_meas_time_of_flight' pd_data yes '_pd_proc_2theta_corrected' pd_data yes '_pd_proc_2theta_range_min' pd_data no '_pd_proc_d_spacing' pd_data yes '_pd_proc_energy_incident' pd_data both '_pd_proc_intensity_net' pd_data yes '_pd_proc_recip_len_Q' pd_data yes '_pd_proc_wavelength' pd_data both '_pd_proc_ls_weight' pd_data yes My greatest objection here is that these data names do not begin with the category name - again, there is no formal rule to prevent this, but it sure is going to make things very confusing for the user, who must remember that this collection of data names cannot appear in the lists implied by the data name itself. But there is also such a mixed bag of list assignments within the category. _pd_instr_beam_size_ax cannot appear in a list, but _pd_instr_var_illum_len must. _pd_proc_2theta_range_min cannot appear in a list, but _pd_proc_2theta_corrected must. _pd_meas_time_of_flight must appear in a list, _pd_meas_step_count_time can go either way, and _pd_meas_rocking_angle may not appear in a list. - - - - - You get the idea. I'll finish by stating my objection one more time - none of the above violates any hard and firm rule, but allowing this order of flexibility and variability is going to makes this an extremely difficult data structure with which to work, most especially from a software perspective. And this is certainly not the direction in which the CIF core dictionary is moving - although that dictionary is also written in DDL 1.4, it has taken on the flavor of a more rigorous database structure - items are grouped by names into categories, each category has a category overview, and each data item that may appear in a list has a _list_reference specified. I really hope that the powder dictionary can adopt the same level of category formality. I'd like to thank John Westbrook and Helen Berman for many helpful discussions in formalizing these thoughts and commiting them to writing. Paula Fitzgerald - - - - - Regards Brian
- Prev by Date: (60) Powder indexing; final call on pdCIF 1.0
- Next by Date: (62) pdCIF category semantics
- Index(es):