Discussion List Archives

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

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

Dear John,

   OK -- does anyone object to identifier_set in place of ensemble?

   My personal motivation is to move to one DDLm dictionary that will
become the primary maintenance vehicle for the DDLm, DDL2 and a new
DDL1 versions of imgCIF.  I believe that this approach will simplify
the entire move to DDLm while continuing to support DDL1 and DDL2
for other dictionaries, but that use is up to the maintainers of
those other dictionaries.

   The established approach of just using aliases against other 
dictionaries will work fine as long as the appropriate dictionary
is a distinct other document, but becomes a problem once more
people move to DDLm dictionaries as the primary dictionaries
for multiple uses as DDLm, DDL1 and DDL2 dictionaries, a capability
explicitly promised on the IUCr web site.

   To trespass on David's territory -- once he has a complete core
dictionary, why should the new mmCIF DDLm dictionary have its
own copy of the core as it now does.  It should simply import
David's new core for the same purpose, but that new core should,
in my opinion, simply define both the dotted notation tags for
new CIFs and in the same dictionary define the old DDL1 style
tags with no need to refer to the original DDL1 core dictionary.
That way the core gets maintained in one place, not 2 or 3,
and your effort just focuses maintaining truly mmCIF items.
Then I, in imgCIF, would import both your mmCIF and David's

   To me, it makes sense.  That does not mean you cannot continue
to do what you are currently doing, but I think you will find
the more organized DDLm approach to be a better division of labor.

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


On Thu, 27 Jan 2011, John Westbrook wrote:

> Hi Herbert,
> Your *_set alternative names are fine.  Ensemble is a killer term for the mm world.
> I am afraid I am just not appreciating the motivation for this fancy grouping mechanism.
> My aliases always arise by reference to a particular data item in some named dictionary/version.
> The dictionary could certainly have a well-defined URI in addition to a name but
> this may not capture the version depending on how the dictionary is managed.
> Given this is my typical scenario, could you explain how I should map this to your
> idea of for referencing aliases.
> Thanks again for the explanation --
> John
> On 1/27/11 3:01 PM, Herbert J. Bernstein wrote:
>>> Dear John,
>>> In many contexts, a DDL variant well could be an ensemble, e.g. if we
>>> were talking about the DDL1 core, but we also could have ensembles that
>>> are finer and/or coarser-grained than a particular DDL variant, e.g.
>>> a mixed set of tags needed to represent a particular class of experimental
>>> data acquisition, which might combine, say, imgCIF, EM, and mmCIF tags,
>>> or, say, imgCIF and PD tags. In both cases, the ensemble could draw
>>> from portions of multiple dictionaries. That is why I have resisted
>>> conflating it with xref_code. It just is not the same thing.
>>> In addition, a single dictionary can (and in my opinion should be)
>>> a repository for the primary definitions of tags belonging to
>>> multiple ensembles.
>>> That being said, I don't mind going to a thesaurus and finding
>>> yet more words describing ways to group tags, but I think you
>>> will find almost all to them have already been used in some sub-discipline
>>> impacted by macro-molecular crystallography. That is why I started
>>> with tag_style, to get away for terms that have already been used.
>>> How about "tag_set" or "identifier_set"? That is clumsy enough not to have been taken yet (I think), but does convey the idea.
>>> Regards,
>>> Herbert
>>> At 2:44 PM -0500 1/27/11, John Westbrook wrote:
>>>> Hi Herbert,
>>>> Thanks for the example. From a DDL2 perspective we appear to now making a reference to a
>>>> dictionary language version rather than a particular named dictionary and we are lacking
>>>> an associated dictionary version.
>>>> I have a couple of points/questions --
>>>> 1. I am not sure that I understand the scope of an ensemble here. Is this a reference
>>>> to a DDL variant or just any named collection of items?
>>>> 2. The term ensemble would be very confusing in the PDB context so I would prefer
>>>> something more reflective of the target in your example. Perhaps,
>>>> dict_language, dict_collection, dict_set, definition_set, or definition_collection
>>>> depending on the scope above.
>>>> 3. If ensemble refers to dictionary (i.e. core_cif.dic) or some portion of a dictionary
>>>> then I think I understand the usage and would only ask that you adopt a
>>>> different ddl category name. If this is not the strategy then I am confused
>>>> by this construction and do not see how to map from mmCIF/DDL2.
>>>> Thanks for the clarification --
>>>> John
>>>> On 1/27/11 9:10 AM, Herbert J. Bernstein wrote:
>>>>> Dear John,
>>>>> There are lots of alternate resolutions to this, but suppose
>>>>> we started with the 2008 DDLm expanded core dictionary entry:
>>>>> save_geom.special_details _definition.id '_geom.special_details' _definition.update 2006-12-14
>>>>> _description.text ; Description of geometry information not covered by the existing data names in the geometry categories, such as
>>>>> least-squares planes. ; _description.common 'GeomSpecialDetails' _name.category_id geom _name.object_id special_details
>>>>> _type.purpose Describe _type.container Single _type.contents Text
>>>>> save_
>>>>> Then the essential definitions to handle DDLm, DDL1 core, and DDL2 mmCIF
>>>>> would be:
>>>>> loop_
>>>>> _alias_ensemble.definition_id
>>>>> _alias_ensemble.ensemble_id
>>>>> _alias_ensemble.xref_code
>>>>> '_geom.special_details' DDLm .
>>>>> '_geom_special_details' DDL1 .
>>>>> '_geom.details' DDL2 .
>>>>> loop_
>>>>> _ensemble.id
>>>>> _ensemble.description
>>>>> DDLm "The tags for use with common DDLm CIF2 data files"
> [*** Terminated Message ***]
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.