[DAS2] curation history and splits&merges

Andrew Dalke dalke at dalkescientific.com
Fri Feb 10 15:49:10 UTC 2006

We talked some on tracking curation history.

We decided it was a hard topic and we would defer further
discussion to the next sprint.  We're getting rather
frazzled here after nearly 5 days of hard work.

Here are some things that came up.

The writeback delta needs a field for user comments.

How persistent is an identifier for an object?  Is
it for the exact version of a feature or is it for
the concept of a the given feature?

That is, if there's a feature change the server could
assign it a new id/url.  It would need to tell the
annotation about the new id, just like it tells the
client about the newly created ids.

This makes updates more like a changeset version control
system, where there is a version number for each stable
data set.  Compare to CVS where there is a version number
for each file/record but not for the whole system.

But the current Otter database is more the CVS route.
While the changeset version seems nicer, there will
be some (I assume non-trivial) work to make Otter support

There are advantages.  You could do searches with
timewarps by using a "changeset=" parameter in the
query.  The DAS mechanism handles that just fine,
since interlinks between no-longer current URLs would
be correct.

There needs to be a way to get the history of an
element. There are two thoughts:

   - put the curation history in the feature document (via
some embedded XML)

   - link to a URL which provides the curational history
document for the given element

We prefer the latter.

For splits and merges there needs to be support in
the delta to say if there is a relationship to existing
or about to be deleted features.  We did not work on
that, other than to get a feel that it works.

Again, no server handles this so we decided it table it
for the future, and work on it more for the next sprint.

					dalke at dalkescientific.com

More information about the DAS2 mailing list