SDD proposal: Acknowledgment and documentation of intellectual contributions

TDWG working group: Structure of Descriptive Data (SDD)

Introduction

(Note: The following discussion is partly based on discussions at the SDD meetings in Brazil (2002) and Paris (2003). See also the proposal Intellectual Property documentation )

In large projects it is essential that the individual contributions can be traced to a certain extent and that the scientist responsible for a given part of the work is recorded. Two major aspects exist:

the issue of recording and accrediting intellectual property rights (IPR)
the management aspect

To some extend these two aspects are interwoven and are therefore treated together. Occasionally it will be important, however, to distinguish them.

The dominant aspect is the IPR, and here in contrast to most commercial operations, not even the legal aspects of IPR. Rather, to be promoted or even allowed to continue, most scientists must be able to document their work in the form of publications (printed or digital). Large database projects must be able to generate web pages that can be cited to proof the individual contributions.

Work on a project that is collecting and revising descriptive data has many aspects and phases. After the initial phases of conceptually defining the scope of the project and the terminology to be used, the work on the descriptions consists of:

data collection (original data, retrieval of publish data)
data input
- selection of data to enter
- typing
- proofreading of data
interpretation
- scientific interpretation of data
- critical review of interpretations
editorial synthesis work
- gap analysis (which data are missing)
- formal editorial work (e. g. improve terminological consistency)

In practice most of these steps are difficult to distinguish. Data typing and interpretation are difficult to separate if the terminology of information source and data model differs, most proofreading occurs as a by-product during interpretation and revision, etc. A data model that would require the contributor to a project to evaluate their own work with respect to such a classification would probably be very hard and ungratifying to use for scientists.

Data collection is especially problematic. The information source itself is recorded in the form of a citation of a publication resource (see @@@). However, the effort to find appropriate data sources at all is not directly visible in any object in a descriptive database. It is intimately related with the data input, which creates the first object.

It is possible to distinguish between a person that is responsible for the selection of data, and another person that does the typing work. The DiversityWorkbench model (@@) distinguishes in general between a responsible person and an operator, and always uses a double login. That is, an non-scientist operator may work for different responsible scientists, and a responsible scientist is logged in as both operator and responsible person.

Whether such a distinction should be entered in the SDD model should be discussed [@ Open Question @]. The experience with the DiversityWorkbench projects has proven it to be very useful. It should be noted, however, that tracing the typist's names is exclusively a management problem, and not related to intellectual property rights. Furthermore, pure typing work is perhaps relatively rare in descriptive data.

Granularity of accreditation

Depending on the scale of the project, several solutions offer the best balance between efficiency of work (avoiding management overhead and time consuming recording of meta data) and accuracy of IPR documentation:

For small to moderate-sized projects the author team model is ideal. The individual contributions are not differentiated or documented, which requires an advance agreement about the work share and reciprocal trust among all team members. A differentiation is possible only insofar that the first author is expected to have made a larger contribution than the others (occasionally it is also assumed that the last author is only the head of the departement... :-) @@need to delete that later@@@)
For larger projects, where individual contributions can not be agreed upon in advance, or where the contributions are too unequal to allow the handling as a team, a shared work model is best. In this model all contributors work on the same piece of work and each atomic contribution is (usually automatically by the application) marked as a contribution from one of the collaborators. The collaborators attempt not to duplicate the work of others or contradict each other; a necessary correction of someone elses work is assumed to be a correction of errors, not scientific dispute. If dispute is unavoidable, it is settled separately outside of the descriptive information system. This system requires a substantial mutual trust among participants. Occasionally it can be irritating to find that some data oneself has entered has been "improved" by another collaborator. In general, however, these improvements will much more frequently correct real errors than erroneously deteriorate the data quality.
Finally, for huge collaborative projects which are held to together not by mutual trust, but by other benefits of working in a common system, a "private workspace" model is preferable. Here each scientist is able to see the results of other scientists, and to profit from peripheral resource information added to the system by any collaborator (e. g. publications, media, etc.) but has a private workspace with data that only she or he can revise. It become now the option of the scientist whether to add data in duplicate to show that one is in agreement and would have entered it oneself if somebody else had not yet done so - thereby guaranteeing that no change by another person will affect ones own data. Even if data are entered in duplicate, each collaborator benefits from data that are already there, by reducing errors or speeding up the data entry. In this model an explicit contradiction mechanism is necessary, to state that some fact entered by another collaborator is considered to be erroneous.

(The terms "author team model", "shared work model", and "private workspace model" are introduced here for the purpose of discussion. I am grateful if somebody points out citable equivalent terms to me.)

The following example illustrates for states of a single character the differences between the 3 models:

