OBIS publishes data on behalf of scientists from government agencies, museums, universities, commercial companies, and non-governmental organisations. OBIS is always seeking new contributors.

OBIS is a marine biogeographic information system, meaning that we concentrate on datasets that record particular species (or higher taxonomic group) from particular marine locations, at particular times. At present, we can only publish data where the locations are recorded as latitude and longitude, not as place names. Our focus is on high taxonomic quality, so datasets where organisms have been identified by professional or trained biologists are our priority. In the near future, we will be expanding to take in environmental datasets (i.e. coverage of physical, chemical, and geological parameters) that are relevant to understanding the distribution of species. So we are interested in hearing from potential contributors of these datasets, and welcome your contact, but are still in the process building this facility.

OBIS claims no ownership nor rights to the data sets it publishes. All rights remain with the data source, whom may at any time decide to remove their data from OBIS. This is true whether you serve the data yourself, or whether you place your dataset at a Regional OBIS Node or the central OBIS portal for serving.

There are two models for sharing data through the OBIS system:

• You become a distributed data contributor. This means that you keep your dataset locally, and set up a server that can respond to OBIS queries. This requires "mapping" your dataset to the OBIS schema (which is not as hard as it sounds!) and installing a free software package called DiGIR to communicate with the portal. There are more details on this below.

• You provide your data set in electronic form to a Regional OBIS Node, the central data portal, or another existing Data Provider, and it is published from there.

Which choice is right for you depends on whether you are interested in maintaining your own server, and also whether you expect to be making regular updates to the data set. OBIS prefers groups to be distributed data contributors, because we think it is best for the data contributor, who knows the dataset best, to maintain it. That way you can add data and make corrections directly. But if you cannot or do not wish to set up a server, OBIS is happy to host data. In either case the data will be credited to you.

The short answer is that OBIS is committed to free, open, public access to date, so if you have sensitive data you probably don't want to publish it through OBIS (or any other publication). However, there are some particular concerns we may be able to help with. For example, if you are concerned about giving the precise location of a rare or commercial species, then we may be able to represent your data at a lower spatial resolution, or to give a bounding box instead of a point location. If you have data that you would like to publish but want to wait until its analysis is published elsewhere, we can help you set up your dataset appropriately now, but agree not to publish it for a certain amount of time.

Please read the information about OBIS on this website, and contact the Executive Director of OBIS.

Think of the OBIS schema as a menu of options. There are only four fields that are required in order to be compatible (latitude, longitude, taxonomic name, and date/time of last modification). For all of the other fields you only need to include them if you want to have that information in your database. If you don't plan to hold a particular type of information, you can leave it out of your database. However, if you do include a type of information covered by a field in the OBIS schema, you should represent it as described in the OBIS schema.

No, you can use any field names you like. When you implement DiGIR, it will ask you to tell it which fields relate to which OBIS Schema field. You should keep track of this and make sure that there is a one-to-one mapping of fields in the OBIS schema to your database and that you use the required format for the field. For example, because the OBIS Schema has separate fields for day, month, and year of the record, it is best to hold these in three separate fields and not in a single date field (or at least have a plan for how to separate the pieces for serving to OBIS).

Note that most database software will allow you to do automatic operations on fields. You may prefer to enter your location information as degrees and minutes for latitude and longitude instead of decimal degrees. That's fine, because it will be easy for you to create a database view with a latitude field in decimal degrees calculated from (latitude degrees + (latitude minutes/60)).

It may be easiest for you to implement DiGIR by creating a "view" or query in your database that has all the OBIS schema fields in one table. You may have separate tables for "species names", "observations" etc., but may create one virtual view that does all the joins necessary for the OBIS query. You can also have it do any reformatting (such as the latitude degrees and minutes calculation mentioned in the above question) required. Then it will be easy during DiGIR installation to map onto the OBIS schema.

Because these are Darwin Core fields. To be compliant with the Darwin Core, OBIS must allow all Darwin Core fields to be entered. But remember, these are all optional fields. Don't even put them in your database if you don't need them - most OBIS datasets won't. OBIS operates off latitude and longitude locations, which are why these two are the only required locality information.

The OBIS databases hold information on the locations where different species have been found. The act of finding a species at a place is called a "collection" or an "observation" throughout the schema documentation. This term is meant to apply very broadly, and includes cases where species were literally seen during a visual search, were collected in a sample of any kind (research survey, fisheries catch date, etc.), where a specimen in a museum indicates the location where it is from, etc.

Yes, the OBIS Schema can accommodate data from multiple observations of a single individual organism, such as data produced by tagging studies. To implement this, the user should 1) create a record in their database for the individual and use the Catalog Number as a unique identifier for that individual; and 2) each observation for that individual should be entered as a separate record in the database and tied to the individual by setting the Related Catalog Item field equal to the Institution Code, Collection Code, and Catalog Number of the individual record, and the Relationship Type field to 'point observation for tagged animal of.' (see the Technical Resources page for more on the OBIS Schema fields).

First, figure out what information you have or plan to have. If you already have datasets, either in electronic or paper formats, look at the data that are included. Make a list of these fields (i.e. the column headings in your data table). Then go through the OBIS schema. If there is one or more fields in the OBIS schema that cover information that you want to hold, then use that field name and the suggested format. If there are one or more fields in the OBIS schema that do not apply to your data, just leave them out. If there is additional information that you want to keep in your database that is not covered by the OBIS schema, then you can add additional fields.

A relational database is a class of software that allows you to hold data in linked tables. You do not need to use a relational database, as you can hold your information in a "flat file" such as an Excel worksheet. However, a relational database offers great advantages. First, it lets you enter information more efficiently. For example, you can enter a scientific name once into a table of names. Then for every record or observation you have for that species, you won't need to type that name in again, you can just pick it from a drop-down list. So it is faster and you don't have to worry about making typing or spelling mistakes. In addition, relational databases can be queried in more complex ways than a spreadsheet. For example, you can ask for "all the records for species X that were caught north of 30° north, shallower than 300m, and between 1980 and 1985."

A note on text files. Delimited text files are good for archiving data (saving it in such a way that someone years from now will probably still be able to get to it), but not very good if you actually want to do things with the dataset, like extract certain data of interest, update it, or serve it.