Re: Model Hierarchy in mmCIF

• Messages sorted by: [ date ][ subject ][ author ]
• Previous message: Dale Tronrud: "Model Hierarchy in mmCIF"

While I personally like the clarity and representational efficiency
of the name.variant notation, this would seem to be a signficant
drift away from the strict tag, value alternation style of DDL2.
(e.g. note the change from value(esd) in DDL1 to value and esd
as distinct (albeit related) item values in DDL2).  Also, the
character "." has meaning in many contexts.  However, I'd really
like to be able to use this name.variant construct.  So, perhaps
the DDL2 folks might accept a special shorthand notation, where
    item_name_tag  item_name_value/item_variant_name_value
would be considered a shorthand for
    item_name_tag  item_name_value
    item_variant_name_tag item_variant_name_value
where the item_variant_name_tag would be required to be associated
with the item_name_tag by appropriate new _item_related.function_code
values.  Where such a declaration had been made, then
    item_name_tag  item_name_value
would always be treated as if
    item_name_tag  item_name_value
    item_variant_name_tag   .
had been entered.

I realize that what I have just said is a DDL2 more than an mmCIF issue,
but I raised it in the hope we could concentrate on the right
rules for the "variant" use, rather than on the syntax of presentation.

On that point, forgive me for raising an objection to the rigid
requirement for strict parallelism among variants.  I suspect we will
end up tripping over that restriction.  There is no physical reason
why multiple variants have to have identical sequences, or, even
the same numbers of residues.  The identical cases are certainly the
easiest models to deal with, but, if possible, it might be best
to allow some slack for minor or even major variations in the
representational approach right now.  

• Previous message: Dale Tronrud: "Model Hierarchy in mmCIF"