Discussion List Archives

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

Re: [ddlm-group] Objectives of CIF2 syntax discussion

If the CIF1 interoperability with DDLm is an absolute given, we should
be able to work things out.  That may or may not require changes in
CIF2, but I am fairly sure it will require some new hooks in
dREL and DDLm to be able to work fully with CIF1 tags.  Perhaps
I've missed those hooks.

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
                  [email protected]
=====================================================

On Wed, 19 Jan 2011, James Hester wrote:

> Dear all, I've changed the subject line.
>
> I believe that the objectives of the CIF2 discussion are as follows:
> (1) Alter CIF1 syntax to accommodate DDLm and dREL
> (2) Take the opportunity to improve CIF1 syntax to provide a net
> benefit to the community
>
> If you like, we can include the constraint from the IUCr website that
> "No changes are required in existing archival data files in order to
> apply domain dictionaries written in DDLm", although I take this as a
> statement of fact arising out of DDLm, not syntax.
>
> What has to be done for (1) is not contentious.  Decisions on what to
> do for (2) are, because they involve cost-benefit analyses taking into
> account the various communities that Herbert has identified.  Because
> these assessments of cost/benefit are so dependent on the value that
> we place as individuals on various aspects of CIF use, our discussions
> have been long and not all decisions are necessarily to everybody's
> liking.  But those decisions do represent a set of compromises that we
> have reached as concerned and involved CIF users.  They thus reflect a
> collective wisdom, and reopening discussion of them is likely to be
> unproductive and time-consuming due to the many imponderables
> involved.  I would therefore urge anybody with a wishlist of changes
> to the current CIF2 standard to stop and ask themselves how successful
> they expect to be in convincing a majority of voting members to change
> their mind.
>
> James.
>
> On Sun, Jan 16, 2011 at 11:26 PM, Herbert J. Bernstein
> <[email protected]> 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 ...)
>
> CIF in general is quite widespread as a format for transfer of
> crystallographic data, both for submission to databases and input to a
> myriad of niche programs.
>
>> 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
>
> I agree with 1 and 2.  I don't agree with 3 as an objective, because
> it is in direct conflict with (1) as no CIF1 software will be able to
> read CIF2 list structures.  I would drop (3), and simply let objective
> (4) carry the weight, that is, make the changes that are necessary to
> software and archives as clear and simple as possible.
>
> I have no objections to 4 or 5.
>
> I believe that the current CIF2 standard fulfills (1) and (2)
> completely as I have explained in other emails today.  The changes
> needed to current parsers are limited to small, easily understood
> additions or changes, so (4) is satisfied.  (5) is met by the addition
> of Unicode (and I've already had plaudits from a European CIF user for
> this change) and the removal of the unusual embedded quotes in
> single-quoted strings.
>> 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
>> � � � � � � � � [email protected]
>> =====================================================
>>
>> 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 <[email protected]>
>>> To: Group finalising DDLm and associated dictionaries
>>> <[email protected]>
>>> 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 <[email protected]>
>>>> To: Group finalising DDLm and associated dictionaries
>>>> <[email protected]>
>>>> 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:[email protected]>[email protected]>
>>>>> To: Group finalising DDLm and associated dictionaries
>>>>> <<mailto:[email protected]>[email protected]>
>>>>> 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:[email protected]>[email protected]
>>> om><mailto:[email protected]>[email protected]>
>>>>>> To: Group finalising DDLm and associated dictionaries
>>>
>>>>>>>>> <<mailto:<mailto:[email protected]>[email protected]><mailto:ddlm-gr
>>> [email protected]>[email protected]>
>>>>>> 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:[email protected]>[email protected]><mailto
>>>
>>> :[email protected]>[email protected]><mailto:<mailto:[email protected]
>>> g>[email protected]><mailto:[email protected]>[email protected]
>>>
>>>>>>>>>>> <<<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:[email protected]>[email protected]><mailto:yaya@d
>>>
>>> owling.edu>[email protected]><mailto:<mailto:[email protected]>[email protected]
>>> du><mailto:[email protected]>[email protected]
>>>>>> =====================================================
>>>>>> _______________________________________________
>>>>>> ddlm-group mailing list
>>>
>>>>>>>>> <mailto:<mailto:<mailto:[email protected]>[email protected]><mailto:
>>>
>>> [email protected]>[email protected]><mailto:<mailto:[email protected]
>>>> [email protected]><mailto:[email protected]>[email protected]
>>>
>>>>>>>>> <<<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:[email protected]>[email protected]><mailto:ddlm-gro
>>> [email protected]>[email protected]
>>>
>>>>>>>>> <<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:[email protected]>[email protected]><mailto:[email protected]
>>> u>[email protected]
>>>>> =====================================================
>>>>> _______________________________________________
>>>>> ddlm-group mailing list
>>>
>>>>>>> <mailto:<mailto:[email protected]>[email protected]><mailto:ddlm-grou
>>> [email protected]>[email protected]
>>>
>>>>>>> <<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:[email protected]>[email protected]
>>>
>>>>>>> <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:[email protected]>[email protected]
>>>> =====================================================
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> <mailto:[email protected]>[email protected]
>>>
>>>>> <http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.o
>>> rg/mailman/listinfo/ddlm-group
>>>>
>>>>
>>>> _______________________________________________
>>>> ddlm-group mailing list
>>>> [email protected]
>>>> 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
>>> � � � � � � � � � [email protected]
>>> =====================================================
>>> _______________________________________________
>>> ddlm-group mailing list
>>> [email protected]
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>
>> _______________________________________________
>> ddlm-group mailing list
>> [email protected]
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>>
>
>
>
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
[email protected]
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