Complexity of SDD format

Gregor Hagedorn G.Hagedorn at BBA.DE
Wed Aug 27 12:37:31 CEST 2003


my apologies to all list members for dropping out of the discussion
for almost 5 months. I was overwhelmed with other work and could not
get out of just feeling guilty but not picking the work up again. I
am back from other work and also just back from vacation.

Steve Shattuck wrote:

> Kevin is pretty much right that I see the main use of SDD as
> documenting essentially finished data rather than a "work in
> progress".  My thinking is that most people will work on their dataset
> until it's finished, then make it available through SDD to other
> interested parties.  My assumption is that most collaborative projects
> will select a single tool to use while building the dataset (be it
> DELTA, LucID, DeltaAccess or what ever) and will use the native format
> of this application to share data.

> Now, I have no problem with capturing details needed by specific
> situations or applications and would say that these are important and
> should be support by SDD.  However, I would try to make them
> extensions to the basic, core data rather than part of the core
> itself.

I agree with your concern about complexity. It already shows that the
complexity present is difficult to document. We urgently need more
introductory material.

However, I disagree about the notion of "finished datasets". I may be
wrong, but I think that this is a thing of the past. The current
process of publishing scientific information in unchangeable batches
is primarily a function of the process of publishing printed
materials, which are difficult to revise. I believe in the future we
will move into continuously updated and revised versions. The
granularity in terms of time may be months or years, but not decades
as it is currently the case.

Especially when I am thinking about collaboration I am thinking not
about 2 or 3 people working closely, but a loose network of
collaborators. That also includes that datasets are passed on from
one generation to the next. If some researcher created a very
valuable dataset as a finished work, then retired and a new Ph.D.
candidate revises this dataset, it will be irrelevant whether
creation and intellectual property details are in the SDD set.
However, the outcome of this will be a dataset perhaps 5% improved,
95% original material. Now I believe it is undesirable to pass the
entire dataset on to the next reviser without any indication of what
happened. In this second step, I believe it is the task of the SDD
exchange format to record some fundamental attribution of
intellectual property.

I am, however receptive to wisdom that caring for this (web updated
data etc.) makes our task too complicated.

> This leads to two thoughts:
> First, it is crucial for SDD to be the product of a team with
> differing views who work together towards some middle ground.
> Otherwise it is unlikely that it will meet the needs of the broader
> community.
> Second, I worry about SDD becoming too specialised and too complex.
> The "joy" of the DELTA standard is its simplicity.  And this
> simplicity is, I would say, one of the reasons it has been so
> successful.  I would contrast this with the Nexus format.  Nexus is
> only seriously being used by the 3 or 4 applications involved in its
> original development.  It is hardly a "standard" outside this small
> community.  The power of Nexus is that it supports essentially all of
> the features of these original applications.  This seems to be the way
> SDD is heading: support all of the features of character-based
> programs that currently exist.  My concern would be that if we do this
> we will be the only people who use SDD, new players finding the format
> so complex and so specialised that it's expensive to implement and has
> little flexibility to support "extensions" outside of the strict
> standard.  If this is true and is realised we all lose.

Here I would maintain that we do you existing programs to help us in
finding the requirements, but that the presence of a feature in a
program never had any bearing on whether it should become a feature
of SDD. Rather the argument always is: Is there a need to exchange
such data, do these data describe scientific information or
management information that should be interoperable as metadata of
the scientific process. Quite a number of DeltaAccess features are
NOT or completely differently supported in SDD.

The concern about complexity is correct, however.

A call to everyone: Please do join the TDWD /SDD meeting in Lisbon,
21-26 October of this year, to help us finding a good compromise!

(Please inform me by direct mail if you are likely to come)

Gregor Hagedorn (G.Hagedorn at
Institute for Plant Virology, Microbiology, and Biosafety
Federal Research Center for Agriculture and Forestry (BBA)
Koenigin-Luise-Str. 19          Tel: +49-30-8304-2220
14195 Berlin, Germany           Fax: +49-30-8304-2203

Often wrong but never in doubt!

More information about the tdwg-content mailing list