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 James,

   All of this is fascinating, and the factual bakground, I do not dipute. 
Where we differ is on what is important and relevant to our actions. The 
factual history does not answer the question of what our goals are and 
what our priorities are among those goals in the exercise we are currently 
doing -- which is to define CIF2 and its relationship to DDLm 
dictionaries.  Are we or are we not trying to define a structure in which 
we can apply the new DDLm dictionaries to archived CIF1 documents as 
promised on the IUCr web site?

   If our goals are as listing in my message of Sunday, 16 Jan, then I 
think we really do need to revisit _all_ the past decisions on CIF2, 
because I think we have drifted very far from those goals.  If the goals 
are in dispute, then we need to work on finding a common set of goals.

   As for the issue of executable documents.  I see DDLm as, in a modest 
way making CIFs into executable documents in ways that help to reach the 
state goals, but also has providing the critical and important first steps 
towards having fully executable documents, a very important recent 
initiative in scientific publishing.  Why would be want to cut off that 
possibility for the IUCr, which is a major scientific publisher?

   Even if we restrict our attention to just what dREL and
DDLm currently provide, one of the features is to populate missing
values, a very useful feature that goes beyond simple validation
and is, indeed, an executable document feature.

   Is James saying that, in addition to having dropping full CIF1 
compatibility, we are also dropping full DDLm/dREL functionality.
I hope not.

   I know this is all very stressful, but I believe we may have
made a whopping big mistake is allowing CIF2 to become so
imcompatible with CIF1, and need to carefully recheck if
all the points of divergence are necessary to achieving our
goals.  I suspect we can achieve close to full compatibility
between DDLm and CIF1.

   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 Tue, 18 Jan 2011, James Hester wrote:

> There is a persistent misunderstanding of the different roles the
> various layers in the CIF framework play.  CIF2 is a syntax
> specification for serialising a collection of simple relational
> database structures.  As such, DDL dictionaries are also just
> relational databases.  Programs and people can use the information in
> the DDL dictionaries to check the validity of data files and
> dictionaries.  The innovation of dREL is to provide a way of
> describing algorithmic relationships among relational database
> entries.  These algorithms can be translated and used by programs.
>
> I hope this description captures the elegant simplicity of the CIF
> framework.  To start to talk about making these databases executable
> or making the database serialisation protocol a program at best makes
> very little sense and at worst pollutes the clear demarcation lines
> between the components.  Each component in the framework is optimised
> for the role it plays, relatively simple to understand (I had thought)
> and largely insulated from changes in any of the others.
>
> Anybody (and I have been among those people) who thinks that dREL
> should just be replaced by some well-known programming language fails
> to understand the function that it carries out and the context in
> which it executes.  For instance:
>
> (1) dREL is optimised for relational database work, in particular:
>      - dREL has very neat syntactic sugar to allow indexing items
> between categories using category keys
>      - dREL introduces syntax for looping over categories
> (2) All dictionary datanames are automatically in scope
> (3) The dREL method does not have to concern itself with
> implementation details such as keeping track of which loop packet is
> currently calculating or throwing error messages.
> (4) Many features of a fully-blown programming language are not
> relevant or even dangerous in the dictionary context
> (5) There is no need for dREL to commit to a particular concrete
> implementation of the CIF datastructure.  Each dREL engine is welcome
> to optimise as it sees fit and convert the dREL method to one that
> works with whatever the native CIF datastructure is for a given
> application.
> (6) These methods are canonical in that they are going into a
> dictionary.  They should change over time as little as possible, and
> be as easy as possible to understand and create.
>
> What Nick et al did was to take Python, remove language features that
> were not necessary and add some syntactic sugar.  The result is an
> algorithmic language that elegantly expresses relationships within a
> relational database with minimum clutter and in a way that is
> hopefully reasonably accessible to dictionary writers, and didn't
> commit CIF to a particular language implementation or CIF
> implementation.
>
> Anybody visiting my poster in Osaka would have had a chance to get up
> close and personal with these issues.  I automatically translate dREL
> methods into Python, inserting print statements and whatnot, and then
> evaluate those Python chunks *after* making the appropriate variable
> initialisations.  Execution of each method is under control of a
> master program that determines which method to execute and keeps track
> of loop packet construction etc.
>
> I'll say it again: so far I've seen no sustainable argument for
> sending CIF2 back to committee, or for adopting Python string handling
> syntax into CIF2.
>
> On Sun, Jan 16, 2011 at 8:16 AM, Herbert J. Bernstein
> <yaya@bernstein-plus-sons.com> wrote:
>> 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
>>> 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
>>
>
>
>
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> 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.

Useful links