Discussion List Archives

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

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

Dear James,

   I hope you like what David and I have proposed.  It
solves some practical problems in working with DDLm
in a DDL1 and DDL2 context, with the "noble" goal
of consolidating DDL1, DDL2 and DDLm dictionaries
into one DDLm dictionary, helping to speed the
transition to DDLm and reducing transitional dictionary
maintenance.

   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 Fri, 21 Jan 2011, James Hester wrote:

> I'm still digesting the last few emails and running a complex
> experiment so won't be ready to vote on anything for a few days.  I
> need to get clear in my mind the link between the proposal and the new
> functionality that it makes available, so bear with any questions as
> they turn up in the next few days.  I'm not particularly for or
> against it, indeed once I understand it I may well be  enthusiastic.
>
> On Fri, Jan 21, 2011 at 12:53 PM, Herbert J. Bernstein
> <yaya@bernstein-plus-sons.com> wrote:
>> Dear John B.
>>
>>   You seem to have agreed to everything except calling the necessary
>> addition tag a tag_style.  You want to call it a virtual_dictionary_id.
>> If the others agree with you on that naming change, I can live with that.
>> That leaves the only point of disagreement your idea of overloading that
>> concept onto the dictionary_uri. I object to that as being pointlessly
>> confusing, but if a majority prefers to overload a virtual_dictionary_id
>> which is simply a text string onto the URI type, I'll accept that.  I need
>> the functionality.  It everybody else want to call the relevant tag by
>> some other name, I can cope, but I really want a recorded vote on this.
>> I am hoping a majority will prefer clarity.
>>
>> So we now have two small points to vote on:
>>
>> 1.  Should the new tag be
>>   _alias.tag_style
>> or
>>   _alias.virtual_dictionary_id
>>
>> 2.  Instead of one of the above two tags, such the
>>   _alias.dictionary_uri
>> be overloaded with the non-URI use of the above
>> two tags?
>>
>> 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 Thu, 20 Jan 2011, Bollinger, John C wrote:
>>
>>> On Thursday, January 20, 2011 2:10 PM, Herbert J. Bernstein wrote:
>>>>   The existing alias mechanism has been used in the past to carry actual
>>>> information about tags from entry to entry and dictionary to dictionary,
>>>> allowing one side or the other of such a definition to be less complete
>>>> than it might otherwise have been, but also creating the sort of conflicts
>>>> noted.
>>>
>>>
>>> That seems an excellent reason for DDL2 software and dictionaries to not have used aliases in such a manner.  I see nothing in their DDL2 definition that that suggests such use would be appropriate, but at this point that's moot.  It sounds like you might join me in asserting that the move up to DDLm provides an excellent opportunity to make a clean break from that practice, consistent with the alias usage for which I have been arguing.
>>>
>>>
>>>>  Any software aside, it is certainly confusing to users of the
>>>> actual dictionaries to have such conflicting information around.  Just
>>>> think of this as going back to Codd and trying to make sure we only have
>>>> to update our data in one place and not several. It reduces the chance of
>>>> error to gather the information about a group of tags with the same
>>>> meaning, but different names in one place.
>>>
>>>
>>> I wholly favor that proposition, and I have never argued against it.  I'm having trouble determining why you keep asserting otherwise.  Please cite some comments of mine that you have taken as advocating something else, so that I can set the record straight.
>>>
>>>
>>>>   As David and John W. note, there are important differences in data file
>>>> construction rules, dare I say "styles" for DDL1, DDL2 and DDLm
>>>> dictionary-based data files.
>>>
>>>
>>> Acknowledged and agreed.  You have previously remarked, however, that the proposed style tag was intended to serve a much more generic purpose than identifying the DDL compliance of the dictionary from which an alias was drawn.  If you are now interested in limiting the concept to DDL compliance then I think we can come to an agreement, perhaps based on the inclusion of DDL compliance in David's list of needed alias attributes.
>>>
>>>
>>>>  However, once we have a tag-by-tag style
>>>> identification so we get the right tags, there is also no reason we cannot
>>>> give our validators and writers knowledge of which of the several over-all
>>>> styles we are trying to conform to, even the ever troubling difference in
>>>> approach as to what can and cannot be looped, and whether the use of the
>>>> period for category identification is mandatory (DDL2), optional (DDLm) or
>>>> not normally used (DDL1)
>>>
>>>
>>> You have agreed, as I understood you, that DDL compliance level is not sufficient for most purposes in this area.  That is especially the case for writers.  For most purposes one really wants to specify compliance with a specific logical *dictionary*.  Such dictionaries need not have a physical representation independent of the DDLm dictionary that refers to them, and with David's separation of access URI from dictionary identifier, those that do not have an independent representation can easily be recognized.  I'm still waiting for a use case for style_tag that is not well addressed by using (logical) dictionaries as the unit of alias grouping.
>>>
>>>
>>>>   David has made a nice case for even more precise detail in the
>>>> alias category.  Rather than trying to overload the URI or depend
>>>> on other external resources, I urge that we provide the details
>>>> we need in the alias category in the alias catgeory.  Extending
>>>> the key is an interesting issue.   We may need to add the
>>>> implicit concept from DDL2 to DDLm or to make a subcategory.
>>>
>>>
>>> As I wrote separately, I agree with David about the additional data that should be associated with aliases.  And once more: I do not support, favor, claim, assert, promote, or in any other sense agree with DDLm dictionaries relying on external resources for any part of their normative content.  As long as we're throwing around references to Codd, however, I do favor normalizing some of the dictionary details that would otherwise be duplicated for many aliases.  I wrote about this in my response to David.
>>>
>>>
>>> [...]
>>>
>>>
>>>>   I would suggest we give David the extra alias category tags
>>>> he is asking for as well as my tag_style identifier, with
>>>> reasonable default assumptions when they are not used.
>>>
>>>
>>> I concur that we should provide the additional alias attributes, or, as I prefer, a more normalized equivalent.  I still see no reason for tag_style.
>>>
>>>
>>>>   If
>>>> I fail in what David calls my "noble" goal in DDLm-ing the
>>>> imgCIF dictionary and he fails in whatever use he makes of
>>>> the extended alias catgeory, what will it have cost those
>>>> who choose not to use these features in their dictionaries.
>>>
>>>
>>> I have already answered this.  At minimum, it will cost everybody incrementally longer software release cycles and incrementally more risk of bugs in the software they rely upon.
>>>
>>>
>>>> If we succeed on the other hand, you will have a few extra
>>>> useful tools you might decide to use in the future.
>>>
>>>
>>> How useful a tool tag_style would be is a key issue in dispute, and an essential one for the cost / benefit analysis that should inform our decision about whether to include it.  I do see value in categorizing aliases.  I currently see almost zero practical distinction between calling the grouping unit a "style" and calling it a "dictionary", however, and I see no benefit to providing redundant features.
>>>
>>>
>>> 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
>
_______________________________________________
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.