[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: _atom_site_aniso_label is broken
- Subject: Re: _atom_site_aniso_label is broken
- From: "Herbert J. Bernstein" <yaya@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 23 Jun 2005 09:01:41 -0400
- In-Reply-To: <20050623113720.GB14599@emerald.iucr.org>
- References: <Pine.LNX.4.62.0506201006460.1008@mostaccioli.csse.uwa.edu.au><1119244417.23197.73.camel@anbf10><Pine.LNX.4.62.0506201352580.1008@mostaccioli.csse.uwa.edu.au><1119254820.23197.108.camel@anbf10><Pine.LNX.4.62.0506201639000.1008@mostaccioli.csse.uwa.edu.au><1119335990.25566.69.camel@anbf10><Pine.LNX.4.62.0506211527170.16290@mostaccioli.csse.uwa.edu.au><1119342204.25566.105.camel@anbf10><Pine.LNX.4.62.0506211627260.16290@mostaccioli.csse.uwa.edu.au><1119344398.25566.118.camel@anbf10><20050623113720.GB14599@emerald.iucr.org>
Even the DDL2 appraoch has its denormalized compromises (vis the complexity of the atom_site list). A good data framework supports the presentation of data in denormalized form, but validates against an explicit or implicit fully normalized model, so that data can be handled in a relational database when needed. Lots of data presentations that look superficially anthetical to the relational model actually are not. Examples include the joined tables of the atom_site lists in both core_cif and mmcif, and the repeated tags and order-dependence of the internal publication process CIFS used at the IUCr. We need to show respect for the historical path to our current state to the extent that we need to be able to process existing CIFS within the context of any new system and provide a smooth transition path for users of existing software packages, but we also need to focus on the needs of our community for data representations and tools that will facilitate the creation, retrieval and analysis of the increasingly valuable data we all work with. -- Herbert At 12:37 PM +0100 6/23/05, Brian McMahon wrote: >Apologies for the slow response - as David mentioned, I've been tied up with >knotty hardware problems in the office, as well as being out of the office >at a meeting. I was surprised that Syd had not responded, but it turns out >that he isn't subscribed to this list. > >I'm exploring the issue now with Syd, because there is a possible impact on >the way this is explained in Volume G, which is now only days away from >going to press. I hope that one or other of us can report back within a >couple of days once we've analysed the problem and the suggested response in >some detail. > >I should say that I think James is doing a valuable service here: the final >form of DDL1.4 was elaborated in the circumstances that David described, but >there never has been, to my knowledge, a proper attempt to implement >software able to validate completely against that specification. Without a >reference implementation, there has always been a possibility - indeed >likelihood - that there were errors. > >Herbert is right in claiming that DDL2 comes close to being a normalized >relational database model, and we can be fairly confident that the aspects >of DDL2 that reflect this have been well tested in practice, because the PDB >are running large-scale relational database applications that use them >directly. It's possible, though, that DDL2 retains material imported from >DDL1 to ensure compatibility, but which has never been tested in >implementation and so may also contain errors. > >However, it also seems to me that within this group there is support for a >data model that is not that of a normalized relational database - Brian >Toby's arguments strike a sympathetic chord. DDL1.4 distanced itself from >being a complete relational model to accommodate that. In defining a future >development path for DDL applications, COMCIFS needs to consider (helped >greatly by the sort of input that this group is providing here) how >such flexibility can be retained. Personally, I don't discount the >possibility that we may need to continue to support DDL1.4, though >perhaps in the longer term only for a subset of CIF applications. After >all, whatever anyone ould like to see, the established software packages >will continue to pump out large numbers of (ostensibly) DDL1-compliant >CIFs for years to come. For that reason I think it's good to know if DDL1 >does offer a fully workable framework for validation, or whether some of >the attributes it provides are in fact broken The better we understand >why some applications cannot (or should not) conform to a relational >data model, the better placed we will be to determine the best way to >handle them. > >Best wishes >Brian >_______________________________________________ >cif-developers mailing list >cif-developers@iucr.org >http://scripts.iucr.org/mailman/listinfo/cif-developers -- ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 Office: +1-631-244-3035 Lab (KSC 020): +1-631-244-3451 yaya@dowling.edu ===================================================== _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- References:
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Brian McMahon)
- Prev by Date: Re: _atom_site_aniso_label is broken
- Next by Date: Re: _atom_site_aniso_label is broken
- Prev by thread: Re: _atom_site_aniso_label is broken
- Next by thread: Re: _atom_site_aniso_label is broken
- Index(es):