[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 <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed)
- From: John Westbrook <jwest@rcsb.rutgers.edu>
- Date: Sun, 23 Jan 2011 11:00:58 -0500
- In-Reply-To: <alpine.BSF.2.00.1101230722100.35756@epsilon.pair.com>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnb-i@mail.gmail.com> <a06240800c96133786773@192.168.2.102> <AANLkTikxmqNkwjZ21FMVRM7gXUFGR258wPmJjL75RR3V@mail.gmail.com><alpine.BSF.2.00.1101230722100.35756@epsilon.pair.com>
Hi Herbert, Category groups are an organizational tool for dictionaries in DDL2. We usually describe this as a chaptering mechanism but it also provides a mechanism to construct a hierarchy of category relationships which is not tied to the underlying parent-child/foreign key relationships. Group membership as well as subcategory membership are explicitly supported as part of the DDL. This is used as a means to select sets of extensions, categories for particular experimental methods, content areas within methods, and the like. I would prefer it to remain this way rather than turn this into parsing directives with comments. Perhaps I misunderstand your suggestion with the '###' directives. Regards, John On 1/23/11 8:18 AM, Herbert J. Bernstein wrote: > Dear James, > > In my case the dictionaries to be specified with the grouping tag to > validate an imgCIF file against DDL2 would be a new DDLm imgCIF > dictionary plus either a new DDLm mmCIF dictionary, whenever that is > ready, or the existing DDL2 mmCIF dictionary. > > To validate against DDLm, the best choice would, of course, be a new > DDLm imgCIF dictionary plus a new DDLm mmCIF dictionary. I am not > certain if using an existing DDL2 mmCIF dictionary will or will not work > in that case. It depends on what changes John W. has in mind in the move > of mmCIF to DDLm. > > For a more self-contained dictionary, such as, say the core, I am not > certain if it will need to specify any dictionaries other than itself, > but that, of course depends on how many pieces it is broken up into. > > As for rules for a grouping, as I said, I seem to be seeing most of the > basic rules for category management from DDL2 in DDLm. The differences > seem to be small, mainly a matter of DDLm being a bit more fussy about > things such as unrolling a catgeory or not. The lexical scan issues we > have introduced are not themselves in the dictionary. Inasmuch as the > category management issue difference seem small and the lexical > differences have to be handled by parameters in the lexer, to start, I > will handle it with flags in the code, as I have done in the past for > DDL1 versus DDL2 differences in CIFtbx and CBFlib. > > What happens after that depends on how well it works and, what, if > anything, people feel needs to be adjusted in the DDL to handle such > differences better than by flags in the code. > > As for the archived versus current distinction -- I have to deal > with continuing additions to and changes in imgCIF, so the > imgCIF dictionary will continue to evolve, and I would much > rather maintain one base the reference dictionary in DDLm than > having to maintain 2 parallel dictionaries now (DDLm and DDL2) > and 3 parallel dictionaries shortly (DDLm, DDL2 and DDL1). > To use existing software that is out in the hands of users, > I will have to provide updated DDL2 dictionaries, but with > the grouping tags, I expect to be able to use a slightly augmented > DDLm dictionary as a base for automatically an generated DDL2 > dictionary -- and that is actually the first use I will be > making of the grouping tags. > > I doubt if users will want to modify existing data files to > specify both a dictionary and a group. Indeed I doubt they > will take the effort to even specify the dictionary, but > it cannot hurt to encourage them to do so. For those who > decline, I will handle it with program parameters. For > those who are willing, I would suggest we add a place for > grouping in the initial comments. Right now we put the > CBF dictionary version in the initial "magic number" comment: > > ###CBF: VERSION 1.6 > > we could add the grouping(s) there as in > > ###CBF: VERSION 2.0 GROUP DDL2 > or > ###CBF: VERSION 2.0 GROUP DDL1 > > It does not make much sense to specify this in terms if a > group other than DDL2 or DDL1 because that is precisely the > distinction we are trying to convey, but, yes, for test > versions we can use > > ###CBF:VERSION 2.0 GROUP BplusSDDL2TRIAL_28FEB11 > > or somesuch to avoid confusion with something that is > not yet official. Ultimately, the DDL1/DDL2/DDLm groupings > are liekly to be the most intutively clear and useful ones. > > Now we just need to settle the issue of do we or do we not > put this in with the alias items or do we put it by itself, > and I can get started on setting up a DDLm imgCIF dictionary > for DDL2 and DDL1 dictionary generation. > > So -- how do other people feel about conflating the grouping with > the xfer code? I can live with it either way. > > Regards, > Herbert > > ===================================================== > Herbert J. Bernstein, Professor of Computer Science > Dowling College, Kramer Science Center, KSC 121 > Idle Hour Blvd, Oakdale, NY, 11769 > > +1-631-244-3035 > yaya@dowling.edu > ===================================================== > > On Sun, 23 Jan 2011, James Hester wrote: > >> Hi Herbert: I think we are agreed that the 'grouping' attribute is >> useful, but disagree on how to use it, so there is probably enough >> agreement within this group to move forward with an addition to DDLm >> and defer discussion on exactly what enumerated values it can take. I >> would obviously prefer that this grouping tag not take values of >> DDL2/DDL1/DDLm until you have shown that these groupings are >> meaningful, probably through a demonstration. Incidentally, are you >> (Herbert) happy with the concept that a CIF datafile would specify >> both a dictionary and a 'group', which would be the basis for software >> to run validation checks? >> >> What DDL2 rules would you validate using a DDLm dictionary and DDL2 >> grouping tag? This seems to be where we disagree. >> >> Yes, DDLm dictionaries can validate all *archived* files with respect >> to the *DDLm* data model, and those archived files can thereby take >> advantage of new DDLm features. There seems little to no point, >> however, using a DDLm file to validate an archived file against a >> pseudo-DDL2 dictionary derived from a DDLm dictionary (even if it were >> possible), because if you wanted to validate against DDL2 you would >> just use current tools and the DDL2 dictionary the archived file was >> originally generated with respect to. If you plan to generate new >> (not archived) data files that use datanames derived from a DDL2 >> perspective of a DDLm dictionary instead of just the DDLm dictionary, >> one has to ask, why? You can generate perfectly legitimate CIF1 >> syntax datafiles that validate against a DDLm dictionary, if syntax is >> the concern. >> >> In any case, I won't argue against the DDL1/2/m grouping tag if you >> can come up with a nice demonstration. >> >> On Sun, Jan 23, 2011 at 1:39 PM, Herbert J. Bernstein >> <yaya@bernstein-plus-sons.com> wrote: >>> Dear Colleagues, >>> >>> I can find almost nothing in James side comments about DDLm versus >>> DDL2 versus DDL1 with which I agree. I really do believe that >>> I will be able to write a single DDLm dictionary and supporting >>> software that will be able to validate current imgCIF files against >>> DDL2 rules, a CIF2 imgCIF file against DDLm rules, and, hopefully >>> a new DDL1 imgCIF file against DDL1 rules. Thus far I have not >>> found anything in DDLm that will prevent a DDLm dictionary with >>> a few added tags (such as something of the sort David and I have >>> proposed) from carrying all the information needed for this purpose, >>> but I am more familiar with DDL2 than with DDL1. Perhaps James >>> is referring to some inherent conflict between DDLm and DDL1, >>> but I really thought the intent of DDLm was to allow it to become >>> the dictionary definition language for dictionaries that could >>> be used to validate _all_ archived DDL1 and DDL2 data files. >>> >>> Certainly, in using that dictionary for DDL2 validation, I will >>> be using it in a way that is not consistent with all DDLm rules, e.g. >>> by not honoring the list restriction-- but that is precisely the point. >>> Most of what is in DDLm looks very similar to what is already in >>> DDL2, so that specialization look to me to very doable, and DDLm >>> seems to have support of the major concepts, such as the list flag >>> from DDL1. >>> >>> So right now, I have no idea what misconception James is referring to, >>> but does it really matter? I will either succeed, or I will fail, >>> but the additions I have asked for will not do any harm to those >>> who do not use them. >>> >>> I can cope either with David's and John's approach of >>> putting the grouping information in with the alias information, >>> or with James wish to go back to my original proposal to >>> have the group information separated out. I just need a >>> way to organize the grouping relationship among stylistically >>> different tags with the same meanings. If you all prefer, >>> I can just work up an imgCIF DDLm dictionary using >>> a modified DDLm with a few added tags using the prefix mechanism. >>> That might help in understanding the issues I am looking at >>> without trespassing on what is or is not formally part of DDLm. >>> For the moment I would put the mapping information into >>> a separate category, but make it joinable to alias, so it >>> can be used either the way John B. has proposed or separately >>> as James has proposed. The only point that seems to be a >>> real sticking point is whether the grouping identifier should >>> be conflated with the xref code or not. James seem to feel >>> very strongly that it should be distinct. John B. argued very >>> strongly that the grouping identifier had to be conflated with >>> the xref code. I think it is clearer to make it distinct, but >>> that, other than being a little confusing, John B.'s approach >>> does no real harm. >>> >>> What do other people think about conflating the grouping >>> identifier with the xref code? I'll go along with whatever >>> the majority chooses on that issue. >>> >>> Regards, >>> Herbert >>> >>> >>> At 12:19 PM +1100 1/23/11, 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. 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. >>>> >>>> Nevertheless, an important use case for rewriting tags has been >>>> identified by Herbert: transitioning from the use of tags with a local >>>> identifier to those using a "global" (ie no namespace) identifier. >>>> With something like the tag_style proposal in place, the DDLm >>>> dictionary writer can write the dictionary as if it were a global >>>> dictionary (this may particularly help with dREL methods) and include >>>> a "local" tag_style which gives an alternate dataname that includes >>>> the local section. In tandem with this, any datafiles containing >>>> datanames defined in this local dictionary would use the audit >>>> category to specify both a dictionary *and* a style. If only "local" >>>> datanames are in use, then the style would be "local"; if the >>>> dictionary becomes a standard, no rewriting is necessary, and >>>> datafiles can now just use the default value of style ("standard"). I >>>> think this is a compelling use case, but still have to think through >>>> how dictionary merging will work. >>>> >>>> The second future use case is that of datanames in a DDLm dictionary >>>> containing non-ASCII code points. These, and only these, DDLm >>>> datanames are not CIF1-compatible. A style could therefore be added >>>> giving the "ASCII" equivalent dataname. >>>> >>>> As John W was suggesting (at least reading between the lines), the >>>> above two use cases are semantically distinct from aliases. Aliases >>>> point to definitions in a dictionary and state that the aliased >>>> dataname is the equivalent dataname in a different dictionary. As the >>>> dictionary DDL languages may be different, there are no explicit >>>> guarantees that all semantic properties (e.g. category relationships) >>>> can be preserved in making this translation. On the other hand, the >>>> tag_style use is a simple rewriting of the dataname preserving perfect >>>> semantic identity. >>>> >>>> Therefore, I believe that the tag_style tag should not be conflated >>>> with aliases, but should be created in a separate category. Note also >>>> that "local" and "ASCII" are not mutually exclusive designations, so >>>> some further work is necessary to get everything to work together >>>> properly (e.g. how do I transition between "local + ASCII", "local", >>>> "ASCII" and "standard+ASCII"?). I also think that "style" is probably >>>> not the best terminology to use - perhaps "presentation" or "view" >>>> would be better. >>>> >>>> I have so far no objection in principle to normalising out the >>>> dictionary using dictionary_xref as John has proposed. >>>> >>>> On Sat, Jan 22, 2011 at 7:47 AM, Herbert J. Bernstein >>>> <yaya@bernstein-plus-sons.com> wrote: >>>>> This can be made to work, but for my uses, there are >>>>> some minor issues: >>>>> >>>>> 1. I will be grouping the primary DDLm tag. With the >>>>> _definition.xref_code removed, the primary DDLm tag >>>>> will have to be aliased; and >>>>> >>>>> 2. With multiple xref codes for a given tag (e.g. >>>>> DDL2 and DDLm), it would be more appropriate to >>>>> normalize and put the tags and xref codes into >>>>> a sub-category, rather than to keep repeating the >>>>> same tag. This would have the advantage of allowing >>>>> the alias category to return to a non-compound key >>>>> and would also allow all the grouping of >>>>> tags in a dictionary to be gathered on a separate >>>>> block, if desired. >>>>> >>>>> For these reasons, I suggest >>>>> >>>>> 1. Leave _alias.dictionary_uri, but deprecate it in >>>>> favor of: >>>>> >>>>> 2. Create an ALIAS_XREF category with the >>>>> following tags, forming a composite key >>>>> >>>>> _alias_group.definition_id >>>>> a tag identifier belonging to a group >>>>> _alias_group.xref_code >>>>> a code identifying a real or virtual dictionary >>>>> or other logical groups of tags to which the tag >>>>> belongs >>>>> >>>>> The other tags that John proposes for David's uses >>>>> actually fit better in terms of normalization in this sub- >>>>> category, than on the top level, but that is a decision >>>>> for David to make. I am happy either way. >>>> > >>>>> The addition to the ddl dictionary would be: >>>>> >>>>> save_ALIAS_XREF >>>>> >>>>> _definition.id alias_xref >>>>> _definition.scope Category >>>>> _definition.class List >>>>> _definition.update 2011-01-21 >>>>> ; >>>>> The attributes used to specify the actual dictionary, >>>>> virtual dictionary, or other logical grouping of >>>>> tags indicated by an xref code to which a given tag belong. >>>>> >>>>> The default xref code under which all tags for which >>>>> no xref group is defined is the one specified by >>>>> a null value. >>>>> >>>>> ; >>>>> _category.parent_id alias >>>>> _category_key.primitive ['_alias_xref.definition_id', >>>>> '_alias_xref.xref_code'] >>>>> save_ >>>>> >>>>> save_alias_xref.definition_id >>>>> _definition.id '_alias_xref.definition_id' >>>>> _definition.class Attribute >>>>> _definition.update 2011-01-21 >>>>> _description.text >>>>> ; >>>>> Identifier tag of a definition associated with >>>>> an xref code by which to group this tag with >>>>> other tags. A single tags may be associated >>>>> with multiple xref codes. An xref code does >>>>> not have to be associated with a particular >>>>> dictionary, nor with a particular DDL format. >>>>> >>>>> Note that the tag does not have to be a valid >>>>> tag under DDLm tag construction rules, but >>>>> it should be a valid tag under the rules of >>>>> some DDL. >>>>> ; >>>>> _name.category_id alias_xref >>>>> _name.object_id definition_id >>>>> _type.purpose Key >>>>> _type.container Single >>>>> _type.contents Code >>>>> save_ >>>>> >>>>> save_alias_xref.xref_code >>>>> _definition.id '_alias_xref.xref_code' >>>>> _definition.class Attribute >>>>> _definition.update 2011-01-21 >>>>> _description.text >>>>> ; >>>>> A code identifying the actual dictionary, >>>>> virtual dictionary or other logical grouping >>>>> to which the identifier tag belongs. >>>>> ; >>>>> _name.category_id alias_xref >>>>> _name.object_id code >>>>> _type.purpose Key >>>>> _type.container Single >>>> > _type.contents Code >>>>> save_ >>>>> >>>>> >>>>> >>>>> ===================================================== >>>>> Herbert J. Bernstein, Professor of Computer Science >>>>> Dowling College, Kramer Science Center, KSC 121 >>>>> Idle Hour Blvd, Oakdale, NY, 11769 >>>>> >>>>> +1-631-244-3035 >>>>> yaya@dowling.edu >>>>> ===================================================== >>>>> >>>>> On Fri, 21 Jan 2011, Bollinger, John C wrote: >>>>> >>>>>> >>>>>> On Friday, January 21, 2011 8:57 AM, David Brown wrote: >>>>>> [...] >>>>>>> I would like to know exactly what I am voting on. There seems >>>>>>> to be >>>>>>> general agreement on the information that is needed for an >>>>>>> alias, the >>>>>>> only dispute is the format in which it will appear. If the various >>>>>>> pieces of information I listed each had their own item, this >>>>>>> would be >>>>>>> agreeable and we could delegate someone to come up with the >>>>>>> requisit >>>>>>> DDLm save frames, but if this information is to be included, >>>>>>> explicitly >>>>>>> or implicitly, in a smaller number of items, then I would like >>>>>>> to see >>>>>>> the definitions and descriptions so that I could understand how >>>>>>> each >>>>>>> piece of information would be retrieved. John B, can you supply us >>>>>>> with an example of what your normalized item(s) would look like? >>>>>> >>>>>> >>>>>> Indeed, here is the formal proposal I promised, at the end of >>>>>> which is >>>>>> an example: >>>>>> >>>>>> >>>>>> Proposal: Extended Alias Attributes >>>>>> =================================== >>>>>> >>>>>> Introduction / Rationale >>>>>> ------------------------ >>>>>> >>>>>> This proposal aims primarily to provide all the ALIAS attributes >>>>>> that several members of this group have recently agreed are needed >>>>>> (at least in principle). However, attributes that are properties >>>>>> of dictionaries rather than of individual data names are >>>>>> normalized out of the ALIAS category and into the DICTIONARY_XREF >>>>>> category. The description of the DICTIONARY_XREF category is >>>>>> slightly modified to be explicitly consistent with this usage and >>>>>> with the concept of referencing logical dictionaries that have no >>>>>> independent physical manifestation. >>>>>> >>>>>> >>>>>> Proposed Actions >>>>>> ---------------- >>>>>> >>>>>> 1) Replace _alias.dictionary_uri with: >>>>>> >>>>>> _alias.xref_code: Specifies a code that identifies the logical or >>>>>> physical dictionary in which the alias is defined. This serves to >>>>>> categorize and fully identify the alias. >>>> >> _type.purpose Identify >>>>>> _type.container Single >>>>>> _type.contents Code >>>>>> >>>>>> 2) Add these attributes: >>>>>> >>>>>> _alias.dictionary_version: Specifies the first version of the >>>>>> dictionary identified by _alias.xref_code that defines the alias. >>>>>> _type.purpose Identify >>>>>> _type.container Single >>>>>> _type.contents Code >>>>>> >>>>>> _alias.deprecated: Specifies whether use of the alias is deprecated. >>>>>> _type.purpose State >>>>>> _type.container Single >>>>>> _type.contents YesorNo >>>>>> >>>>>> 3) In the ALIAS category, replace attribute _category_key.generic >>>>>> with: >>>>>> _category_key.primitive [ '_alias.xref_code' >>>>>> '_alias.definition_id' ] >>>>>> >>>>>> 4) Modify the definition of _dictionary_xref.format by changing its >>>>>> _type.contents attribute to "Code". >>>>>> >>>>>> 5) Remove _definition.xref_code (its purpose will be served via the >>>>>> alias mechanism) >>>>>> >>>>>> 6) Modify the description of the DICTIONARY_XREF category to: "The >>>>>> DICTIONARY_XREF attributes identify and describe logical or physical >>>>>> dictionaries to which items in the current dictionary are >>>>>> cross-referenced using the _alias.xref_code attribute." >>>>>> >>>>>> >>>>>> Comments >>>>>> -------- >>>>>> >>>>>> Here is the resulting correspondence between DDLm data names and >>>>>> David's >>>>>> list of alias attributes: >>>>>> >>>>>> "The tag" -> _alias.definition_id (unchanged by this proposal) >>>>>> >>>>>> "the dictionary in which it appears" -> a row/instance of >>>>>> DICTIONARY_XREF, identified by _alias.xref_code (added by this >>>>>> proposal) >>>>>> >>>>>> "the version of this dictionary" -> _alias.dictionary_version >>>>>> (added by >>>>>> this proposal) >>>>>> >>>>>> "the DDL in which the dictionary is written" -> >>>>>> _dictionary_xref.format >>>>>> (type attributes modified by this proposal) >>>>>> >>>>>> "a flag to indicate whether the dataname is deprecated" -> >>>>>> _alias.deprecated (added by this proposal) >>>> >> >>>>>> "a pointer to where the named dictionary can be found" -> >>>>>> _dictionary_xref.uri (unchanged by this proposal) >>>>>> >>>>>> >>>>>> Although this proposal chooses the existing DICTIONARY_XREF >>>>>> category as >>>>>> the normalized location for alias attributes that depend only on >>>>>> dictionary, it would also be possible to instead introduce a new, >>>>>> parallel category for this purpose. If the _definition.xref_code is >>>>>> merged into the alias feature as I propose, however, then >>>>>> DICTIONARY_XREF no longer has any other purpose. On the other >>>>>> hand, it >>>>>> is not essential to drop _definition.xref_code. >>>>>> >>>>>> As in my previous proposal concerning _alias.dictionary_uri, the >>>>>> key for >>>>>> the ALIAS category is expended to a compound one containing the >>>>>> dictionary identifier and the data name. This allows one data >>>>>> name's >>>>>> appearances in multiple dictionaries all to be aliased to the same >>>>>> defined name, without implying that all possible definitions of >>>>>> the name >>>>>> are aliased. Essentially, it scopes the alias to the dictionary in >>>>>> which it appears. DDL2's similar ITEM_ALIASES category is keyed not >>>>>> only to name and dictionary identifier, but also to dictionary >>>>>> version; >>>>>> the last seems needless, even in DDL2, because we can assume that >>>>>> once >>>>>> introduced into a dictionary, data names are not removed or >>>>>> incompatibly >>>>>> changed. >>>>>> >>>>>> The type attributes of _dictionary.xref_format are changed so >>>>>> that this >>>>>> attribute represents a computer-interpretable code describing at >>>>>> least >>>>>> the DDL compliance level of the referenced dictionary. Allowed >>>>>> values >>>>>> could be defined so that they encompass other information as >>>>>> well, very >>>>>> much like the proposed tag_style might do. It might be desirable >>>>>> for >>>>>> DDLm to enumerate allowed values for this attribute, but it would be >>>>>> more flexible to have an external register, such as Herbert >>>>>> proposed for >>>>>> tag_style. I presently take no position on the best course in that >>>>>> regard, but this proposal does not provide enumerated values. >>>>>> >>>>>> This proposal is offered for comment. Although I would be >>>>>> willing to >>>>>> have a vote on it as it stands, it could likely be improved. I >>>>>> am open >>>>>> to changing some of the details if that will contribute to broader >>>>>> acceptance. >>>>>> >>>>>> >>>>>> Example >>>>>> ------- >>>>>> >>>>>> loop_ >>>> >> _dictionary_xref.code >>>>>> _dictionary_xref.date >>>>>> _dictionary_xref.format >>>>>> _dictionary_xref.name >>>>>> _dictionary_xref.uri >>>>>> core '2010-Jun-29' DDL1 cif_core.dic >>>>>> ftp://ftp.iucr.org/pub/cif_core.dic >>>>>> mmcif '2005-Jun-27' DDL2 mmcif_std.dic >>>>>> ftp://ftp.iucr.org/pub/cif_mm.dic >>>>>> >>>>>> [...] >>>>>> >>>>>> save_diffrn_standards.decay_percent >>>>>> _definition.id '_diffrn_standards.decay_percent' >>>>>> >>>>>> [...] >>>>>> >>>>>> loop_ >>>>>> _alias.xref_code >>>>>> _alias.definition_id >>>>>> _alias.dictionary_version >>>>>> _alias.deprecated >>>>>> core '_diffrn_standards_decay_%' . no >>>>>> mmcif '_diffrn_standards.decay_%' . no >>>>>> >>>>>> save_ >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> John >>>>>> >>>>>> -- >>>>>> John C. Bollinger, Ph.D. >>>>>> Department of Structural Biology >>>>>> St. Jude Children's Research Hospital >>>>>> >>>>>> >>>>>> Email Disclaimer: www.stjude.org/emaildisclaimer >>>>>> >>>>>> _______________________________________________ >>>>>> ddlm-group mailing list >>>>>> ddlm-group@iucr.org >>>>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group >>>>>> >>>>> _______________________________________________ >>>>> ddlm-group mailing list >>>>> ddlm-group@iucr.org >>>>> http://scripts.iucr.org/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://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 >>> yaya@dowling.edu >>> ===================================================== >>> _______________________________________________ >>> ddlm-group mailing list >>> ddlm-group@iucr.org >>> http://scripts.iucr.org/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://scripts.iucr.org/mailman/listinfo/ddlm-group >> > > > _______________________________________________ > ddlm-group mailing list > ddlm-group@iucr.org > http://scripts.iucr.org/mailman/listinfo/ddlm-group _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] DDLm aliases (subject changed) (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed) (Herbert J. Bernstein)
- 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)
- Index(es):