[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
save_definition.replaced_by
_definition.id '_definition.replaced_by'
_name.category_id definition
_name.object_id replaced_by
_description.text
;
A dataname that should be used instead of the defined dataname. The defined dataname
--
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: Mon, 15 May 2017 17:01:51 +1000
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=QLLl0IvPJcgN+sfoRyb+IJmy0t5JXoh1GV1DC7iUk5g=;b=Fnvrfbg6HBr7g43hJDgnuTSAcUK49ZZgY6WdzP5Y9MaNRz5UpBIGTPTENGzwquavm7BU45bRlvwwXFh5q6sPa2FU+dzK2sGFIng4O9c64Bx5IZ+6UHCJTwAFkePUVPLeOn7y3cS37VejaE7LTcn8zPONn65Kz8K7Ihunu7VKjvKdkZbKLvpEbNbNKd8IjpTu8mTVS1RxGhsBCM9B7T6qJT2gyrz/iynYtjflj8WXPssbFOD4p3M4aLd35HmRxNKG3Z2CF7z7N3CwCeycR4RCJnZN9xj7Bcf0+CUdUr2RA0dyefszLO3R8So6NCPoyol1mrhJ8Xqy4vl+lLqsKlkueQ==
- In-Reply-To: <b7b15457-e721-659d-e52a-77e29fa68219@rcsb.org>
- References: <CAM+dB2co6J-ksAAsWY3nz_NW=kc_VJ3Z0+UBc0+QNv9_xtaWww@mail.gmail.com><b7b15457-e721-659d-e52a-77e29fa68219@rcsb.org>
Dear 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 Assigned
save_
Note that this definition assumes that a deprecated dataname will have a clear replacement. The only current use case is for 'symmetry_cell_setting', which
allowed 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
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]
- Follow-Ups:
- Re: [ddlm-group] Managing deprecation in DDLm (James Hester)
- References:
- [ddlm-group] Managing deprecation in DDLm (James Hester)
- Re: [ddlm-group] Managing deprecation in DDLm (john.westbrook@rcsb.org)
- Prev by Date: Re: [ddlm-group] Treatment of CIF2 unicode characters with CIF1equivalents
- Next by Date: Re: [ddlm-group] Managing deprecation in DDLm
- Prev by thread: Re: [ddlm-group] Managing deprecation in DDLm
- Next by thread: Re: [ddlm-group] Managing deprecation in DDLm
- Index(es):