[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] DDLm aliases (subject changed). .
- To: Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed). .
- From: "Herbert J. Bernstein" <email@example.com>
- Date: Wed, 26 Jan 2011 12:33:34 -0500
- In-Reply-To: <4D404DAA.firstname.lastname@example.org>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnbemail@example.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDE@SJMEMXMBS11.stjude.sjcrh.local> <4D404DAA.firstname.lastname@example.org>
OK, so we need to pick a non-conflicting name for the tag that gives the unifying identifier that will satisfy John W.'s concerns and James's concerns, but that will not preclude John B. and David's preference to allow the presentation to be unified with the xref_code. How about "ensemble_id". This is a distinct concept from the identifier of the dictionary itself, because one dictionary can contain multiple ensembles and one ensemble can span multiple dictionaries. Here is my modified version of John B.' proposal: 1) Deprecate _alias.dictionary_uri. 2) Add as a of subcategory of alias, alias_ensemble with the following tags: _alias_ensemble.definition_id a tag identifier belonging to an ensemble _alias_ensemble.ensemble_id a code identifying an ensemble of tags to which the tag belongs _alias_ensemble.xref_code All of these tags are members of the composite key of the sub category, so that it is possible to have a physical dictionary the same tag in multiple ensembles, or to break out this subcategory as a master index running over all tags alias giving both the physical dictionaries from which they are taken and and the ensembles to which they belong. 3) Add tag _alias.xref_code to the alias category _alias.xref_code specifies the physical dictionary from which the preferred definition of the tag alias has been taken, or is null if the current dictionary is the primary definer of the tag alias. This tag is the parent of _alias_ensemble.xref_code. There are some technical issues on use of the join mechanism, and which tags are keys, but they can be resolved if the flattened version is truly desired. 4) Add tag: _alias.deprecated: Specifies whether use of the alias is deprecated. _type.purpose State _type.container Single _type.contents YesorNo 5) Modify the definition of _dictionary_xref.format by changing its _type.contents attribute to "Code". 6) Deprecate _definition.xref_code (its purpose will be served via the alias mechanism) Note that I say "deprecate" rather than remove because the existing tags have been public for more than 3 years. None of this is "brand new". At 11:36 AM -0500 1/26/11, David Brown wrote: >Now that we seem to have some agreement in principle on how aliases >will be structured and used, could Herbert and John B (or either of >them) provide us with a unified proposal for alias and xref DDLm >code? In these matters the Devil is always in the details, and only >with a draft code is it possible to see what will and what won't >work, Eventually we will need to approve the change to the DDLm, >but unless we have a specific proposal, nothing will get done and I >will be no further ahead in generating DDLm compatible CIF >dictionaries. > >I look forward to the opportunity of evaluating a complete and >coherent proposal. > >David > > > > >Bollinger, John C wrote: > >>On Saturday, January 22, 2011 7:19 PM, James Hester wrote: >> >>>I believe this discussion arose out of a misconception, but will end >>>up producing something useful. First of all, we should be clear that >>>the only well-defined meaning of "DDL1/DDL2/DDLm tag" is "a dataname >>>defined in a dictionary written using DDL1/DDL2/DDLm". Note in >>>particular that all DDL1 and DDL2 tags are consistent with CIF1 >>>syntax, and writing a DDLm dictionary with CIF1-compatible tags is >>>also not troublesome. >>> >> >> >>I take that to mean something like "any CIF1-compatible tag can be >>defined in a DDLm dictionary," which is true. Of course, tags that >>do not comply with dREL conventions cannot be referenced by >>methods, at least not directly. Depending on the semantics of >>ALIAS (or some similar mechanism for associating data names), >>however, we could make it possible to reference them indirectly >>through a dREL-compatible name. It might work something like this: >> >>==== >>save_diffrn_standards.decay_percent >> _definition.id '_diffrn_standards.decay_percent' >> >>[...] >> >> loop_ >> _alias.xref_code >> _alias.definition_id >> _alias.dictionary_version >> _alias.deprecated >> . '_diffrn_standards_decay_%' . yes >> >>save_ >>==== >> >>The key there is use of an _alias.xref_code value that signifies a >>data name logically defined in the same dictionary, rather than in >>an external one. (The example uses . for that purpose, but there >>are alternatives.) The result would be that >>_diffrn_standards.decay_percent and _diffrn_standards_decay_% are >>aliased in roughly the same sense as identifiers in a programming >>language can be. >> >>We could go even further by saying that an alias into the current >>dictionary does not require (perhaps should not have) a separate >>definition from that of the item to which it is aliased. That way >>opportunities for inconsistency within a single dictionary could be >>foreclosed. >> >> >>> This means that it is simple to write a DDLm >>>imgCIF or coreCIF dictionary where datanames satisfy CIF1 syntax >>>rules. A datafile in CIF1 syntax can then refer to the DDLm >>>dictionary as the reference for the datanames. >>> >>>On the other hand, it is not possible to write a DDLm dictionary that >>>can serve as a DDL1 or DDL2 dictionary, because the DDL languages are >>>different and incompatible. >>> >>> Simply rewriting the tags does not change >>>the fact that the tag is defined in a DDLm dictionary and therefore is >>>interpretable using DDLm semantics *only*. The concept of a virtual >>>dictionary generated from a "master" DDLm dictionary but with >>>DDLm/DDL1/DDL2 flavours is therefore meaningless and should be >>>abandoned. >>> >> >> >>I don't yet see what validity constraints can be expressed using >>DDL1 or DDL2 that cannot be expressed using DDLm, or what validity >>constraints are inherently implied by DDLm definitions that are not >>implied by DDL1 or DDL2 definitions. Absent distinctions these >>kinds, it's not clear to me why an existing DDL1 or DDL2 dictionary >>could not be rewritten in DDLm format. Indeed, I take it as an >>important objective for DDLm that there be no obstacle to such >>rewriting. >> >>What else does it mean, then, that a DDLm dictionary cannot serve >>as a DDL1 or DDL2 dictionary? >> >>Suppose that we perform such a rewrite from (say) a DDL1 >>dictionary, D1, to a DDLm dictionary, Dm. As part of this process >>we record for each defined name an alias to the corresponding D1 >>definition, even though the two data names are the same. By >>assumption, Dm is equivalent to D1, at least with respect to the >>CIFs it validates. >> >>Now suppose that we create a new dictionary, Dm', based on all the >>aliases defined in Dm. For each alias we write a definition for >>the aliased name by copying the Dm definition in which the alias >>appears, except substituting the alias data name for the defined >>data name. Because all the aliased data names are the same as the >>associated defined names, however, Dm' is identical to Dm. Thus >>it, too, is equivalent to D1 for validation purposes. >> >>But what if we create a third DDLm dictionary, Dm'', by adding some >>definitions having no aliases to D1, by changing some of Dm's >>defined data names without otherwise altering their definitions, >>and by adding aliases into some other dictionary to some of the >>defined items. Dm'' is *not* equivalent to D1, at least because it >>will accept some data names that D1 does not, and it will reject >>some data names that D1 accepts. But if we apply the same >>procedure described in the previous paragraph to generate a new >>dictionary from the aliases defined in Dm'', selecting only those >>aliasing into D1 and stripping aliases to other dictionaries from >>the result, then we regenerate Dm', which is equivalent to D1 for >>validation purposes. >> >>Wouldn't it then be reasonable to describe D1 as a virtual DDL1 >>dictionary resident in or generated from Dm''? >> >> >>Now consider a CIF originally written and valid against the DDL2 >>mmCIF dictionary, and a DDLm dictionary containing mmCIF as a >>virtual dictionary. We can use dREL methods to generate additional >>values, and we can use the defined aliases to map those values to >>their mmCIF data names, if they have any. We can test whether >>those data that have corresponding mmCIF names are collectively >>valid against the virtual mmCIF dictionary, we can determine what >>other data may be needed for validity, and we can look for dREL >>methods in the host dictionary to generate any such. After all >>data manipulations are complete, we can output the data using the >>mmCIF data names, omitting any data not defined by mmCIF, and >>knowing (if we wish) whether the resulting data set is valid >>against mmCIF. These are useful things to do, and they require >>little that DDLm does not already provide. >> >> >>I do not argue that converting a CIF that is valid against a host >>DDLm dictionary to a CIF valid against some virtual dictionary >>resident in the host would be as simple as merely translating data >>names. If the host properly embeds the virtual dictionary as >>described above, however, then it's not obvious to me that it would >>not be. I shall have to think on that. >> >> >>It is a different question whether a single DDLm dictionary can >>simultaneously provide the semantics of both a DDL1 dictionary and >>an overlapping DDL2 dictionary, as Herbert proposes. David also >>expressed doubts about the feasibility of that proposition. >>Surely, however, the prospects at least depend on the contents of >>the DDL1 and DDL2 dictionaries that are proposed to be co-expressed >>this way. I can easily produce a trivial example that works, and >>Herbert is by far the best judge of how well imgCIF is suited to >>such treatment. >> >> >>This is already quite long, so I will respond separately to the >>other part of James's comments. >> >> >>Regards, >> >>John >> >>-- >>John C. Bollinger, Ph.D. >>Department of Structural Biology >>St. Jude Children's Research Hospital >> >> >>Email Disclaimer: >><http://www.stjude.org/emaildisclaimer>www.stjude.org/emaildisclaimer >> >>_______________________________________________ >>ddlm-group mailing list >><mailto:email@example.com>firstname.lastname@example.org >><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group >> > > > >Attachment converted: Macintosh HD:idbrown 90.vcf (TEXT/ttxt) (0032C487) >_______________________________________________ >ddlm-group mailing list >email@example.com >http://scripts.iucr.org/mailman/listinfo/ddlm-group -- ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 firstname.lastname@example.org ===================================================== _______________________________________________ ddlm-group mailing list email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] DDLm aliases (subject changed). .. . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed). . (David Brown)
- Prev by Date: Re: [ddlm-group] DDLm aliases (subject changed). .
- Next by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .
- Prev by thread: Re: [ddlm-group] DDLm aliases (subject changed). .
- Next by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .