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

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

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

Reply to: [list | sender only]