Discussion List Archives

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

Re: [ddlm-group] Discussion of hub-spoke proposal

Dear John B and others,

We indeed seem to have converged on a workable outline.   The reason I may appear attached to keeping 'Set' as a distinct category class is that I think it simplifies reading and writing dictionaries for mainstream use.  On the other hand, the hub and spokes concept is a more fundamentally correct description of the relationship between categories appearing in a datablock.  I propose the following  definition for a 'Set' category, on the understanding that this information is redundant and secondary, with the key relations being the fundamental determinant. There are plenty of other redundancies in DDLm so such redundancy, of itself, shouldn't matter and can be easily checked before publication using validation software.

Set
;
    Category of items that are restricted to a single value per datablock.
;

Note that it is important that any expansion dictionaries that add keys to a 'Set' category change _definition.class to 'Loop' and expand the _category_key.name list for the category.


On 8 July 2016 at 23:48, Bollinger, John C <John.Bollinger@stjude.org> wrote:
 


[...]
 
> dREL
> ====
[...]
> (2) Where a category contains keys that are themselves siblings, the dREL method must explicitly state the values of those keys when accessing other categories (see GEOM_ANGLE)


Yes.  And dREL already has a means of doing that, right?

dREL only envisages using a single value to index into a category, i.e. cat[index].value.  The DDLm authors have thus required a primary surrogate key (I hope I've got the database terminology right) for every Loop category (category.key_id). This key is usually formed in dREL from the compound key values. Funnily enough, these 'ID' datanames are never actually used to index a foreign category in cif_core in a situation where there is no alternative primary key available, but I have had occasion to use them in some experimental dREL methods for imgCIF.

To be completely rigorous in our proposed approach, we would need to allow syntax of the form cat[index1,index2].value or even cat[key1=index1,key2=index2].value, although this enhancement of syntax would not be needed in cif_core. The changes we are contemplating here will devalue the 'ID' datanames in favour of dealing directly with the compound keys, and so I'm currently not seeing much use for the ID datanames - it would be good if anybody can defend the need for having them at all.


[...]

It sounds like we are coming together, but don't we also need to propose dictionary changes to implement H&S, at least in the DDLm core?

Yes we do, and I will put together a draft proposal on Github for us to edit collaboratively before presenting to core CIF DMG and then COMCIFS.

all the best,
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

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