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

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