Discussion List Archives

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

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

Title:
Dear Colleagues,

Following John B's suggestion I have had a look at XERF (external reference).  This seems to be an alternative to using aliases and I am not sure why both approaches were defined in DDLm.  In speaking with Syd some time ago I got the impression that XREF had been defined for future use and had not been tested (nor had aliases).  The DDLm code is fairly primitive and looks as if it would need refinement.

The main difference between the two approaches is that SREF allows for all the attributes of the other dictionaries to be given in a single list.  The save frame of a normal data item then contains just the alternative name and a code for the dictionary where it is found.  The DDLm probably would need some tweeking, but this approach has the advantage that all the dictionary attributes are given only once, rather than with every datename from that dictionary.  With all the information one might ever want about the dictionary stored in a singel list of external dictionaries, only a single code is needed to identify the dictionary of any alias name.  Collecting all the datanames by dictioanry (or dictionary version) would invlove only checking the dictionary code of each alias item. 
 
David

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

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

_alias_group.identifier_id
   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
cases.

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, 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
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]
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.