Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .

I'm not sure I understand the maintenance burden alluded to here.

I would also add that maintaining an alias list keyed by dictionary
name is an important exercise for the human reader of dictionaries,
who may (for example) be trying to work out how to upgrade software
with hard-coded datanames to a new standard.  The alias list also
fulfills a similar function to the dictionary history table by
tracking the evolution of a dataname - perhaps not essential for
programming tasks, but important in a wider scholarly sense.  So I
would not like to see the dictionary name dropped from the alias list.

On Thu, Jan 20, 2011 at 8:46 AM, Herbert J. Bernstein
<yaya@bernstein-plus-sons.com> wrote:
> Dear John,
>
>   The definition_id most certainly does not exhibit the tag
> style.  For example, there is no way to distinguish DDLm
> tag style from DDL2 or DDL2 tag style from context.  That
> is intentionally inherent in the design of DDLm.
>
>   As for defining a hypothetical URI, that can break,
> or each least time-out programs trying to get additional
> information about an aliased tag from that URI.  URIs
> should be for things that really exist on the web,
> not a substitute for a tag that really defines something
> different, in this case the style of tags.
>
>   We already do something very similar to this with
> alternate conformers and with NMR model numbers.  It
> really is a simply concept for organizing information
> that belongs in groups, in this case the group of
> DDL1 or DDL2 or DDLm or ... style tags.  It solves
> a very real problem for me with imgCIF.  It does
> not harm to anybody else.  If nobody uses it in
> another dictionary, it still would have been a useful
> addition to DDLm.
>
>   In the end, I suspect that both core and mmCIF DDLm
> dictionaries will be built this way, because it
> make it simpler and clearer and allows multi-purpose
> dictionaries to be self-contained and avoid the
> maintenance headache David spotted.
>
>   Having one tag to nominate a preferred alias tag
> by tag is quite a clerical burden.  Having one style
> to select is a lot less work.
>
>   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 Wed, 19 Jan 2011, Bollinger, John C wrote:
>
>>
>> On Wednesday, January 19, 2011 12:04 PM, Herbert J. Bernstein wrote:
>>>   That was very helpful.  You want to maintain one dictionary that will dynamically act as a DDL1, DDL2 or DDLm dictionary. Fair enough.  But then shouldn'e the information on what alias is intended for what style of output simply be in the alias tags.  It is not really a matter of which dictionary it come from, but of which of several alternate styles of tags it conforms to.
>>>
>>>   Right now the alias category has 2 tags,
>>>
>>>   _alias.definition_id
>>>   _alias.dictionary_uri
>>>
>>> We could both do what we need to do without conflicting if there were a third tag
>>>
>>>   _alias.tag_style
>>>
>>> which would simply be a character string, such as DDL1, DDL2, DDLm,
>>> my_new_style, ... which could be used to tie together the style of tags
>>> to be used for a particular dictionary use, both for validation of
>>> input and for generation of output.  If no particular style had been
>>> specified, the save frame name would win.  This would bring the data on
>>> which are DDL1 names and which are DDL2 names for the core values
>>> neatly together on one core dictionary without having to know if any
>>> other dictionaries were DDL1 style and which are DDL2 style.  The DDLm
>>> dictionary would have all the information right there and would not
>>> even need to refer to the older dictionaries on most cases to work with
>>> DDL1 and DDL2 data files.
>>
>> _alias.tag_style seems redundant to me.  For one thing,
>> _alias.definition_id will inherently exhibit the tag style.  Moreover,
>> the "tag style" in the DDL-version sense is both well known and
>> electronically available, given _alias.dictionary_uri, at least for
>> official and registered dictionaries.  A program that cared generically
>> about tag type could use either or both of those to determine it
>> dynamically while processing the dictionary.  Moreover, there is in
>> general no particular reason to expect not to find multiple aliases of
>> the same tag type, whether defined in the same or in different
>> dictionaries.
>>
>> If you want to select, for instance, Core data names vs. mmCIF data
>> names then then _alias.dictionary_uri gives you that directly.  It works
>> even among multiple alternative names for the same concept defined in
>> different dictionaries using the same data name convention.  Moderately
>> clever software could even make selection by dictionary URI work for
>> merged dictionaries, provided it was given information about the
>> constituent dictionaries.
>>
>> There does, however, appear to be a possible need for a tag by which to
>> nominate a preferred alias among several defined in the same external
>> dictionary.  The preference doesn't matter when reading CIF input, but
>> it does potentially matter when choosing a tag for output.  We could
>> rely on order of appearance in the alias list, but until now loop
>> packets have been order-independent.
>>
>>>   For my work, this would be just as effective as the import ... as ...
>>> or my method_alias suggestion in allowing me to use CIF1 tags that are
>>> >illegal under CIF2 without requiring us to allow those names as valid
>>> tags in DDLm dictionaries.
>>>
>>>   Could you accept _alias.tag_style, and perhaps allowing
>>> _alias.dictionary_uri to be omitted when not really needed?  This would
>>> be a big help >to me in then making a DDLm imgCIF dictionary that could
>>> not only replace the DDL2 dictionary, but could also, for the first
>>> time provide a DDL1 >version of all imgCIF tags.  I could even then
>>> automatically produce valid DDL1 and DDL2 dictionaries from the DDLm
>>> dictionary source, making thr >DDLm dictionary the only version that I
>>> would have to maintain.
>>
>> For this particular purpose, how about defining a URI to represent the
>> hypothetical DDL1 imgCIF dictionary, and using that with
>> _alias.dictionary_uri to achieve your objective?  The resulting
>> dictionary would even be more informative about the nature of the
>> aliases than a tag style could make it.  That approach would be no
>> harder to code for, as it simply substitutes one data name and set of
>> constants for another.
>>
>>
>> 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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links