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

Let's take a concrete example:  Suppose we want to use a DDLm method to 
populate _diffn_standards.decay_% in an mmCIF dictionary from the actual 
measured reflections (or, more elegantly as a long-term goal directly from 
the data in a scan of image frames).

That tag cannot be used directly in a dREL method. Under David and John's 
proposed use of the alias mechanism, what aliases would have appear where 
and to what should be method itself refer, and in what save frame would it 
be defined.  Ideally, we would like to be able to have this all gathered 
into one dictionary, and the dictionary merge mechanism allows us to do 
that, so whatever we propose should not depend on the name or type of the 
dictionary.

I can see how the alias mechanism can be used to validate the value.  I 
don't yet see how it can be used to generate the value using the illegal 
tag. If I understand the DDLm docuemnt correctly, to generate a value for 
a tag, the method has to be in the same frame defining that tag, but we 
seem to have barred this tag from being the name of a save frame in a 
CIF2-style DDLm dictionary.  If we were to go back to allowing all the 
valid CIF1 tags as tags in DDLm dictionaries, then this particular problem 
would go away with a little jiggering either of the alias mechsnism or by 
adding the import ... as ... to the methods. I think the import is 
cleaner, but I msay be wrong and look forward to seeing the alias 
solution. I am not sure I see any simple solution if we don't relax the 
tag restriction back to CIF1 rules, but again, I may be wrong.

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, Bollinger, John C wrote:

  

On Wednesday, January 19, 2011 7:37 AM, Herbert J. Bernstein wrote:

    

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.
      

I trust those here having more practical experience with DDLm and dREL to correct me where I am wrong, but as far as I can tell, DDLm's alias system provides all the needed hooks.  Here are some implied details that might clarify matters:

1) Each dREL method appearing in a DDLm data dictionary refers to CIF items exclusively in terms of those items' data names (not aliases), as defined in the dictionary in which the referenced items and the method's item all appear.

2) Where necessary, DDLm aliases bind the data names actually used in input data CIFs to the corresponding names defined in the dictionary.  This aliasing is transparent to dREL methods and to data validation procedures.

3) When needed, a DDLm-based system can automatically select an output data name for an item, based on the name of the dictionary in which the user expects the output name to be defined.  If the chosen dictionary is not the DDLm dictionary itself then the given dictionary name is used to select the appropriate alias from among those defined for the item in question.  This activity also is transparent to dREL, if not outside dREL's scope altogether.

All of that depends heavily on the content of the dictionary, but it appears fully supported by DDLm and dREL as presently defined. None of those operations inherently depend on details of CIF syntax.


It is possible that part of the problem here is a disagreement over the meaning of "CIF1 interoperability".  The above description explains CIF1 interoperability over the full breadth of DDLm / dREL design goals as I perceive them, but Herbert has expressed an interest in embedding script in data files, and perhaps his concerns arise from that direction.  As far as I can tell, that would be outside dREL's design parameters, but dREL could conceivably still be applied in such a context.  Details and any semantic differences would need to be defined in the appropriate data dictionary, however, not in that dictionary's DDL (whether DDLm, DDL2, or DDL1).  As stimulating as a discussion of that topic might be, I think at the moment it would go rather too far afield.


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
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group

    

_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group