Discussion List Archives

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

Re: [ddlm-group] Proposal to allow SU corresponding to a givenMeasurand data name to be linked using _name.linked_item_id

As there is a one-to-one link between the SU data name and the data name itself (that is, each data name may have only one SU data name, and visa versa), there is no parent or child data name in the sense used in DDL2 or DDLm, and the broader issues of where to accumulate child information in many-to-one relationships are not relevant. Seeking resolution and then consistency with those many-to-one situations imposes an unnecessary burden.  The original proposal simply makes finding the other end of the one-to-one link a whole lot simpler when you don't know whether a given data name has a default SU data name or a special one (like Fsigma).  Before moving on to your larger topic, do you have any objection to the original proposal, given the points made in this paragraph?

I do agree with your general point on accumulating parent-child relationships. My understanding is that mmCIF originally made the decision to do so solely in the parent definition, and to leave out child data name definitions completely, but later on (by popular request?) added child definitions with parent information. As a result, several of the categories in imgCIF have child keys of _diffrn.id (anything with 'diffrn' in the data name) but these child key data names are (almost) always absent from the imgCIF dictionary.  As I think you are hintng, Herbert, creating new child keys of a mmCIF or pdbx category requires updating the mmCIF/pdbx dictionary itself, and this therefore requires coordination with the PDB.

In terms of DDLm policy on accumulating parent-child information, that decision has been made for us in that there are no DDLm attributes that would indicate the child data names of a data name, and so there are no options for accumulation of this information.  The parent-child information is, of course, available, so generating a DDL2 version of DDLm dictionaries is not at all hampered by this lack of the appropriate attribute.

On 24 July 2018 at 21:32, Herbert J. Bernstein <yayahjb@gmail.com> wrote:
Before making this decision, we need to consider the general issue of requiring parents to accumulate all information on their children.  It makes the addition of new children more complex.  In general we could extract the information on parent-child relationships from either side.  We could require it on the parent, or on the child, or on both.  We should try to be consistent.

On Mon, Jul 23, 2018 at 11:39 PM, James Hester <jamesrhester@gmail.com> wrote:
Dear DDLm group,

(abbreviated text of issue raised at https://github.com/COMCIFS/cif_core/issues/86)

The current DDLm specification provides for a data name that contains the standard uncertainty of another data name to flag this relationship by setting _type.purpose to SU and _name.linked_item_id to the data name that it holds the SU of. However, it is more often useful to search in the opposite direction, that is, given a data name, find the data name that holds the SU. I therefore propose that, when a data name has _type.purpose of Measurand, a data name specified in _name.linked_item_id will hold the standard uncertainty.  Any objections?

James.

--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group



_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group




--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links