[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: [email protected], Group finalising DDLm and associated dictionaries <[email protected]>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed)
- From: "Herbert J. Bernstein" <[email protected]>
- Date: Sun, 23 Jan 2011 11:12:16 -0500
- In-Reply-To: <[email protected]>
- References: <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]>
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
>> [email protected]
>> =====================================================
>>
>> 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
>>> <[email protected]> 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
>>>>> <[email protected]> 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
>>>>>> [email protected]
>>>>>> =====================================================
>>>>>>
>>>>>> 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
>>>>>>> [email protected]
>>>>>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>>>>>
>>>>>> _______________________________________________
>>>>>> ddlm-group mailing list
>>>>>> [email protected]
>>>>>> 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
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> =====================================================
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>
>>
>> _______________________________________________
>> ddlm-group mailing list
>> [email protected]
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>_______________________________________________
>ddlm-group mailing list
>[email protected]
>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
[email protected]
=====================================================
_______________________________________________
ddlm-group mailing list
[email protected]
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):