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

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

Title:
Dear Coleagues,

Herbert J. Bernstein 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

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?

David


=====================================================
  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

begin:vcard
fn:I.David Brown
n:Brown;I.David
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
email;internet:idbrown@mcmaster.ca
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773
version:2.1
end:vcard

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]