[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: jwest@rcsb.rutgers.edu, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed)
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Sun, 23 Jan 2011 11:12:16 -0500
- In-Reply-To: <4D3C50BA.5010900@rcsb.rutgers.edu>
- 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><4D3C50BA.5010900@rcsb.rutgers.edu>
Dear John, These are tag groups, rather than category groups, but I can see that using the word group could be confusing. We have been through "style", "virtual dictionary" and "group", how about one of the following: mode ensemble set aggregation I don't care much about the name, but I really need the functionality Regards, Herbert At 11:00 AM -0500 1/23/11, John Westbrook wrote: >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 -- ===================================================== 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
Reply to: [list | sender only]
- 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)
- Re: [ddlm-group] DDLm aliases (subject changed) (John Westbrook)
- 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):