Discussion List Archives

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

Re: The meaning pf "categories"? [Was: Re: Please advise regarding adesign of CIF dictionaries for material properties]

  • To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
  • Subject: Re: The meaning pf "categories"? [Was: Re: Please advise regarding adesign of CIF dictionaries for material properties]
  • From: Nick Spadaccini <nick@csse.uwa.edu.au>
  • Date: Mon, 03 Oct 2011 11:04:19 +0800
  • In-Reply-To: <4E88711D.6010205@ibt.lt>
On 2/10/11 10:11 PM, "Saulius Grazulis" <grazulis@ibt.lt> wrote:

>> Again prop_ is a prefix, not something one would define as the category.
>> From the papers and the on-line information on CIF and DDL that are
> accessible to me, I have got an impression that the term "category" is
> used in two relatively unrelated meanings:
> a) DDL1 and increasingly DDLm use the "category" term to group related
> items into categories, so that their attribute descriptions must not be
> repeated. A category<->subcategory relation is then similar to a
> "class<->subclass" relation on OO programming languages; DDL2 uses
> "category group", "category" and "subcategory" terms for this. "parent"
> and "child" in this context describe superclass and subclass relations;

Originally DDL1 was a flat, no category structure, in much the same way as
you have been using it. Over time (and influenced by the mm community)
categories came in to it as a was of group data items which were related
together. To be honest apart from a convenience I am not sure how much
planning has gone in to DDL1 categories and how to use them. But they do
provide a very simple abstract model.

In DDLm we have developed a much more expansive syntax and semantics to the
language. A hierarchy of categories and sub-categories in the full sense of
building trees, encapsulation of data/definitions in to frames and nested
frames, keys both primary and foreign, automatic natural joins on
parent-child categories of a particular types etc. So there is a quite
abstract model that over lays DDLm, which can be mapped in to any concrete
model you want. A relation-model or a class/subclass OO model both naturally
fall out of a dictionary in DDLm.
> b) DDL2, by insisting on "category" <=> "single CIF loop_" equivalence
> supposes that a "category" is essentially a "single relational database
> table"; "parent" <-> "child" relations in this context are what the
> RDBMS people would call "primary key" <-> "foreign key relations". The
> terms "parent" and "child" might be unrelated to their usage in case a)
> Is that true - is my understanding correct? If not, may I please ask for
> some clarifications where I am wrong?
> If b) is the case, dose it mean that DDL2 dictionary becomes essentially
> a RDBMS scheme?

DDL2 IS a purely relational model in the RDBMS sense. This has always been
my difficulty with DDL2. There is no question it works well for mm people
and in particular the PDB. I have no complaints about what DDL2 is for that
community and the enormous contribution it makes to their function.

However it is a concrete (back end) model for implementation (relational
tables), that is constrained on the data representation at an
exchange/archive level. If you are not going to adopt a relational model for
implementation then DDL2 obfuscates what you need to represent.

A purely abstract model at the DDL level is needed if you are going to
require the seamless translation in to any number of possible concrete
back-end models.



Associate Professor N. Spadaccini, PhD.
Adjunct Research Fellow
The University of Western Australia
35 Stirling Highway
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au

Reply to: [list | sender only]