Model:	"author team"	"shared work"	"private workspace"
Scientist 1: inserts state "x"	state x	state x	state x
Scientist 2: confirms state "x"	state x	state x	state x state x
Scientist 2: adds state "y"	state x state y	state x state y	state x state x state y
Scientist 1: contradicts state "y"	state x	state x	state x state x state y NOT state y

--------------------------

I have a strong dislike for the solution to allow metadata just everywhere. The reason for this is, that it is elegant when the data are captured, and it makes easy programming, but it reorganizing data pure hell. For every element with meta data the implications of making a change have to be analyzed carefully before making changes. I feel this would make it almost impossible to change the structure of SDD in a new version, even if we should find ourselves in error. I do not see that elements themselves have any meta data in itself. rather, the meta data refers to the container. There is no such thing as author of the character element itself, but there is a thing like author of everything that is contained within this element (including label, definition, etc.) The implications of having metadata on all kinds of hierarchies rather than on atomic elements to me is, that you cannot ever modfiy the hierarchy. If there is metadata on a character grouping, you can not reorganize characters without throwing away all metadata on them. I believe for each metadata instance we need a clear definition of what it means and what not. For instance, I believe that metadata on the description (former "item") should be understood to refer to the definition (taxon name, publication, specimen reference and item annotation, but not to the actual description itself, although this is contained in the same element. If this is done we keep a path open for future reorganizations. We could say metadata can exist only on simple types, but perhaps we should keep some items together. I do not think it is necessary to add metadata on for a state score on both the frequency upper and lower range values associated with the state. In fact I currently feel that allowing metadata ONLY on states in the description would be a good solution. ================================= From email with G: > > I do not see that elements themselves have any meta data in itself. > > rather, the meta data refers to the container. There is no such > > thing as author of the character element itself, but there is a > > thing like author of everything that is contained within this > > element (including label, definition, etc.) > I don't see any difference between the author of a book, and the > author of characters, plot and landscapes from the book. True. My problem is what if 100 authors each writes some paragraph in the book and 3 editors do work on different parts of the content, and the printer does work on the book. Now putting metadata on the book element probably needs explanation, and you cannot simply get away with saying "this is some kind of metadata on the book element". In my thinking the metadata are not meaningless, but you must differentiate between IPR metadata that mean: Covers this and all included content, and IPR metadata that mean: only covers this. Whenever data are reorganized, you must analyze this distinction in detail. =================================

Issues of versioning and recording user actions

(Gregor attempted to clarify the discussion on the next day in the following proposal. This material from Friday is shown here to keep it in the context:)

Collaboration is an issue of SDD, but on-line collaboration or concurrent multiusers working techniques are not. Issues like locking documents or parts of documents, checking data in or out of a versioning system (e. g. a CVS), transaction management or implementation of database replication are not issues for SDD data exchange. To perform/conduct interoperable data exchange using the SDD format, a descriptive data project must be in an exclusive state without locks or transactions.
Securing and encrypting data to prevent unauthorized access or data manipulation is not an issue to SDD. Manipulating data will always be possible in a non-encrypted xml document.
The documentation of the intellectual contributions of users working on the system is an issue for interoperability. This does not imply that security IDs need to be transferred, but the basic documentation of who made which intellectual contributions should be preserved when the data are moved from one application to another.
The date and time of contributions and alterations by the same person are currently not preserved in the general SDD format. A fully logged system, allowing to trace the history of any changes of the descriptive data over time may be desirable for some applications. In the current SDD process it is, however, considered an application specific property not subject to interoperability demands. If demand becomes greater and multiple implementations of this feature exist, a future version of SDD may deal with this problem. Checking xml-based SDD documents into a versioning system (e. g. CVS) may be a good implementation independent solution for tracking changes over time.
To some extent, management considerations are so basic that it is desirable to keep some management data interoperable rather than . This refers, for example, to revising and checking descriptive data. Also, this is both a management item and a piece of information to the enduser, helping in establishing the level of trust in a particular piece of information. Other management tools may be left to application specific data.
Versioning of the entire project is provided in the project definition.

The current project-based attribution schemes (as present in DELTA) makes it possible to work in small teams where all members know each other well, and where the relative share of the work is agreed upon in advance. However, even middle sized projects need to observe some management practices.

With multiple users, a scheme how to append and add to each others information is relatively easy, since the mechanism is identical to summarizing information from several specimens for a taxon descriptions. However, at the moment the question how to contradict each other is unresolved!

General problem: of attribution/accrediation of data origin/editing/analysis/intellectual property rights should be perfect here, the model easily becomes unmanageable, so we have to find a good compromise.

Request for discussion

Please send your criticism or suggestions to the SDD mailing list or to any of the authors.

Gregor Hagedorn; Vers. 1; 14. March 2003

Return to the SDD starting page.

First published 2003-03-14, last update: 2003-03-14.