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

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


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"
>>> DDL1 "The tags for use with DDL1 CIF1 core data files"
>>> DDL2 "The tags for use with DDL2 CIF1 mmCIF data files"
>>>
>>> And we should add _alias tags into the
>>> _geom.special_details save frame:
>>>
>>> loop_
>>> _alias.definition_id
>>> _alias.xref_code
>>> '_geom.special_details' .
>>> '_geom_special_details' .
>>> '_geom.details' .
>>>
>>> Alternatively, because this is a very simple case, we can flatten
>>> the hierarchy and not use the dictionary alias_ensemble category
>> > at all, joining the two loops as one loop into the _geom.special_details save frame
>> >
>>> loop_
>>> _alias.definition_id
>>> _alias.ensemble_id
>>> _alias.xref_code
>>> '_geom.special_details' DDLm .
>>> '_geom_special_details' DDL1 .
>>> '_geom.details' DDL2 .
>>>
>>> and we could, if we wished actually use the xref codes for DDL1 and DDL2
>>> and refer back to the existing core CIF and mmCIF dcitionaries, though
>>> I would suggest trying to make the new DDLm dictionaries self-contained.
>>>
>>> Regards,
>>> Herbert
>>>
>>>
>>> At 7:52 AM -0500 1/27/11, John Westbrook wrote:
>>>> Hi Herbert,
>>>>
>>>> I am trying to understand the mapping of the proposed items to a simple
>>>> example from the mmCIF dictionary. Could you provide an example using
>>>> the proposed DDL for how the following alias would be represented.
>>>>
>>>> save__geom.details
>>>> _item_description.description
>>>> ; A description of geometry not covered by the
>>>> existing data names in the GEOM categories, such as
>>>> least-squares planes.
>>>> ;
>>>> _item.name '_geom.details'
>>>> _item.category_id geom
>>>> _item.mandatory_code no
>>>> _item_aliases.alias_name '_geom_special_details'
>>>> _item_aliases.dictionary cif_core.dic
>>>> _item_aliases.version 2.0.1
>>>> _item_type.code text
>>>> save_
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>>
>>>> On 1/26/11 10:49 PM, Herbert J. Bernstein wrote:
>>>>> So, to pull it all together, see below. Please review and see
>>>>> what I have missed, mistyped or failed to convert from some
>>>>> earlier incarnation. Comments, corrections and suggestions
>>>>> greatly appreciated.
>>>>>
>>>>> I have not yet included the type change for _dictionary_xref.format
>>>>> because I am not sure a single word code would be sufficient
>>>>> to describe the format of any given dictionary, so for the moment
>>>>> it is still Text.
>>>>>
>>>>> -- HJB
>>>>>
>>>>> save_definition.xref_code
>>>>> _definition.id '_definition.xref_code'
>>>>> _definition.update 2011-01-26
>>>>> _definition.class Attribute
>>>>> _description.text
>>>>> ;
>>>>> Code identifying the equivalent definition in the dictionary
>>>>> referenced by the DICTIONARY_XREF attributes.
>>>>>
>>>>> Use of _definition.xref_code is deprecated in favor of
>>>>> use of _alias.xref_code
>>>>> ;
>>>>> _name.category_id definition
>>>>> _name.object_id xref_code
>>>>> _type.purpose Identify
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>> save_
>>>>>
>>>>> save_ALIAS
>>>>>
>>>>> _definition.id alias
>>>>> _definition.scope Category
>>>>> _definition.class List
>>>>> _definition.update 2011-01-26
>>>>> _description.text
>>>>> ;
>>>>> The attributes used to specify the aliased names of definitions.
>>>>> Every tag has an implicit alias to itself with a null
>>>>> _alias.xref_code to allow use of the primary tag in
>>>>> the ALIAS_ENSEMBLE category.
>>>>> ;
>>>>> _category.parent_id ddl_attr
>>>>> _category_key.primitive ['_alias.definition_id',
>>>>> '_alias.xref_code']
>>>> > save_
>>>>>
>>>>>
>>>>> save_alias.definition_id
>>>>> _definition.id '_alias.definition_id'
>>>>> _definition.class Attribute
>>>>> _definition.update 2006-11-16
>>>>> _description.text
>>>>> ;
>>>>> Identifier tag of an aliased definition.
>>>>> ;
>>>>> _name.category_id alias
>>>>> _name.object_id definition_id
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Tag
>>>>> save_
>>>>>
>>>>> save_alias.deprecated
>>>>> _definition.id '_alias.deprecated'
>>>>> _definition.class Attribute
>>>>> _definition.update 2006-11-16
>>>>> _description.text
>>>>> ;
>>>>> Specifies whether use of the alias is deprecated
>>>>> ;
>>>>> _name.category_id alias
>>>>> _name.object_id definition_id
>>>>> _type.purpose STATE
>>>>> _type.container Single
>>>>> _type.contents YesorNo
>>>>> _enumeration.default No
>>>>> save_
>>>>>
>>>>>
>>>>> save_alias.dictionary_uri
>>>>> _definition.id '_alias.dictionary_uri'
>>>>> _definition.update 2011-01-26
>>>>> _definition.class Attribute
>>>>> _description.text
>>>>> ;
>>>>> Dictionary URI in which the aliased definition belongs.
>>>>> _alias.dictionary_uri is deprecated in favor if
>>>>> _alias.xref_code
>>>>> ;
>>>>> _name.category_id alias
>>>>> _name.object_id dictionary_uri
>>>>> _type.purpose Identify
>>>>> _type.container Single
>>>>> _type.contents Uri
>>>>> save_
>>>>>
>>>>> save_alias.xref_code
>>>>> _definition.id '_alias.xref_code'
>> >>> _definition.update 2011-01-26
>>>>> _definition.class Attribute
>>>>> _description.text
>> >>> ;
>>>>> Code identifying the dictionary containing the primary
>>>> > definition of the dictionary as given in the
>>>>> DICTIONARY_XREF category.
>>>>>
>>>>> ;
>>>>> _name.category_id definition
>>>>> _name.object_id xref_code
>>>>> _name.linked_item_id '_dictionary_xref.code'
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>> save_
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> save_ENSEMBLE
>>>>>
>>>>> _definition.id ensemble
>>>>> _definition.scope Category
>>>>> _definition.class List
>>>>> _definition.update 2011-01-26
>>>>> ;
>>>>> Data items used to describe the ensemble identifiers
>>>>> used in this dictionary. Data items in this category
>>>>> are NOT used as attributes of individual data items.
>>>>>
>>>>> See linked item _alias_ensemble.ensemble_id.
>>>>> ;
>>>>> _category.parent_id ddl_attr
>>>>> _category_key.generic '_ensemble.id'
>>>>>
>>>>> save_
>>>>>
>>>>> save_ensemble.id
>>>>> _definition.id '_ensemble.id'
>>>>> _definition.class Attribute
>>>>> _definition.update 2011-01-26
>>>>> _description.text
>>>>> ;
>>>>> A code identifying an ensemble of related tags.
>>>>> To help ensure that dictionaries can be merged,
>>>>> each code should either begin with an IUCr-registered
>>>>> prefix or if not prefixed, have been approved
>>>>> by COMCIFS. The special prefix 'local_' may be
>>>>> use for purely internal purposes of an organization.
>>>>> ;
>>>>> _name.category_id ensemble
>>>>> _name.object_id code
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>>
>>>>> save_
>>>>>
>>>>> save_ensemble.description
>>>>> _definition.id '_ensemble.description'
>>>>> _definition.class Attribute
>>>>> _definition.update 2011-01-26
>>>>> _description.text
>>>>> ;
>>>>> A description of the ensemble
>>>>> ;
>>>>> _name.category_id ensemble
>>>>> _name.object_id code
>>>>> _type.purpose Describe
>>>>> _type.container Single
>>>>> _type.contents Text
>>>>>
>>>>>
>>>>> save_
>>>>>
>>>>> save_ALIAS_ENSEMBLE
>>>>>
>>>>> _definition.id alias_ensemble
>>>>> _definition.scope Category
>>>>> _definition.class List
>>>>> _definition.update 2011-01-26
>>>> > ;
>>>>> The attributes used to specify the ensemble of
>>>>> tags to which a given tag belong.
>>>>>
>>>>> A given tag may belong to multiple ensembles
>>>>> and may be cited against multiple dictionaries.
>>>>>
>>>>> ;
>>>>> _category.parent_id alias
>>>>> _category.parent_join Yes
>>>>> _category_key.primitive ['_alias_ensemble.ensemble_id',
>>>>> '_alias_ensemble.definition_id',
>>>>> '_alias_ensemble.xref_code']
>>>>> save_
>>>>>
>>>>> save_alias_ensemble.definition_id
>>>>> _definition.id '_alias_ensemble.definition_id'
>>>>> _definition.class Attribute
>>>>> _definition.update 2011-01-21
>>>>> _description.text
>>>>> ;
>>>>> Identifier tag of a definition associated with
>>>>> an xref code by which to group this tag with
>>>>> other tags.
>>>>>
>>>>> A given tag may belong to multiple ensembles
>>>>> and may be cited against multiple dictionaries.
>>>>>
>>>>> Note that the tag does not have to be a valid
>>>>> tag under DDLm tag construction rules, but
>>>>> it should be a valid tag under the rules of
>>>>> some DDL.
>>>>> ;
>>>>> _name.category_id alias_ensemble
>>>>> _name.object_id definition_id
>>>>> _name.linked_item_id '_alias.definition_id'
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>> save_
>>>>>
>>>>> save_alias_ensemble.ensemble_id
>>>>> _definition.id '_alias_ensemble.ensemble_id'
>>>>> _definition.class Attribute
>>>>> _definition.update 2011-01-26
>>>>> _description.text
>>>>> ;
>>>>> A code identifying an ensemble of related tags.
>>>>> To help ensure that dictionaries can be merged,
>>>>> each code should either begin with an IUCr-registered
>>>>> prefix or if not prefixed, have been approved
>>>>> by COMCIFS. The special prefix 'local_' may be
>>>>> use for purely internal purposes of an organization.
>>>>> ;
>>>>> _name.category_id alias_ensemble
>>>> > _name.object_id code
>>>>> _name.linked_item_id '_ensemble.id'
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>>
>>>>> save_
>>>>>
>>>>>
>>>>> save_alias_ensemble.xref_code
>>>>> _definition.id '_alias_ensemble.xref_code'
>>>>> _definition.class Attribute
>>>>> _definition.update 2011-01-21
>> >>> _description.text
>>>>> ;
>>>>> A code identifying the actual dictionary,
>>>>> virtual dictionary or other logical grouping
>> >>> to which the identifier tag belongs.
>>>>> ;
>>>>> _name.category_id alias_ensemble
>>>>> _name.object_id code
>>>>> _name.linked_item_id '_dictionary_xref.code'
>>>>> _type.purpose Key
>>>>> _type.container Single
>>>>> _type.contents Code
>>>>> save_
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> At 2:29 PM -0600 1/26/11, Bollinger, John C wrote:
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> --
>>>> ******************************************************************
>>>> John Westbrook, Ph.D.
>>>> Rutgers, The State University of New Jersey
>>>> Department of Chemistry and Chemical Biology
>>>> 610 Taylor Road
>>>> Piscataway, NJ 08854-8087
>>>> e-mail: jwest@rcsb.rutgers.edu
>>>> Ph: (732) 445-4290 Fax: (732) 445-4320
>>>> ******************************************************************
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> ddlm-group@iucr.org
>>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>
>> --
>> ******************************************************************
>> John Westbrook, Ph.D.
>> Rutgers, The State University of New Jersey
>> Department of Chemistry and Chemical Biology
>> 610 Taylor Road
>> Piscataway, NJ 08854-8087
>> e-mail: jwest@rcsb.rutgers.edu
>> Ph: (732) 445-4290 Fax: (732) 445-4320
>> ******************************************************************
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>

-- 
******************************************************************
   John Westbrook, Ph.D.
   Rutgers, The State University of New Jersey
   Department of Chemistry and Chemical Biology
   610 Taylor Road
   Piscataway, NJ 08854-8087
   e-mail: jwest@rcsb.rutgers.edu
   Ph:  (732) 445-4290  Fax: (732) 445-4320
******************************************************************
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]