[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 have been no response to my previous email on this topic, I will assume that this group has no objections to the proposal below.

On Fri, 27 Jul 2018 at 15:33, James Hester <jamesrhester@gmail.com> wrote:
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


--
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]