[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
--
Reply to: [list | sender only]
Re: [ddlm-group] Managing deprecation in DDLm
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Managing deprecation in DDLm
- From: James Hester <jamesrhester@gmail.com>
- Date: Tue, 8 Jan 2019 17:10:52 +1100
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:references:in-reply-to:reply-to:from:date:message-id:subject:to; bh=08F0bb2cGHOuS6tbTBrHRuMHlTV/ZOhwli1H1jqQUYw=;b=ar17SBkv77GYn6ntU41vwr4Mc61rfjnTDU/lYe8vfdccuv71CJFIGT50nkZgy+Pji+VHdufT5XJacqG2YNJt/r8Ajshx1UAv75Rbro1nRWiZAT7Vt5GbCWa4OO8KmOMoXUOTCnbTEqUFXq8J5cXV4kTBCgmb94Uf7LipojoIBuhs1GLUJ+gbo7AkQxsKnaxdpubhi1Pd+HSXMnbpzPx9dC/GoNwjZ3Uiqrm61I303wjKtdmNhEu6Oon876mUaGgqYELY0pcxwSrTIy7TB0ew9NHm2nXW83orafGBLcEBOAHLBqy7joFlkHwwyJRvThK6WNa2jBbxgDD3p4TJC2Vk/g==
- In-Reply-To: <CAM+dB2ec_zqoJODpiKhSuhqePPJ8Lk_zK+Z_3igHq-mX-6XBRA@mail.gmail.com>
- References: <CAM+dB2co6J-ksAAsWY3nz_NW=kc_VJ3Z0+UBc0+QNv9_xtaWww@mail.gmail.com><b7b15457-e721-659d-e52a-77e29fa68219@rcsb.org><CAM+dB2dRqLQOtVxLyfDpDG8BUHzcxaSQGVKnYtXcsthOP2k9jQ@mail.gmail.com><CAM+dB2ec_zqoJODpiKhSuhqePPJ8Lk_zK+Z_3igHq-mX-6XBRA@mail.gmail.com>
Dear DDLm group,
A new situation has come up where a dataname has been replaced by three datanames (see https://github.com/COMCIFS/cif_core/issues/104). As a result, it would be desirable to turn _definition.replaced_by into a looped category, so that multiple datanames can be listed. Does anybody have any objections? Currently I imagine it as a two-dataname category, that is, the previously-used dataname would simply become looped and an opaque identifier would also be added. I believe we should be able to simply replace this attribute as it has not been in existence for long. Otherwise, we can use it to deprecate itself. Here is a proposed set of replacement definitions:
save_DEFINITION_REPLACED
_definition.id DEFINITION_REPLACED
_definition.scope Category
_definition.class Loop
_definition.update 2019-01-08
_description.text
;
Attributes used to describe deprecated and replaced definitions
;
_name.category_id DEFINITION
_name.object_id DEFINITION_REPLACED
save_
_definition.class Attribute
_definition.update 2019-01-08
_description.text
;
A dataname that should be used instead of the defined dataname.
The defined dataname is deprecated and should not be used.
;
_name.category_id definition_replaced
_name.object_id by
_type.container Single
_type.purpose Encode
_type.contents Tag
_type.source Assigned
save_
_definition.class Attribute
_definition.update 2019-01-08
_description.text
;
An opaque identifier for the replacement
;
_name.category_id definition_replaced
_name.object_id id
_type.purpose Key
_type.source Assigned
_type.container Single
_type.contents Code
save_
On Fri, 9 Jun 2017 at 15:04, James Hester <jamesrhester@gmail.com> wrote:
James.Dear DDLm group,There having been no objections, I have incorporated the new '_definition.replaced_by' dataname into the DDLm dictionary (see https://github.com/COMCIFS/cif_core/blob/cif2-conversion/ddl.dic) and immediately put it to use to deprecate _symmetry.cell_setting in cif_core.On 15 May 2017 at 17:01, James Hester <jamesrhester@gmail.com> wrote:A dataname that should be used instead of the defined dataname. The defined dataname_description.text_name.object_id replaced_by_name.category_id definition_definition.id '_definition.replaced_by'save_definition.replaced_byDear DDLm-group,Please see the below a proposed definition for a new DDLm attribute to flag deprecation.
;is deprecated.
;_type.container Single_type.purpose Encode_type.contents Name_type.source Assignedsave_Note that this definition assumes that a deprecated dataname will have a clear replacement. The only current use case is for 'symmetry_cell_setting', whichallowed 8 different settings and appears to mix the concepts of 'crystal system' (7 members) and 'Bravais system' (7 members), leading to potential ambiguity as to which space groups belong to 'hexagonal'. No dataname is currently a direct substitute for 'symmetry_cell_setting', but 'space_group.crystal_system' appears closest in meaning.An alternative approach would add another enumerated state to type.purpose (e.g. 'Retired'), but this would mean both that (i) the original purpose was obscured, which may interfere with validation routines applied to old datafiles, and (ii) that there is no opportunity to suggest a replacement.Please comment,James.On 28 April 2017 at 22:15, john.westbrook@rcsb.org <john.westbrook@rcsb.org> wrote:
On 4/27/17 9:11 PM, James Hester wrote:
Dear DDLm-group,Aliases as used in DDL2 provide correspondences for semantically identical items. The role replaces/replacedby is identify
In the case of direct dataname equivalents, '_alias.deprecation_date' is suitable as a way of flagging deprecation. However, if
there is no one-for-one substitution, there is no easy way to deal with deprecation. For example, on the cif_core discussion list we
have been talking about how to deprecate _cell_symmetry_setting, which has no direct equivalent in the new core dictionary. Having
no equivalent clearly requires that we keep the dataname in the dictionary in order to interpret legacy files. For such definitions,
it would be good to (i) have an attribute that directly flags deprecation (ii) where an algorithm exists to convert values to an
alternative dataname (e.g. unit conversion), that this algorithm could be specified. While such deprecation happens very rarely, it
would seem prudent to allow for occasional mistakes in dataname definition.
Note that in DDL2 the _item_related.function_code dataname has values that indicate deprecation (Vol G table 2.6.5.1) and conversion
by multiplication: "replaces", "replacedby", "conversion_constant", "conversion_arbitrary". This is not a particularly good match
for us, as simple replacement is already accomplished by aliases, and simple constant multiplication is not always sufficient. We
also have dREL at our disposal for describing arbitrary transformations.
cases of deprecation and/or preferred usage which seems to be what you are seeking to represent.
Regards,
John
I propose the following:
(i) a new DDLm attribute '_definition.replaced_by' which would have the value of a dataname that should be used instead (or default
value 'None').
(ii) a new DDLm '_method.purpose' tag 'FromDeprecated' which could be used in the definition of the dataname that replaces the
deprecated definition. The method associated with this purpose would calculate the value of the new dataname from the old dataname
(and any other datanames that are necessary).
Does this scheme seem reasonable to you? If so, I will work up a proper definition.
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
--
John Westbrook, Ph.D.
RCSB, Protein Data Bank
Rutgers, The State University of New Jersey
Department of Chemistry and Chemical Biology
174 Frelinghuysen Rd
Piscataway, NJ 08854-8087
e-mail: john.westbrook@rcsb.org
Ph: (848) 445-4290 Fax: (732) 445-4320
_______________________________________________
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
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]
- References:
- [ddlm-group] Managing deprecation in DDLm (James Hester)
- Re: [ddlm-group] Managing deprecation in DDLm (john.westbrook@rcsb.org)
- Re: [ddlm-group] Managing deprecation in DDLm (James Hester)
- Re: [ddlm-group] Managing deprecation in DDLm (James Hester)
- Prev by Date: Re: [ddlm-group] Clarifying semantics of _type.purpose 'Key'
- Next by Date: Re: [ddlm-group] Clarifying semantics of _type.purpose 'Key'
- Prev by thread: Re: [ddlm-group] Managing deprecation in DDLm
- Next by thread: [ddlm-group] Treatment of CIF2 unicode characters with CIF1equivalents
- Index(es):