Discussion List Archives

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

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

Dear Colleagues,

   A dictionary is rarely a collection of words defining one
language.  It is more commonly a collection of words defining
a more or less related family of languages.  Certainly one could
think of the subset of words to be used in one member of
that family as being, as John B. suggests, a "virtual dictionary".
I happen to think of it as a "style".  To help get the
emotion out of this, how about we take the term "group"?
In terms of a DDL rules, the problem with placing this directly
under alias, is that the same tag may belong multiple
sunsets, so I would suggest we create a subcategory of
alias called alias_group, and start it off with the
following two tags:

   This is one component of the key, and is an identifier
for a group of tags

   This is the other component of the key.  It specifies
either the tag of the item in the current definition, or an 
identifier to be used in place of the DDLm tag of the item
in the current definition when working with this particular
group for validation or output

The question of whether some of the additional detail that
David is requesting belongs down in the subcategory or in
the parent category depends on normalization rules, which
in turn will follow from what duplication may arise in use

  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


On Fri, 21 Jan 2011, Bollinger, John C wrote:

> Dear Herbert,
> On Thursday, January 20, 2011 7:54 PM, you wrote:
>>   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.
> Almost.  I think the needed attribute is already among David's proposed expanded set:
> "The tag, the dictionary in which it appears, the version of this dictionary, the DDL in which the dictionary is written [...], a flag to indicate whether the dataname is deprecated (needed for writing files) and a pointer to where the named dictionary can be found."
> Note the separation of "the dictionary in which it appears" from "a pointer to where the named dictionary can be found".  The former might receive the name "_alias.dictionary_code", and the latter the name "_alias.dictionary_uri"; _alias.dictionary_code (or whatever name is chosen for this attribute) serves.
>> 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.
> David's separation of dictionary identifier from dictionary locator already addresses this problem.  I took that to be intentional on his part.  This moots my proposed redefinition of dictionary_uri, therefore I withdraw that proposal, including those parts related to other attributes.  I plan to bring an alternative soon, based on David's suggestion.
>>  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.
> And which option would provide that?  At this point, I think neither.  There needs to be a definition to go with the name before we can judge either whether the concept is appropriate for the DDL or whether the name is appropriate for the concept.  The new proposal I intend to bring will include these for the attributes it adds or modifies.  If you want a tag_style attribute in addition to the attributes you, David, and I all seem to agree on, then I urge you to prepare proposed definition text so that everyone understands what they are voting on.  Such a proposal probably would not conflict with my forthcoming one, though I expect that I would consider it functionally redundant.
> Regards,
> John
> 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

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

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

ICSU 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.