Discussion List Archives

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

Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. .

Dear David,

   The alias mechanism in the DDLm document of 2008 does
not seem to do the job of getting around the restrictions
that were imposed for CIF2 on the CIF files themselves,
invalidating basically any tag that does not conform
to the necessities of identifer syntax in a dREL method.
What I am proposing as a way for a dREL method itself
to cope with an arbitrary CIF1 tag, allowing true
CIF1 documents handled.  This is important to, for
eaxmple, ensure that when a DDLm method is populating
a category in a CIF1 document, that it populates the
actual original CIF1 category and not the category
with the CIF2 alias name.  This will allow the power
of DDLm and dREL to be applied to documents that still
need to be processed by existing software that is
not yet aware of new CIF2 names for various categories
and tags, and therefore should not automatically migrate
to the alias name.  The current form of alias seems
to be purely a one-way path.

   Is there a later extension of alias after the 2008
document?

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

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

On Mon, 17 Jan 2011, David Brown wrote:

> This is a pssing comment on the first paragraph of Herbert's email to set
> the record straight. 
> 
> David Brown
> 
> 
> 
> Herbert J. Bernstein wrote:
>         What I propose is that we add one new statement to dREL,
>       similar to the python import .. as ..., which allows a module in
>       python that actually exists under one name to be used in a chunk
>       of pythin code as if it had a different name.  One possible
>       syntax could be to simply extent the python import statment
>       allowing elides in the identifier name, such as
>
>         import cell\[\] as CELL
>
>       or some other quoting mechanism to allow CIF1 names that are not
>       valid internally in dREL to be handled by dREL algorithms.
> 
> We discussed this many moons ago.  For the most part Herbert's suggestion is
> already accommodated by the _alias feature of DDLm.  This allows any CIF1 or
> CIF2 dataname to be recognized as equivalent to a DDLm dataname at the timw
> of reading.  Thus a CIF1 or CIF2 item will be treated exactly the same way
> in the program as if it were in a file written using a DDLm dictionary. 
> There may be one or two places where a DDLm driven program might have
> difficulty, but they will not be common.  None come immediately to mind. 
> The main problem will be trying to read the many archived CIFs that are not
> well formed, but there should be no need for a major reformatting of the
> existing archive.
> 
> 
> ## End of my comments
> 
> 
>
>         This does not mean that a DDLm dictionary would somehow have
>       to contain the identifiers that have been banned under CIF2. The
>       dictionary could work entirely under CIF2 rules.  It just means
>       that the data being manipulated under control of the dictionary
>       could include unmodified CIF1 data files and that the algorithms
>       in dREL could be applied to the entire range of CIF1 tags.
>
>         There is no import statement currently in dREL, so there is
>       not conflict with the existing spec.  Other than providing a
>       symbol table translation, there should be no impact of this
>       change on the structure and syntax of dREL.
>
>         While this is an othogonal feature, I do intend to also
>       propose that DDLm dictionaries we used to process CIF1 files
>       that include CIF1-style string, e.g. the famous 'O'', so that
>       the promise made for so many years on the IUCr web site of being
>       able to process archived CIF1 data files with DDLm can be kept.
>
>         I think CIF1 (both DDL1 and DDL2 CIF) coupled to DDLm could be
>       a very powerful and useful combination that could be introduced
>       with minimal disruption to existing software. I understand that
>       others may prefer a more drastic change. I hope they will see
>       the value in allowing this more cautious and conservative
>       approach to go forward under the CIF banner, even if they
>       themselves intend to pursue their own, more drastic set of
>       changes, also under the CIF banner.
>
>         If this is agreeable, I will undertake to have a demonstration
>       version of DDLm/dREL fully coupled to CIF1 using the import ...
>       as ... statement to show and discuss with those who are
>       interested in Madrid.
>
>         Regards,
>           Herbert
> 
>
>       =====================================================
>        Herbert J. Bernstein, Professor of Computer Science
>          Dowling College, Kramer Science Center, KSC 121
>               Idle Hour Blvd, Oakdale, NY, 11769
>
>                        +1-631-244-3035
>                        yaya@dowling.edu
>       =====================================================
>
>       On Sun, 16 Jan 2011, Herbert J. Bernstein wrote:
>
>             Dear Simon,
>
>              If I read your message correctly, you seem to be
>             saying that the design objectives of CIF2 are:
>
>              1.  enchance CIF as a data source
>              2.  accomodate DDLm
>              3.  do 1 and 2 in a way that does not complicate
>             CIF as a data source
>
>              I don't understand what you mean by "enhance CIF as
>             a data source". This is the first time I recall
>             hearing that objective.  Please clarify.
>
>             In terms of present practice, I had thought that the
>             major current uses of CIF to be:
>
>              1.  As a language for publication of papers in IUCr
>             journals;
>              2.  As a language for submission of data to CCDC;
>              3.  As a language for submission of data to the
>             PDB;
>              4.  As a data harvest language for CCP4; and
>              5.  As a language for formatting image data from
>             Dectris detectors,
>             with some emerging use for data management of
>             synchrotron data
>              ( Please fill in uses I have missed ...)
>
>             which would seem to me to represent a large current
>             investment in data management software that depends
>             critically on stability and reliability of CIF
>             representation of both numeric data and text.  As I
>             understand it, DDLm and dREL can contribute to these
>             current uses by enhancing the reliabiity of
>             validation of data in these contexts, especially in
>             uses 1, 2 and 3, above. To me, that would  seem to
>             change the objectives to:
>
>              1.  Accomodate DDLm and dREL; and
>              2.  Do this in a way that keeps required changes to
>             existing
>             archives to a minimum; and
>              3.  Do this in a way that allows as much existing
>             CIF software
>             as possible to continue to operate reliably; and
>              4.  To the extent that changes will be needed in
>             archives and
>             software, provide a clearly understood mechanism for
>             making
>             those changes, with as much support software as
>             possible; and
>              5.  Subordinate to the above, add new features to
>             CIF that may
>             encourage broader use and more software support
>
>             Please tell me what I have misunderstood in this.
>
>             Regards,
>              Herbert
>
>             =====================================================
>             Herbert J. Bernstein, Professor of Computer Science
>               Dowling College, Kramer Science Center, KSC 121
>                    Idle Hour Blvd, Oakdale, NY, 11769
>
>                             +1-631-244-3035
>                             yaya@dowling.edu
>             =====================================================
>
>             On Sun, 16 Jan 2011, SIMON WESTRIP wrote:
>
>                   I believe that the CIF2 syntax changes
>                   enhance CIF as data source,
>                   even with the restriction to the
>                   contents of  ' and " delimited values,
>                   which
>                   I suspect will be the main source of
>                   incompatability between archived CIFs
>                   and CIF2. What we havent acheived is
>                   100% compatability of CIF1 with CIF2,
>                   but having agreed that CIF2 is distinct
>                   from CIF1 and minimized the
>                   incompatability,
>                   I do not see the changes as disruptive
>                   or retrograde.
>
>                   DDLm methods will not be applicable to a
>                   significant percentage of a CIF
>                   data source
>                   (those 'free text' fields used to report
>                   experimental details etc.). I
>                   believe other approaches
>                   will be needed to enhance their content
>                   (referencing other data items from
>                   an item etc).
>                   Unicode support in CIF2 is beneficial in
>                   this area, and the new alternative
>                   delimiters may
>                   prove convenient. The list and table
>                   structures may also be exploited.
>
>                   So from my point of view, though I
>                   understood the aim of CIF2 was to
>                   accommodate DDLm,
>                   it turns out that it does offer a little
>                   bit more. I would still like the
>                   problem of including all delimiters
>                   in a value to be solved, and
>                   line-folding to be included. On my 'wish
>                   list'
>                   are value concatenation
>                   and a value-referencing mechanism for
>                   use with CIF as a data source.
>
>                   I know this doesnt really answer your
>                   question. What we are *not* trying to
>                   do is complicate
>                    CIF as a data source?
>
>                   Cheers
>
>                   Simon
> 
> ___________________________________________________________________________
>                   _
>                   From: Herbert J. Bernstein
>                   <yaya@bernstein-plus-sons.com>
>                   To: Group finalising DDLm and associated
>                   dictionaries <ddlm-group@iucr.org>
>                   Sent: Sunday, 16 January, 2011 2:05:59
>                   Subject: Re: [ddlm-group] Relationship
>                   asmong CIF2, STAR, CIF1 and Python. .
>
>                   Dear Simon,
>
>                     I have reviewed the record on this,
>                   and I have trouble finding
>                   a strong basis for most of the decisions
>                   made other than arguments
>                   from the authority of established past
>                   practice in STAR and dREL.
>                   Now that those arguments have turned out
>                   not to have been what they
>                   seemed, I have trouble accepting the
>                   resulting conclusions without
>                   new, clearly stated arguments based in
>                   the functionality we are
>                   trying to achieve, but it is now not
>                   even clear what functionality we
>                   are
>                   trying to achieve.
>
>                     Perhaps you can help me -- what are we
>                   trying to do in defining
>                   CIF2?
>
>                     Regards,
>                       Herbert
> 
>
>                   At 11:55 PM +0000 1/15/11, SIMON WESTRIP
>                   wrote:
>                   >That's a question I asked myself when I
>                   first joined this discussion group
>                   :-)
>                   >
>                   >To be honest Herbert, I do not feal
>                   qualified to contest anything to do
>                   with
>                   >dREL, nor DDLm, given that I havent
>                   worked on them and respecting the
>                   >years of effort that went into
>                   development thus far. The same is
>                   >true with respect to some of
>                   >the changes to CIF syntax that
>                   invalidate CIF1: I have accepted that
>                   >they are necessary
>                   >to facilitate implementation of dREL
>                   methods.
>                   >
>                   >Cheers
>                   >
>                   >Simon
>                   >
>                   >
>                   >
>                   >From: Herbert J. Bernstein
>                   <yaya@bernstein-plus-sons.com>
>                   >To: Group finalising DDLm and
>                   associated dictionaries
>                   <ddlm-group@iucr.org>
>                   >Sent: Saturday, 15 January, 2011
>                   23:14:36
>                   >Subject: Re: [ddlm-group] Relationship
>                   asmong CIF2, STAR, CIF1 and Python.
>                   .
>                   >
>                   >Why not?  It is almost that right now.
>                   >
>                   >
>                   >At 11:08 PM +0000 1/15/11, SIMON
>                   WESTRIP wrote:
>                   >>True - but I can't see dREL becoming
>                   pyREL at this stage?
>                   >>
>                   >>
>                   >>
>                   >>From: Herbert J. Bernstein
>                   >><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>                   >>To: Group finalising DDLm and
>                   associated dictionaries
>                   >><<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org>
>                   >>Sent: Saturday, 15 January, 2011
>                   22:57:17
>                   >>Subject: Re: [ddlm-group] Relationship
>                   asmong CIF2, STAR, CIF1 and Python.
>                   .
>                   >>
>                   >>Dear Simon,
>                   >>
>                   >>  But dREL already shares much of
>                   Python syntax and data structures,
>                   >>but, being significantly mutated,
>                   lacks the software support and
>                   >>documentation that Python has.  Anyone
>                   who has to work with the
>                   >>methods in a DDLm dictionary would be
>                   much better off if we
>                   >>simply made Python work with DDLm.  We
>                   would gain large libraries
>                   >>of pre-written utilities, tools to
>                   test code fragments interactively,
>                   >>and a lot more time to do science or
>                   whatever we are actually
>                   >>funded to do.
>                   >>
>                   >>  Regards,
>                   >>    Herbert
>                   >>
>                   >>
>                   >>
>                   >>At 10:35 PM +0000 1/15/11, SIMON
>                   WESTRIP wrote:
>                   >>>As far as I can see, parsing DDLm
>                   into an object stucture is fairly
>                   >>>uncomplicated;
>                   >>>the hurdle is parsing the dREL script
>                   as a method of the object.
>                   >>>Unless working with python, I'm not
>                   sure that adopting python syntax
>                   >>>for DDLm/CIF
>                   >>>is of any great benefit; likewise for
>                   dREL.
>                   >>>
>                   >>>That said, I have yet to actually do
>                   anything with DDLm, let alone
>                   >>>dREL, so I may be
>                   >>>well off the mark. But even if this
>                   is the case, I suspect there
>                   >>>will be non-python programmers out
>                   >>>there that have cause to work with
>                   CIF and similarly will see no
>                   >>>obvious benefit in
>                   >>>CIF sharing python syntax (especially
>                   if it only adopts it for one
>                   >>>set of delimiters at the
>                   >>>data-source level).
>                   >>>
>                   >>>Cheers
>                   >>>
>                   >>>Simon
>                   >>>
>                   >>>
>                   >>>
>                   >>>From: Herbert J. Bernstein
> >>><<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.c
>
>                   om><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>                   >>>To: Group finalising DDLm and
>                   associated dictionaries
> >>><<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-gr
>
>                   oup@iucr.org>ddlm-group@iucr.org>
>                   >>>Sent: Saturday, 15 January, 2011
>                   21:16:59
>                   >>>Subject: Re: [ddlm-group]
>                   Relationship asmong CIF2, STAR, CIF1 and
>                   Python. .
>                   >>>
>                   >>>At 12:43 PM +0000 1/15/11, Brian
>                   McMahon wrote:
>                   >>>>It might be worth remarking (again)
>                   that dREL is being developed as a
>                   >>>>canonical methods description
>                   language, and not necessarily the
>                   runtime
>                   >  >>>methods evaluator of choice for
>                   future applications. It may be that in
>                   >>>>practice future methods are
>                   initially developed and most frequently
>                   >>>>executed directly in Python or some
>                   other language. As I see it, the
>                   >>>>goal of CIF and DDL evolution is not
>                   to exclude such a possibility.
>                   >>>
>                   >>>If we are trying to be Python
>                   friendly and much of dREL is derived
>                   >>>from a Jython implementation, I don't
>                   understand why we are not
>                   >>>conforming dREL, DDLm and CIF2 to
>                   Python conventions as closely as
>                   >>>possible.
>                   >>>
>                   >>>
>                   >>>
>                   >>>
>                   >>>
>                   >>>
>                   >>>
>                   >>>At 12:43 PM +0000 1/15/11, Brian
>                   McMahon wrote:
>                   >>>>On Thu, Jan 13, 2011 at 05:35:21PM
>                   -0600, Bollinger, John C wrote:
>                   >>>>>
>                   >>>>>  (snip)
>                   >>>>>
>                   >>>>>  CIF2 <=> CIF1:
>                   >>>>>  To the greatest extent feasible,
>                   well-formed CIF1 documents should be
>                   >>>>>  well-formed CIF2 documents
>                   (modulo a CIF version identification
>                   >>>>>  signature) having the same
>                   meaning.
>                   >>>>
>                   >>>>Agreed.
>                   >>>>
>                   >>>>>  CIF2 <=> STAR:
>                   >>>>>  Inasmuch as CIF1 is derived from
>                   STAR, I think it appropriate for
>                   CIF2
>                   >>>>>  to look first to STAR, including
>                   its post-CIF1 development, for new
>                   >>>>>  features it may need.  Even if
>                   CIF2 is not 100% compatible with STAR,
>                   it
>                   >>>>>  is worthwhile to avoid diverging
>                   without compelling reason.
>                   >>>>
>                   >>>>Agreed
>                   >>>>
>                   >>>>>  CIF2 <=> Python:
>                   >>>>>  I see no particular reason for
>                   any formal relationship here beyond
>                   >>>>>  Python's role as the indirect
>                   inspiration for CIF2's new
>                   >>>>>  triple-quote syntax.  I am wary
>                   of the idea of tying CIF tightly to
>                   >>>>>  a particular language.  CIF2
>                   documents are not and never will be
>                   >>>>>  Python programs.  I could imagine
>                   embedding Python in CIF or vise
>                   >>  >>>  versa, but I have seen no
>                   evidence to suggest that greater
>                   similarity
>                   >>>>>  between the two languages' syntax
>                   and semantics would benefit efforts
>                   >>>>>  such as those.
>                   >>>>
>                   >>>>Agreed. As I mention elsewhere,
>                   there is a greater influence on the
>                   >>>>prototype dREL (arising from the
>                   initial Jython implementation), and
>                   >>>>the list and table data types
>                   doubtless arise from that also.
>                   >>>>
>                   >>>>It might be worth remarking (again)
>                   that dREL is being developed as a
>                   >>>>canonical methods description
>                   language, and not necessarily the
>                   runtime
>                   >>>>methods evaluator of choice for
>                   future applications. It may be that in
>                   >>>  >practice future methods are
>                   initially developed and most frequently
>                   >>>>executed directly in Python or some
>                   other language. As I see it, the
>                   >>>>goal of CIF and DDL evolution is not
>                   to exclude such a possibility.
>                   >>>>
>                   >>>>Regards
>                   >>>>Brian
>                   >>>>_______________________________________________
>                   >>>>ddlm-group mailing list
> >>>><mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto
> 
> :ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.or
>
>                   g>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
> >>>><<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.i
> 
> ucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listin
> 
> fo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://
> 
> scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailma
> 
> n/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>
>
>                   http://scripts.iucr.org/mailman/listinfo/ddlm-group
>                   >>>
>                   >>>
>                   >>>--
>                   >>>=====================================================
>                   >>>  Herbert J. Bernstein, Professor of
>                   Computer Science
>                   >>>    Dowling College, Kramer Science
>                   Center, KSC 121
>                   >>>        Idle Hour Blvd, Oakdale, NY,
>                   11769
>                   >>>
>                   >>>                  +1-631-244-3035
>                   >>>
> >>><mailto:<mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@d
> 
> owling.edu>yaya@dowling.edu><mailto:<mailto:yaya@dowling.edu>yaya@dowling.e
>
>                   du><mailto:yaya@dowling.edu>yaya@dowling.edu
>                   >>>=====================================================
>                   >>>_______________________________________________
>                   >>>ddlm-group mailing list
> >>><mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:
> 
> ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org
>
>                   >ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
> >>><<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iu
> 
> cr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinf
> 
> o/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://s
> 
> cripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman
> 
> /listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>h
>
>                   ttp://scripts.iucr.org/mailman/listinfo/ddlm-group
>                   >  >>
>                   >>>
>                   >>>_______________________________________________
>                   >>>ddlm-group mailing list
> >>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-gro
>
>                   up@iucr.org>ddlm-group@iucr.org
> >>><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iuc
> 
> r.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo
>
>                   /ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>                   >>
>                   >>
>                   >>--
>                   >>=====================================================
>                   >>  Herbert J. Bernstein, Professor of
>                   Computer Science
>                   >>    Dowling College, Kramer Science
>                   Center, KSC 121
>                   >>        Idle Hour Blvd, Oakdale, NY,
>                   11769
>                   >>
>                   >>                  +1-631-244-3035
>                   >>
> >><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.ed
>
>                   u>yaya@dowling.edu
>                   >>=====================================================
>                   >>_______________________________________________
>                   >>ddlm-group mailing list
> >><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-grou
>
>                   p@iucr.org>ddlm-group@iucr.org
> >><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr
> 
> .org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/
>
>                   ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>                   >>
>                   >>
>                   >>_______________________________________________
>                   >>ddlm-group mailing list
>                   >><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
> >><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.
>
>                   org/mailman/listinfo/ddlm-group
>                   >
>                   >
>                   >--
>                   >=====================================================
>                   >  Herbert J. Bernstein, Professor of
>                   Computer Science
>                   >    Dowling College, Kramer Science
>                   Center, KSC 121
>                   >        Idle Hour Blvd, Oakdale, NY,
>                   11769
>                   >
>                   >                  +1-631-244-3035
>                   >                 
>                   <mailto:yaya@dowling.edu>yaya@dowling.edu
>                   >=====================================================
>                   >_______________________________________________
>                   >ddlm-group mailing list
>                   ><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
> ><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.o
>
>                   rg/mailman/listinfo/ddlm-group
>                   >
>                   >
>                   >_______________________________________________
>                   >ddlm-group mailing list
>                   >ddlm-group@iucr.org
>                   >http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
>
>                   --
>                   =====================================================
>                     Herbert J. Bernstein, Professor of
>                   Computer Science
>                       Dowling College, Kramer Science
>                   Center, KSC 121
>                           Idle Hour Blvd, Oakdale, NY,
>                   11769
>
>                                     +1-631-244-3035
>                                     yaya@dowling.edu
>                   =====================================================
>                   _______________________________________________
>                   ddlm-group mailing list
>                   ddlm-group@iucr.org
>                   http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
>
>     ____________________________________________________________________
> 
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
> 
> 
> 
>
_______________________________________________
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.