[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Making ddl2 <-> ddlm translation a reality
- To: ddlm-group <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] Making ddl2 <-> ddlm translation a reality
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Thu, 16 Apr 2020 14:04:53 +0000
- Accept-Language: en-US
- ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=passsmtp.mailfrom=stjude.org; dmarc=pass action=none header.from=stjude.org;dkim=pass header.d=stjude.org; arc=none
- ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=r5hSZ5kHu2b00gAmTXVnXfF9fZQA81EOCBb7ZWq8JL0=;b=ZBN9YV77S8nuaQtP1N3glMeH9Q8T6gwpuP7ZX1F8YLYufg+zCW2W9JyAhYHS+re4ObTliXOGRt0ZA9qJSXXiX/bL4ke3yD51cbvaA8M/MjSxiNgdURQBqdf7h54bzTj9XyT572QvffCSNDAwVIRRij4wQj2aDC95F938ZdkhqGobYMAaUSSkN5v7tBPnRfkjrPc7sTOD2JEq/H/pAC1qlNELip44TbRwplCqCEX0BD1sVY0SoVhiw53oHRjvOSTiAR5OTCYKJZCUfUroakUg6GkBqIsdmWOoAv2kUKt/zmMjiVRpgRJ42nRFzYaocazRuL2GePGeMqCX+T+GkSxYZw==
- ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;b=gifq7xc4ougI6VeHvHZefATtUXDBcFy2fAirpvfnDdyi04clgcv50STTvLjiGX1EGuUboLOWSe5gX8LbJ37gtwhSXy3GC1cuYQbcuINLmEhAx8bBz7EuimG/3V9eX4wu2N6Xrm0kYVyoHFkV9UwSFf3HlTjk9aXIGtGuT6j4biMYi/MFdEr/f6NkvsPdLCiw1W39bZpMMOI5jYQhsEbt4m7It/MvV/uHDgR5fc/8vAkc84+rxBJFxycvYIw173tiqQbZaSIltE6j/nIBbCShxUPQORmtVCqlWU5eTxFq50FH2sLlJrMaLx1198oFxFt1sCmWbHzetVL5yObpgy/6Ag==
- authentication-results: spf=none (sender IP is )smtp.mailfrom=John.Bollinger@STJUDE.ORG;
- In-Reply-To: <CAM+dB2fpUR5NnrUK1-6ngPcssYVCSxK3TfXDiJZQBLxT7B1PwQ@mail.gmail.com>
- IronPort-SDR: XFRVoE62E+8B2WVuRc7GS25kej+SdD+CfI/SQ6HLxUkyFovxPZmQq80iZ6HlDVaW9SJIH41aFpjsfoKbmxuPwqVCl270eOsJfPHuM55otEsfSl7qrcMaxcceZKighyqI/iStEOhI7IE70kbYby6PInM8lXP1SwbZV9UEfJ9Ll+SGFVT/ypA5Yhv3AgPwjFCXcsbr+rAVQlx/I8ppIW9k/hjRCjWcBzPi59Ys2OU5TFdXWfpXn/LysTk8Sl4AD3sVVykZQW4WlqHfIA+R/4Gu7HV3piwMP3d5XLWh3Lx/qzY=
- References: <CAM+dB2fpUR5NnrUK1-6ngPcssYVCSxK3TfXDiJZQBLxT7B1PwQ@mail.gmail.com>
Dear DDLm group,
There are (at least) two kinds of type information that need somehow to be preserved in order to successfully round-trip a DDL2 dictionary through a DDLm representation: (i) the components of the item_type_list itself, and (ii) the type assignment for each item. Although it appears that in practice, most DDL2 dictionaries use a subset of mmCIF's item_type_list, it is not safe in a general sense to take that list as universally applicable. Moreover, taking it that way would moot the point of the category, inasmuch as I take that to be that dictionaries define their own data types. Thus, I do not favor James's option (1).
Perhaps James has something more specific in mind for his (3) than I gather from his description, but I agree that the general idea seems fraught. Pretty much anything ought to be doable in this general way, though, because it should be possible to write a meta-CIF dictionary in DDLm, with which we could then represent arbitrary CIF conforming to arbitrary dictionaries. I emphasize, however, that I am not recommending this approach.
Of James's suggestions, that leaves (2). I am inclined to think that it would be easiest to implement, too, and relatively clear. The main disadvantage I see is that it would be specific to the DDL2-mapping case, but I could live with that, given the additional attributes being defined in an extension dictionary, as James suggests, not in DDLm proper.
It occurs to me to consider whether a DDLm definition of DDL2 itself (not necessarily round-trippable) would be useful here. It's an interesting though experiment, and the exercise might even be worthwhile, but I'm inclined to think that it has nothing new to offer with respect to the matter presently at hand.
From: ddlm-group <email@example.com> on behalf of James Hester <firstname.lastname@example.org>
Sent: Thursday, April 16, 2020 12:33 AM
To: ddlm-group <email@example.com>
Subject: [ddlm-group] Making ddl2 <-> ddlm translation a reality
Caution: External Sender
Dear DDLm group,
imgCIF has not yet been incorporated into the DDLm world, which I think is essential for us to take advantage of its excellent raw data descriptors. As we all know, raw data is becoming increasingly important, and even if data are not stored in CIF format, CIF descriptors can be adapted to any format. In order to support a DDLm version of the imgCIF dictionary, imgCIF maintainers want a DDL2 -> DDLm -> DDL2 dictionary round trip to preserve the important information. This will allow a single version of imgCIF to be maintained and be available to both the macromolecular community and to the communities covered by non-DDL2 dictionaries.
As part of preliminary investigation I have analysed how the translation would work in both directions by writing (but not testing!!) dREL methods that operate on dictionary data. I'll make this document available on Github shortly. Most of the fundamental relationships and data name information are simple to transform.
However, as a result of this investigation I have come up against a key problem that has long ago been identified, related to DDL2 types. So: item_type_list is a category that tabulates all possible DDL2 "types", by linking a type name with a regular expression, a primitive type (char/uchar/numb/null) and an explanation. In contrast to DDLm, these types are defined in the domain dictionary instead of semi-baked into the DDL.
While a mapping from DDL2 types to DDLm types is largely straightforward, in doing this a lot of the DDL2 imgCIF/mmCIF information is lost, particularly the highly detailed distinctions between various textual formats in imgCIF/mmCIF that are captured in regular expressions. This means that sensible translation back to DDL2 is impossible, most fundamentally because the DDL2 names of the types are not preserved - DDLm has no dictionary-definable types.
Here are some options that I see for solving this, and by extension the basic DDLm -> DDL2 translation problem:
(1) When translating DDLm-> DDL2, the _item_type_list found in mmCIF/PDBx is consulted for matching regex and the corresponding code used. If none found, arbitrary code is generated.
(2) We create an extension dictionary to DDLm which defines a few extra attributes specifically for preserving DDL2 information (e.g. type codes).
(3) We create a new DDLm category for "foreign" attributes, where arbitrary foreign attributes with values can be listed.
(4) Your suggestions?
Option (1) is not that unnatural, as imgCIF (and as I understand it any mmCIF extension dictionary) should harmonise its units and item type lists with mmCIF. So the translation is not DDLm -> DDL2, but instead DDLm -> DDL2 -> mmCIF extension dictionary. However, in this case we would be using the regex as a natural key and so the DDL2->mmCIF extension step is a bit fragile e.g. there might be multiple ways to express the same text constraints using a regex and therefore matches might be missed if either DDL2 or DDLm sides update a regex.
Option (2) is easy enough to create, and has the advantage of extensibility if and when more things that are dropped in translation are desired. It also serves to "define" the differences in information granularity between DDL2 and DDLm. It allows "pure" DDLm users to work in DDLm, and then if somebody wishes to incorporate that ontology into the mmCIF world, the list of necessary attributes to add to the definitions is available. It does however create (yet) another DDL, although one that could be said to come under the DDLm umbrella. Additionally, it may serve as a model for integrating with other ontologies beyond DDL2. If this group sees merit in this approach, we would probably organise formal approval in COMCIFS.
As far as I can see, Option (3) would only work in a non-clunky way for non-looped attributes which is fine for the particular case of item_type but is not extensible.
What I would like from this group is for us to consider the above options and for us to arrive at a preferred approach.
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________ ddlm-group mailing list firstname.lastname@example.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] Making ddl2 <-> ddlm translation a reality (James Hester)
- [ddlm-group] Making ddl2 <-> ddlm translation a reality (James Hester)
- Prev by Date: [ddlm-group] Making ddl2 <-> ddlm translation a reality
- Next by Date: Re: [ddlm-group] Making ddl2 <-> ddlm translation a reality
- Prev by thread: [ddlm-group] Making ddl2 <-> ddlm translation a reality
- Next by thread: Re: [ddlm-group] Making ddl2 <-> ddlm translation a reality