Discussion List Archives

[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]
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