Discussion List Archives

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

Re: [ddlm-group] DDLm aliases (subject changed). .. .

On Wednesday, January 26, 2011 11:34 AM, Herbert J. Bernstein wrote:

>OK, so we need to pick a non-conflicting name for the tag that gives
>the unifying identifier that will satisfy John W.'s concerns and
>James's concerns, but that will not preclude John B. and David's
>preference to allow the presentation to be unified with the
>xref_code.  How about "ensemble_id".  This is a distinct concept
>from the identifier of the dictionary itself, because one
>dictionary can contain multiple ensembles and one ensemble
>can span multiple dictionaries.

Ok, that makes sense.

> Here is my modified version of John B.' proposal:

I think we are close here.  There are a couple of additions I would like to see to Herbert's version of the proposal, however.  Rather than quote the whole thing, I include it verbatim below, with my additions at the bottom and additional commentary following:


1) Deprecate _alias.dictionary_uri.

2) Add as a of subcategory of alias, alias_ensemble with the following
tags:

_alias_ensemble.definition_id
     a tag identifier belonging to an ensemble
_alias_ensemble.ensemble_id
     a code identifying an ensemble of tags to which the tag belongs
_alias_ensemble.xref_code

All of these tags are members of the composite key of the sub
category, so that it is possible to have a physical dictionary
the same tag in multiple ensembles, or to break out this subcategory
as a master index running over all tags alias giving both the
physical dictionaries from which they are taken and and the
ensembles to which they belong.

3) Add tag

_alias.xref_code

to the alias category

_alias.xref_code specifies the physical dictionary from which the
preferred definition of the tag alias has been taken, or is null
if the current dictionary is the primary definer of the tag alias.
This tag is the parent of _alias_ensemble.xref_code.  There are
some technical issues on use of the join mechanism, and which
tags are keys, but they can be resolved if the flattened version
is truly desired.


4) Add tag:

_alias.deprecated: Specifies whether use of the alias is deprecated.
     _type.purpose     State
     _type.container   Single
     _type.contents    YesorNo

5) Modify the definition of _dictionary_xref.format by changing its
_type.contents attribute to "Code".

6) Deprecate _definition.xref_code (its purpose will be served via
the alias mechanism)


----
JCB Adds:
----

7) In the ALIAS category, replace attribute _category_key.generic with:
    _category_key.primitive [ '_alias.xref_code' '_alias.definition_id' ]

This is still appropriate, inasmuch data names are not guaranteed to be globally unique across all dictionaries.  For that matter, if it were inappropriate here then there would be no need for _alias_ensemble.xref_code, as no _alias.definition_id could be associated with more than one xref_code, and that one would be specified by _alias.xref_code.


8) Modify the description of the DICTIONARY_XREF category to: "The DICTIONARY_XREF attributes identify and describe logical or physical dictionaries to which items in the current dictionary are cross-referenced using the _definition.xref_code or _alias.xref_code attribute."

I still think the concept of a logical dictionary is a sound and useful one, even alongside Herbert's _alias_ensemble idea.  This wording change accommodates the concept without requiring any new attributes.  Be it known, however, that if we agree to this then corresponding slight adjustments may be needed to the definitions of some of the other existing attributes in the DICTIONARY_XREF category.  I think those can be discussed later, when and if the time comes.

Naturally, if _definition.xref_code were removed instead of deprecated, then this definition should not refer to it.

========


I can live with deprecating _definition.xref_code and _alias.definition_uri, though my preference is still to remove them.  Inasmuch as, to my knowledge, DDLm has so far been published and distributed only in draft / for-comments form, it will indeed be a new standard when it eventually is accepted by COMCIFS.  Those developers and dictionary authors already working with the draft should be doing so with the understanding that it is subject to change.  Also, I suspect we will consider further possibly-disruptive changes before we are done, and I am loathe to set a precedent that compatibility with the draft is a supremely compelling concern.

Nevertheless, deprecation vs. removal of these attributes is too small a detail to be hung up over.  When we are ready to vote on the overall proposal, I would prefer to vote separately on that question -- separately for each attribute, in fact.  In the mean time, let's proceed.

Question to consider: should there be a means in the DDL to identify the significance of a particular ensemble, at least for the benefit of humans?  That might take a form as simple as a dictionary-scoped ENSEMBLE category, with attributes _ensemble.ensemble_id and _ensemble.description.

I note also that Herbert did not bring forward my proposed _alias.dictionary_version attribute into his version of the proposal, nor have I added it back to this version.  I see only limited potential use for it, and I am not prepared to argue for it.  Others of you may think differently, however.


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

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

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

International Science Council 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.

Useful links