survey_site_visit_data v2.0.0
Template Archived
This Template is archived, and is no longer available for use.
SYSTEMATIC SURVEY SITE VISIT DATA TEMPLATE INSTRUCTIONS
Intended Usage
This Systematic Survey Site Visit Data template should be used to record data related to the visit made to the Site area during a systematic survey.
This Systematic Survey Site Visit template must be used in combination with the Systematic Survey Site Data template.
Templates have been provided to facilitate integration of data into the Biodiversity Data Repository (BDR) database. Not all types of data have been catered for in the available templates at this stage - if you are unable to find a suitable template, please contact bdr-support@dcceew.gov.au to make us aware of your data needs.
Data Validation Requirements:
For data validation, you will need your data file to: - be the correct file format, - have fields that match the template downloaded (do not remove, or change the order of fields), - have extant values for mandatory fields (see Table 1), and - comply with all data value constraints, - align with existing controlled vocabularies wherever possible, but new terms may be submitted for consideration and will not cause a validation error.
Additional fields may be added after the templated fields (noting that the data type is not assumed and values will be encoded as strings).
FILE FORMAT
- The systematic survey site visit data template is a UTF-8 encoded csv (not Microsoft
Excel Spreadsheets). Be sure to save this file with your data as a .csv (UTF-8) as follows,
otherwise it will not pass the csv validation step upon upload.
[MS Excel: Save As > More options > Tools > Web options > Save this document as > Unicode (UTF-8)]
otherwise it will not pass the csv validation step upon upload. - Do not include empty rows.
FILE NAME
When making a manual submission to the Biodiversity Data Repository,
the file name must include the version number
of this biodiversity data template (v2.0.0).
The following format is an example of a valid file name:
data_descripion-v2.0.0-additional_description.csv
where:
data_description: A short description of the data (e.g.survey_site_visits,test_data).v2.0.0: The version number of this template.additional_description: (Optional) Additional description of the data, if needed (e.g.test_data)..csv: Ensure the file name ends with.csv.
For example, survey_site_visits-v2.0.0-test_data.csv or test_data-v2.0.0.csv
FILE SIZE
MS Excel imposes a limit of 1,048,576 rows on a spreadsheet, limiting a CSV file to the header row followed by 1,048,575 occurrences. Furthermore, MS Excel has a 32,767 character limit on individual cells in a spreadsheet. These limits may be overcome by using or editing CSV files with other software.
Larger datasets may be more readily ingested using the API interface. Please contact bdr-support@dcceew.gov.au to make us aware of your data needs.
TEMPLATE FIELDS
The template contains the field names in the top row. Table 1 will assist you in transferring your data to the template indicating:
- Field name in the template (and an external link to the Data standard for that field where relevant);
- Description of the field;
- Required i.e. whether the field is mandatory, conditionally mandatory, or optional;
- Format (datatype) required for the data values for example text (string), number (integer, float), or date;
- Example of an entry or entries for that field; and
- Vocabulary links within this document (for example pick list values) where relevant. The fields that have suggested values options for the fields in Table 1 are listed in Table 2 in alphabetical order of the field name.
ADDITIONAL FIELDS
Data that does not match the existing template fields may be added as additional columns in
the CSV files after the templated fields.
For example, instrumentType, instrumentIdentifier, weatherConditions.
Table 1: Systematic Survey Site Visit data template fields with descriptions, conditions, datatype format, and examples.
| Field # | Name | Description | Mandatory / Optional | Datatype Format | Examples |
|---|---|---|---|---|---|
| 1 | surveyID | The identifier of the Survey that the Site is related to in this dataset. | Optional | String | AR220-01 |
| 2 | siteID | A unique within dataset string identifier for the site. Valid values include strings that are used specifically for this survey or URIs from BDR Sites that have been established in previous surveys. | Mandatory | String | P1 |
| 3 | siteIDSource | The organisation that assigned the SiteID to this Site | Optional | String | TERN |
| 4 | siteVisitID | The unique key assigned to a visit. A visit is a time distinct assessment conducted within a survey at a designated site. | Mandatory | String | CPXEI0000001 |
| 5 | siteVisitStart | The temporal start of when the Site was being used to collect data for the survey. Expected values include date, dateTime, dateTimeStamp. | Mandatory | Timestamp | 2016-02-28 |
| 6 | siteVisitEnd | The temporal end of when the Site was being used to collect data for the survey. Expected values include date, dateTime, dateTimeStamp. | Optional | Timestamp | 2016-02-28 |
| 7 | visitOrgs | The names of the organisations responsible for recording the original Occurrence. | Optional | List | NSW Dept of Planning, Industry and Environment. |
| 8 | visitObservers | A list (concatenated and separated using |) of names of people, groups, or organisations responsible for recording the original Occurrence. | Optional | List | Oliver P. Pearson | Anita K. Pearson |
| 9 | condition | The state of a patch of vegetation at the time of sampling relative to some specified standard or benchmark (where available). | Optional | String | Burnt |
| 10 | targetTaxonomicScope | The taxonomic group targeted for sampling during the Site Visit | Optional | String | Coleoptera (Vocabulary link) |
| 11 | protocolName | Categorical descriptive name for the method used during the Site Visit. | Optional | String | HARD TRAP (Vocabulary link) |
| 12 | protocolDescription | A detailed description of the method used during the Site Visit. The description may include deviations from a protocol referred to in eco:protocolReferences. Recommended good practice is to provide information about instruments used, calibration, etc. | Optional | String | Three conventional harp traps (3.2m ht x 2.2m w) were established in flight path zones for a period of 4 hrs at dawn and dusk for a total of 10 trap nights. Traps were visited on an hourly basis during each deployment period and the trap catch recorded for species, size, weight, sex, age and maternal status. |
| 13 | samplingEffortValue | Similar to eco:samplingEffortValue. The total sampling effort value. A samplingEffortValue must have a corresponding samplingEffortUnit | Mandatory if samplingEffortUnit is provided. | String | 20 x 12 |
| 14 | samplingEffortUnit | Similar to eco:samplingEffortUnit. The units associated with samplingEffortValue. | Mandatory if samplingEffortValue is provided. | String | trapDays (Vocabulary link) |
APPENDICES
APPENDIX-I: Vocabulary List
Data validation does not require adherence to the vocabularies for the various vocabularied fields. These vocabularies are merely provided as a means of assistance in developing consistent language within the database. New terms may be added to more appropriately describe your data that goes beyond the current list.
Table 2: Suggested values for controlled vocabulary fields in the template. Each term has a preferred label with a definition to aid understanding of its meaning. For some terms, alternative labels with similar semantics are provided.
APPENDIX-II: Timestamp
Following date and date-time formats are acceptable within the timestamp:
| TYPE | FORMAT |
|---|---|
| xsd:dateTimeStamp with timezone | yyyy-mm-ddThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) OR yyyy-mm-ddThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) OR yyyy-mm-ddThh:mmTZD (eg 1997-07-16T19:20+01:00) |
| xsd:dateTime | yyyy-mm-ddThh:mm:ss.s (eg 1997-07-16T19:20:30.45) OR yyyy-mm-ddThh:mm:ss (eg 1997-07-16T19:20:30) OR yyyy-mm-ddThh:mm (eg 1997-07-16T19:20) |
| xsd:Date | dd/mm/yyyy OR d/m/yyyy OR yyyy-mm-dd OR yyyy-m-d |
| xsd:gYearMonth | mm/yyyy OR m/yyyy OR yyyy-mm |
| xsd:gYear | yyyy |
Where:
yyyy: four-digit year
mm: two-digit month (01=January, etc.)
dd: two-digit day of month (01 through 31)
hh: two digits of hour (00 through 23) (am/pm NOT allowed)
mm: two digits of minute (00 through 59)
ss: two digits of second (00 through 59)
s: one or more digits representing a decimal fraction of a second
TZD: time zone designator (Z or +hh:mm or -hh:mm)
APPENDIX-III: UTF-8
UTF-8 encoding is considered a best practice for handling character encoding, especially in
the context of web development, data exchange, and modern software systems. UTF-8
(Unicode Transformation Format, 8-bit) is a variable-width character encoding capable of
encoding all possible characters (code points) in Unicode.
Here are some reasons why UTF-8 is recommended:
- Universal Character Support: UTF-8 can represent almost all characters from all writing systems in use today. This includes characters from various languages, mathematical symbols, and other special characters.
- Backward Compatibility: UTF-8 is backward compatible with ASCII (American Standard Code for Information Interchange). The first 128 characters in UTF-8 are identical to ASCII, making it easy to work with systems that use ASCII.
- Efficiency: UTF-8 is space-efficient for Latin-script characters (common in English and many other languages). It uses one byte for ASCII characters and up to four bytes for other characters. This variable-length encoding minimises storage and bandwidth requirements.
- Web Standards: UTF-8 is the dominant character encoding for web content. It is widely supported by browsers, servers, and web-related technologies.
- Globalisation: As software applications become more globalised, supporting a wide range of languages and scripts becomes crucial. UTF-8 is well-suited for internationalisation and multilingual support.
- Compatibility with Modern Systems: UTF-8 is the default encoding for many programming languages, databases, and operating systems. Choosing UTF-8 helps ensure compatibility across different platforms and technologies.
When working with text data, UTF-8 encoding is recommended to avoid issues related to character representation and ensure that a diverse set of characters and languages is supported.
For assistance, please contact: bdr-support@dcceew.gov.au