Re: [ddlm-group] Removing dictionary_xref,_definition.xref and _enumeration_xref attributes from DDLm

Dear DDLm group,

 

I am not aware of any discussion of those attributes at the ACA meeting.  Inasmuch as they seem to have gone unused, including in DDLm-aware software, I am content to remove them.  If we have a meaningful way to deprecate them for a time before their removal then I do not object to using it.  Being “meaningful” in this sense would mean that dictionary authors and maintainers working with up-to-date tools and an up-to-date version of DDLm itself would be likely to be affirmatively notified of the deprecations.

 

 

John

 

--

John C. Bollinger, Ph.D.

Computing and X-Ray Scientist

Department of Structural Biology

St. Jude Children's Research Hospital

John.Bollinger@StJude.org

(901) 595-3166 [office]

www.stjude.org

 

 

 

From: ddlm-group [mailto:ddlm-group-bounces@iucr.org] On Behalf Of Herbert J. Bernstein
Sent: Sunday, September 16, 2018 8:42 PM
To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Subject: Re: [ddlm-group] Removing dictionary_xref, _definition.xref and _enumeration_xref attributes from DDLm

 

Dear Colleagues,

  I do not think there was a discussion.  I should point out that the dictionary_xref category was in

https://www.iucr.org/__data/assets/file/0020/16373/ddl.dic in 2008.  I am not sure it was ever really used, but if we are going to take something away, I believe the appropriate process would be first to deprecate it in any currently used dictionaries and formally remove it only after the dictionary noting the deprecation has been in use for a year or two.

  Regards,

    Herbert

 

On Sun, Sep 16, 2018 at 8:28 PM James Hester <jamesrhester@gmail.com> wrote:

Dear DDLm-group,

 

Was there any discussion of the xref tags at the ACA meeting?  If yes, could the ACA attendees provide us with an overview of what was discussed? If not, then I propose dropping them from the current version of DDLm, and simply reserving the 'dictionary_xref' category for potential future use.

 

best wishes,

James.

 

 

On Mon, 28 May 2018 at 23:02, Herbert J. Bernstein <yayahjb@gmail.com> wrote:

Dear Colleagues,

 

  I believe we last attempted to resolve alias and xref handling in 2011.  Clearly we did not

come to a satisfactory resolution.  Alias has had a very important role to play in clarifying the

relationships among corecif and mmcif tags.  Do we have a similarly strong use case

for xref?  I would suggest those of us who come to the ACA meeting in July try to get

together and talk through whatever use cases we do have and try to finally get this

resolved.

 

  Regards,

      Herbert

 

 

 

On Mon, May 28, 2018 at 3:16 AM, James Hester <jamesrhester@gmail.com> wrote:

Dear DDLm group,

In preparing the Volume G chapter on DDLm I have noticed that the attributes related to cross-referencing data names with data names in other dictionaries are poorly documented. The intention of these attributes appears to be to allow data names from multiple arbitrary ontologies to be specified as equivalent to the defined data name, and provision is even made for matching enumerated values.  As far as I can tell, these definitions are incomplete, and they are not mentioned in the original DDLm paper.

For example, the _enumeration_set.xref_code and _enumeration_set.xref_dictionary attributes do not specify the particular foreign data name(s) in that foreign dictionary that the value equivalence applies to, perhaps assuming that only one data name can be equivalent to the defined data name in any given foreign dictionary. This is not strictly true in cases where the other ontology splits a category into parts, for example the 'axis' category in imgCIF might be split into 'goniometer axis' and 'detector axis' in some other ontology.  _definition.xref_code allows a single foreign data name to be specified for the whole definition, but there is no reference to which dictionary this comes from, as multiple foreign dictionaries can be referenced using _dictionary_xref. Given that these attributes have clearly never been implemented, let alone tested, and are not essential to DDLm functionality (they do not appear in any of our draft or approved DDLm dictionaries) I was wondering if anybody here would like to defend their inclusion in DDLm, rather than e.g. in some future DDLm extension dictionary dedicated to interoperability. I note also that specification of foreign equivalents in a canonical dictionary would clutter definitions and those definitions might need to be kept up to date with changes in that foreign ontology (although a date is attached to each foreign dictionary).

Alternatively, we should be able to come up with a complete scheme that covers all of the possible interrelationships in a way that is useful (i.e. facilitates automatic interoperability with non-CIF data files).

Thoughts?

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

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

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