Discussion List Archives

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

Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .. .... .. .. .. .. .

On Tuesday, February 15, 2011 9:41 AM, I wrote:
>On Monday, February 14, 2011 10:07 PM, James Hester wrote:
>
>>My own position is to reserve support pending a demonstration of the
>>utility of the proposed changes, ie I do not favour accepting these
>>changes at this time.

[...]

>I will attempt, separately, to assemble brief justification and discussion points for at least the ALIAS-focused changes.

Here is the first in what may become a series of justifications for various parts of the proposal.  Although I strove for brevity, I fear that I did not achieve it.  As a substitute, I have attempted to keep the scope fairly narrow:

====
General

A stated objective for DDLm is that it should support the definition capabilities of DDL1 and DDL2.  To fully achieve that objective, DDLm must provide a semantic analog for DDL2's ITEM_ALIASES category, which has the attributes enumerated in the following table:

DDL2 attribute (_item_aliases.) DDLm 2008 equivalent
alias_name (key)                                _alias.definition_id
dictionary (key)                                (*)
version (key)                           (none)
name (implicit)                         _definition.id (from context)

(*) DDLm 2008 provides no exact semantic equivalent for DDL2's _item_aliases.dictionary.  _dictionary_xref.name provides the same data, but in different, non-associated context.  _alias.dictionary_uri may have been intended as an alternative dictionary identifier, but if so then that has proven controversial; in any case, that item is not semantically equivalent to _item_aliases.dictionary because it takes different values.

It is possible to provide for validating existing instance documents without mirroring DDL2's structure, but DDLm must carry equivalent data somewhere.  The proposal on the table makes dictionary_xref.name serve for _item_aliases.dictionary, and makes (new) dictionary_xref.version serve for _item_aliases.version, by adding _alias.xref_code to reference pairs of these.  It is sensible to use dictionary_xref and references to it for this purpose, so that information about referenced dictionaries is centralized in one place.


Category key

To embody the same validation rules in DDLm that DDL2 provides, DDLm aliases need to be keyed to the aliased item name, an identifier of the item's dictionary, and the version of that dictionary.  Because the proposed _alias.xref_code identifies specific dictionary (name, version) pairs, the current proposal's inclusion of xref_code in the ALIAS category key achieves key equivalence with DDL2, whereas DDLm 2008 does not.


Scope

The DDLm changes directly supported by these arguments are:
+ Addition of _alias.xref_code
+ Expansion of the ALIAS category key to include xref_code
+ Addition of _dictionary_xref.version


Open issues

Although there is good justification above for the aspects of the current proposal that are discussed above, there remain several points of possible disagreement, among them:

1) Is the given objective really one we are pursuing?  I think that's established, but the arguments above depend on that premise, so now would be a good time for anyone who disagrees to say so.

2) Do DDLm aliases really need to be keyed to a dictionary name and version?  It appears that in practice, _item_aliases.alias_name is unique within each definition in each of the official DDL2 dictionaries (mmCIF, imgCIF, and symCIF), therefore keying on _alias.definition_id alone would not prevent valid DDLm versions of any of those dictionaries from being prepared.  I continue to favor including at least a dictionary identifier in the key, for the additional expressive abilities that provides, but key choice is not arbitrary: the chosen set of key fields has semantic implications.

3) Do we indeed want to rely on dictionary_xref for recording information about other dictionaries?  I think there is considerable value in maintaining that information in a single, central category, but we could instead add separate fields to the ALIAS category to hold the additional DDL2 data.
====


Regards,

John
--
John C. Bollinger, Ph.D.
Department of Structural Biology
St. Jude Children's Research Hospital


Email Disclaimer:  www.stjude.org/emaildisclaimer

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/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