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:

_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
                  [email protected]
=====================================================

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
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group

_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group