Discussion List Archives

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

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

On Wednesday, January 19, 2011 3:47 PM, Herbert J. Bernstein wrote:
>   The definition_id most certainly does not exhibit the tag
>style.  For example, there is no way to distinguish DDLm
>tag style from DDL2 or DDL2 tag style from context.  That
>is intentionally inherent in the design of DDLm.

Then I'm afraid I don't quite comprehend the meaning of "tag style".  I would like to do, so that I can form a well-founded opinion about it.

As I thought I had understood the idea, the tag style is proposed to identify the set of DDL conventions with which the given alias complies.  If that were indeed what it was intended to mean, however, then (1) as you observe, some names would comply with more than one set of conventions, but also (2) a set of candidate tag styles, at least, could be generated could be computed for any alias name.

What would be the significance of marking an alias that conforms with both DDL2 and DDLm conventions with tag style DDL2?

Might it ever be needful or useful to mark the same alias with more than one tag style?

>   As for defining a hypothetical URI, that can break,
>or each least time-out programs trying to get additional
>information about an aliased tag from that URI.  URIs
>should be for things that really exist on the web,
>not a substitute for a tag that really defines something
>different, in this case the style of tags.

I don't think the issue is nearly so clear cut.  I would hold, for example, that the primary purpose of a URI is to *identify* a resource.  That's what the "I" stands for, as I'm sure you're aware.  RFC 3986 (Uniform Resource Identifier (URI): General Syntax) explicitly provides that a URI may identify an abstract resource.  RFC 2396 (now obsoleted by 3986) says the same.  Although many URIs fulfill their purpose by serving as resolvable web addresses, some, even among those formatted as URLs, do not.  Examples of the latter abound in various XML communities.

Personally, however, I think a bit more like you do: a URL ought to refer to a retrievable resource on the web.  For an abstract or virtual resource, therefore, I prefer to use a URN.  For something like your virtual DDL1 imgCIF dictionary, I might choose something like urn:x-imgCIF:DDL1.  If a URN were used, then programs assuming a resolvable URL might still break, but only if they were poorly crafted indeed would they hang pending a time out.  The whole issue could largely be mooted by clarifying the purpose and intended usage of _alias.dictionary_uri in its definition.  That need not prevent programs from attempting to resolve dictionary URIs, but if it specified that dictionary URIs might be permanently unresolvable then programmers would know to prepare for that possibility.

>   We already do something very similar to this with
>alternate conformers and with NMR model numbers.  It
>really is a simply concept for organizing information
>that belongs in groups, in this case the group of
>DDL1 or DDL2 or DDLm or ... style tags.

I think that makes it a bit clearer to me what you want to do, but I'm still interested in the answers to my questions above.  I'm a bit uncomfortable with defining generic groups of aliases with per-dictionary semantics, if that's indeed what you're proposing.  For one thing, it does not play well with dictionary merging.  For another, the meaning of the groupings is nowhere defined, at least not without adding at least one more data names to DDLm for that purpose.

On the other hand, data names have at least one natural grouping: the dictionaries in which they are defined.  This grouping is already modeled in DDLm, and as far as I can tell, it is conceptually a perfect fit for what you want to do.

That doesn't necessarily mean that there is no use for a more general grouping mechanism.  I am curious indeed whether there are use cases for grouping data names that do not align well with dictionaries or dictionary-defined attributes.  Can anyone suggest some?

>  It solves
>a very real problem for me with imgCIF.  It does
>not harm to anybody else.  If nobody uses it in
>another dictionary, it still would have been a useful
>addition to DDLm.

I very much want you to have a solution to your problem, and I have suggested one that still seems absolutely natural to me.  It may be that there are better alternatives, and perhaps even that tag style would be one such.  Of the latter, however, I am not yet persuaded.

Perhaps "harm" is too charged a word, but adding an additional attribute to DDLm certainly does cost everyone else.  Every DDLm application must support all the DDLm attributes, so every additional attribute places a development and maintenance burden on multiple developers.  That incrementally slows software release cycles and introduces additional space for bugs and incompatibilities to hide.  It's a small cost for most people, but everyone pays it.  The proposed tag style is no different in that regard from any other DDLm attribute, of course, but that doesn't mean that its cost should be ignored.

As for whether it would be a useful addition to DDLm, that is exactly what I am trying to decide.  Potential use cases such as I solicited above would help me make that decision.

>   In the end, I suspect that both core and mmCIF DDLm
>dictionaries will be built this way, because it
>make it simpler and clearer and allows multi-purpose
>dictionaries to be self-contained and avoid the
>maintenance headache David spotted.

If by "multi-purpose dictionaries" you mean defining multiple virtual dictionaries via a single DDLm dictionary, such as you plan, then I still see the dictionary_uri as the natural way to use aliases for that purpose.  If there is a broader concept here then please help me see it.



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

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.