Biodata Management Framework
Summary
- There are 7 posts — by 3 authors — in this topic.
-
Posts with files From File Date Dan Randow Aug 05 17:46 NZST - Latest post made by James Lambie at Nov 29 12:41 NZDT
Hi All, The initiative that started life as "Biodata Management Guides" <http://dataversity.org.nz/r/topic/79O0PiKtlviEkL5TV0bYQO> has morphed into a Biodata Management Framework. Instead of our original plan to write two of a set of twelve guides, we decided on a smaller project to write all twelve in one go. How will we do that? By writing only very rough guides. While the resulting guides will be of limited use, especially to more specialised data managers, the overall result will be a framework that should help to make biodata management less overwhelming, especially for smaller councils. It will also mean that we can test the output of this project and get feedback on its usefulness, before investing further in the project. If this works, some of you may even take on the maintenance of a guide or two. TFBIS have agreed with all this and are funding Horizons who have engaged me to progress it. We are developing even this simple guide iteratively. With the help of some steering team members, I have started work on a rough outline of the guide at <http://dataversity.org.nz/guide/practices/>. You'll see that it has all twelve biodata management areas where we figured guides were needed. For each of them (aside from the gaps), there is a simple maturity model with a description of each of five levels of maturity. The aim is that you could use this table to do a quick assessment of the state of a biodata management initiative, large or small. You could then use it to prioritise areas in which to improve practices. In each area of biodata management, the framework then has checklists for getting from each maturity level to the next. Each area in the framework will also have user stories, so we know what we are talking about and reference resources including links to discussions. And each area will have an owner who you can talk to if you want to help improve the framework. For now, you will see that the content is very very preliminary. Here's how we are going to improve it. 1 I will continue to work on the framework, with the help of the steering team. 2 Any member of Dataversity can log in to this site and edit any page of the framework. Please do that, or at least just suggest improvements by replying to this email. 3 I plan to hold workshops in Wellington, Auckland and Christchurch to test out and work on the framework. More on these soon. Please come along to one!
cheers, Dan -- @danrandow +64-27-431-4928 +64-3-377-5377 Chief Wrangler http://onlinegroups.net
Part of the approach I am taking with the framework is to test it at every opportunity, even though work on it has barely started. The plan for upgrading FBIS <http://dataversity.org.nz/r/topic/4MGi6pE3K94QMpUH5tGCH6> presents one opportunity. If NIWA have identify ways in which FBIS needs improving, surely all biodata systems could benefit from assessment on similar criteria. So, here are the main tasks for FBIS, compared with the Biodata Management Areas on our framework <http://dataversity.org.nz/guide/practices/>. > 1. Improve species taxa lists held in FBIS (Scoping Report, issue > 5.1), and link these to NZOR. Depending on the exact meaning of "linked", that looks like "Metadata Standards" Level Five: "Metadata Synchronised with Authoritative Standard" <http://dataversity.org.nz/guide/practices/metadata>. > 2. Improve the FBIS user interface (UI) (Scoping Report, issue 5.3) Usability! Clearly this is important but not specific to biodata systems, but then neither are "Archiving", "GIS Integration" or "Sharing Data via the Web". What do you think? Should usability be a biodata management area in the framework? > 3. Produce a new, generic and flexible biodata ingestor framework > (Scoping Report, issue 5.2) to allow biodiversity scientists and > managers to load data into FBIS. This certainly has implications for Data Quality Management, but prompts the question as to whether this area has too much in it. Currently there are four factors considered in the Data Quality Management area <http://dataversity.org.nz/dataquality>: - automated validation - authorisation workflow - recording data-quality metadata - automated data-depreciation 5.2 seems to reflect only the first of these, with a nod to usability. Another system we could look at to inform this area is CADDIS-Fly, as one of its design criteria was ease of getting valid data into it. I think our Data Quality Management Management area needs work. Any volunteers? > 4. Import of NIWA’s priority datasets into FBIS (Scoping Report, > issue 5.5). So, data should be held in a small number (ideally 1) of good systems, rather than a large number of variable ones. This is another area not yet handled by our framework. Would we call it "Data Consolidation"?. Should this be in the framework? Again it is important but not specific to biodata. > 5. Produce web service based interfaces allowing integration of > external agencies' databases into FBIS (Scoping Report, issue 5.5) as > part of a New Zealand confederated biodata structure. This looks like "Sharing biodata via the web" level five: "Data available via web services." <http://dataversity.org.nz/guide/practices/web>.
Comments? Dan
Hi everyone, I realise that everyone is probably very busy with end of financial year activities approaching. I have spent a bit of time so far looking at the info outlined in the Biodata Management Framework table. I have a few questions/comments: 1) What is the goal/endpoint that we're working torwards? Is the goal to have one 'system' that can meet the needs of all councils? There is a cost associated with building and maintaining databases to hold biodiversity data. Yes the world we're trying to collect biodata about is complex and various councils might have specific needs, but is it possible to build a system that is flexible enough to meet these needs and keeps costs down by having numerous councils contribute to it's development and maintenance? Or instead are we aiming for each council having different 'systems' but at least the systems talk to eachother so we can federate, combine and easily mash-up the data? 2) Based on my experience with a few biodata systems, here are a few other areas I would like to see added to the guide, and I'd like to get your feedback: - Useability and Uptake - I agree with Dan's other dataversity post that this area should be added. However, useability covers more than just the useability of the 'front-end' interface. The 'back-end' and the database should also be easily usable so that one can perform database maintenance, updates, add rows or columns to data columns if necessary. For example, the 'back-end' should be easy enough to use that someone in the team can add a new species to the taxa list (say the RPMS is revised) without having to put the change request through a database administrator. - Uptake includes identifying and removing barriers so that people are most likely to use the database. Having a system that people don't use is not much better than having no system at all. The barriers might have to do with a lot of things - not receiving training on the system, not being able to provide input and feedback on the system through all the design phases, the database doesn't report meaningful indicators, an interface that is broken or difficult to use, a system that is too time-consuming to contribute to, a system that functions as a 'back-box' and doesn't allow users to easily go in and correct errors in their dataset. - Future proofing - we can try and imagine all the data we might want to collect and the answers we might want to ask of it. But the world is constantly changing. The data model and logical relationships need to be robust enough to add modules, add columns and rows - in shore the database needs to be flexible enough to allow for growth and change. Platform independent modeling is an important feature of this area: http://en.wikipedia.org/wiki/Platform-independent_model As well as Unified Modelling Language: http://en.wikipedia.org/wiki/Unified_Modeling_Language - Exportability - The goal shouldn't necessarily be to build a database that can do everything. For example, NVS Express from Landcare wasn't built to do all the statistical analyses under the sun. Instead users can export their data in a variety of formats that are compatible with all the major statistical packages. Uploading data - some day I'd like to see council develop a system that they use internally but also allow members of the public to also contribute and upload data in bulk using standard formats. For example, say a person hires a consultant to perform an assessment of environmental effects for a resource consent. The consultant is then required to submit the raw data (e.g. bird counts, ecosystem assessment, pitfall trap data) to council in the standard data format for storage and analysis on the council biodata system.
Hi All, Responding to Stacey Byers' message of 13 June. Stacey Wrote; 1) What is the goal/endpoint that we're working towards? For me, the ultimate aim is to end up with a situation where all local government biodata is seamlessly integrated across councils and across the industry. If we did it through one 'system' that all councils conform to, it would be very tidy and probably a lot easier to train people into using the system, but it is not necessary (and since we councils are a diverse bunch, and we like diversity, a single data management system is unlikely!). My vision, which I believe is shared by a lot of the Dataversity Community is a federated biodata network that, as you say, we can combine and easily mash-up the data. The biodata management framework is a tool we can use to assess the state of our bio-data systems against various subject areas and behaviours we believe the ideal system would need to have in place for data to be able to be integrated. Each level up the chain is a level toward better / stronger integration and higher confidence in a system in being able to deliver data that is fit for purpose. The framework should contain enough guidance so that, once you've assessed where your system sits in the matrix, you can plan and prioritise further actions to increase the integrity of the system. I hope this makes sense - it is a bit hard to describe the matrix in words. The framework, as it evolves, should eventually be deep enough so that you can decide whether to pursue building a system to accommodate data you have collected, or use an existing system (if there is one). 2) Based on my experience with a few biodata systems, here are a few other areas I would like to see added to the guide, and I'd like to get your feedback: (list) Your suggestions are fantastic and I see you've already been to modify the system. I see your also at the Auckland Regional Workshop and this will be a good opportunity to test your thoughts. Regards, James. Horizons Regional Council | 24 hr freephone 0508 800 800 | www.horizons.govt.nz This email is covered by the disclaimers which can be found here: http://www.horizons.govt.nz/exclusion-of-liability
Hi All, Here is the output from the Wellington Workshop, along with some conversations and editing that have occurred since then. I am about to edit these into the pages at <http://dataversity.org.nz/guide/practices/>. Dan . . . Framework improvements 110629 Based on the Wellington workshop with: Sara Moylan Siobhain Browning James Lambie Pedro Jensen Pewter Furnish and on contributions by Stacey Byers and Andrew Watkins <http://groups.open.org.nz/r/post/2MdI4wCEem8f2c03pDZGyC>. Consolidation & Discovery
=========================
Ideally only one system should exist. In practice there are many. There should
at least be a catalogue of systems.
Where to put or list the data – of the catalogues and major systems
Levels
------
1 Unknown number of systems
- Number and location of datasets is not known.
Data that is discoverable is fragmented,
distributed and of variable quality. No way of
reporting on the data. Difficult to interpret
data.
2 Internal catalogue exists
3 Systems use standard metadata and are listed with
main external catalogues
4 Internal catalogues dynamically feed into external catalogues.
5 Internal catalogues dynamically sync with external catalogues.
Integration of Biodata Systems with In-house Systems
====================================================
User stories
------------
A Consents Officer is assessing a consent application on a
parcel that has biodiversity values.
Staff planning asset maintenance need to understand the
biodiversity benefits of maintaining the asset, eg a fence
around a wetland.
A Biodiversity Officer is planning a site visit. She wishes to
contact the land owner to arrange this. She looks for contact
information. She also looks for information about the council
staff and external parties such as volunteer groups and contractors
who have been interacting with the site and its contact people.
Levels and checklists
---------------------
1 No inter-system integration, or potential to integrate them.
- Staff work around this with phone calls and accepting the costs of not
talking to each other (stuff that applies to all level ones).
- Biodata is shoehorned into a completely unsuitable in-house
system.
2 Staff aware of and able to access data from related systems
3 Datasets are well-managed and integratable
- Datasets can be overlaid using GIS.
4 Relationships between datasets are understood.
- Analysis of cross-system data can be done (for reporting and
planning).
- Semi-automated operational workflows.
- Point solutions for specific tasks, eg owner information
ingested periodically.
5 Biodata systems are dynamically linked with in-house systems.
- Land management system is linked to document management and financial
systems so that workflows are captured from initial request for an
inspection. The system tells the relevevant officer to visit the site.
The officer visits site, records observation, document template for
letter pops up. System records the time and other expenses incurred.
System integrates with the following other systems:
contacts
consents
document management
financial
health & safety
references
GIS
asset register
Data Collection Methodology
===========================
This aspect of biodata management refers to the scientific and operational
context in which data is collected. It has significant bearing on data quality
but does not refer to the data quality itself. This framework is about
*systems*. Of course data quality is important, but is outside the scope of the
framework.
Question: is this the only "Fitness for Purpose" issue that matters? Should we
call this area "Fitness for Purpose" and include other factors in that?
1 Casual observations.
- We collect data with no formal definition of what we are
collecting or why.
2 Ad hoc methodology.
- The data was collected for some known purpose, but
the method was not rigorous or was inconsistently
applied.
3 Well-designed methodolgy.
- A suitably qualified person designed a protocol, setting
local standards.
- The methodology is well-documented.
4 Best practice followed.
- The data was collected strictly following a widely accepted best
practice guideline eg DOC weed monitoring protocol, 5MBC.
5 National protocol applied consistently.
- The data was strictly following a national standard
protocol eg RTC monitoring.
Usability
=========
This is related to but not the same as Fitness for Purpose, which is handled to
some extent by "Data Collection Methodology".
Levels
------
1 No documentation. No UI standards.
2 UI Documented.
3 Data model and API documented.
(I am not sure I agree with Stacey's idea that
"the 'back-end' should be easy enough to use that
someone in the team can add a new species to the taxa
list (say the RPMS is revised) without having to put
the change request through a database administrator."
That could result in a nightmare for the DBAs, who
are our friends. The system should inherently allow
the front-end administrator to modify the metadata.
4 UI optimised for data collection methods.
5
User Stories for the Framework
==============================
The following user stories have been added to
<http://dataversity.org.nz/guide/practices/>.
A Biodiversity Office is seeking funding to improve biodata systems. She
uses the framework to assess the current state of systems, to set goals
for system improvements and to justify investment in the improvements.
A Biosecurity Officer is planning to acquire or develop a new biosecurity
database. She uses the framework to set criteria that the new system must
meet, and to evaluate the new system as it is developed or implemented.
A Data Manager wants to connect a biodata system to a network of biodata
systems. He uses the framework and to assess and report on the system's
suitability to become part of a federated system.
A biodiversity team is trying to assess existing data so they can make
better use of it. They use the framework to assess the systems used to
manage the data. This improves their understanding of the quality of the
data.
Web-Based Community Monitoring
==============================
There has been much talk about this. We do have "Sharing Biodata via the Web"
<http://dataversity.org.nz/guide/practices/web/> but that is more oriented to
data-sharing. And then we have "Data Exchange".
I am going to conflate "Data Exchange" and "Sharing Biodata via the Web" and
add "Web-Based Community Monitoring".
What would the levels be?
Limitations of the Framework
============================
Design of the Framework
-----------------------
The Framework is made up of a series of guide. Each guide addresses a specific
aspect of biodata management and currently contains:
- A Title
- User Stories
- An Owner
- A link to a discussion topic
- Levels
- Related biodata management areas
- References
Each level currently comprises:
- A title
- A checklist of criteria for attaining the level
Of the first two intended user tasks for the framework, this seems to suit the
first but not the second.
# Assess the current state of biodata management practices.
# Prioritise improvements to biodata management practices.
In order to help with prioritising improvements, the framework should specify
business (in the broad sense) costs and benefits of maintaining systems at each
level in the framework.
Scope of Data Systems
---------------------
The frameowrk deals with how well data is handled but not with what kind of
data is handled.
Also relevant is the scope of the system:
- Species
- terrestrial
- vegetation
- birds
- pests plants
- pest animals
- freshwater
- marine
- etc
- Sites
- designations
Function of Data Systems
------------------------
The framework also fails to address the kind of tasks that are supported by
data systems.
- Operations
- Reporting
…
System Architecture
-------------------
The framework can be used to assess an individual system, a set of systems or
the entire set of systems in a given context.
It is also necessary to map a system architecture, especially in a world of
interconnected systems.
Hi All, The 19 July Lincoln Biodata Management Framework workshop was a great one. The participants (see below) were enthusiastic about the framework but were also highly critical of it, in a thoroughly constructive way. They pretty much ripped apart the "biodata mangement areas" I had come up with, but provided lots of good ideas for putting them back together. We found various problems with them: areas that contained too many sub-areas, ones that overlapped, areas that spanned the entire data life-cycle and ones that apply to only one stage of that. It looks like the areas might fall into groups, too. Suffice to say, that in the next stage of the Framework project, there is a job to do getting the "areas" sorted, before much else can happen. But when that is done, the areas by themselves will provide an instructive view of the overall task of biodata management. The whole idea of Maturity also went under the knife, but it came off slightly better. We do have to come up with some stable idea of what each level means, so that it can be moderated across the areas. The level descriptors and criteria need to be technology-independent (even when it come to paper). And will need some pre-requisites (like a degree programme) where it really does not make sense to go to far in one area (say Data Quality Management) if you have not addressed another one it depends on (like Field Data Capture). But again, none of this can really be progressed until we decide which areas will be on the list. Once we'd realised how sturdy the framework could end up being, the scope for uses of it widened. This is not just a tool for getting up to levels 2 and 3 in small organisations. Large organisations, institutions even, could use this -- often to get to levels 2 and 3 themselves. And the framework could be used for evaluating software systems, or potential data providers in a federated network. Perhaps compliance with a defined level on the framework could be used as a contract condition for system development or even science provision contracts. Finally, the group came up with a development plan. 1 Get the areas sorted. 2 Get the matrix sorted. 3 Take the guides to a decent level of detail. 4 Get the guides and checklists robustly agreed. Many thanks to all who participated in the Lincoln workshop, and the Auckland and Wellington workshop. This phase of the Framework project is now complete. Below is a link to an overview of the framework project as it stands. We (the Dataversity Steering Team) will be seeking funding to progress the development of the Framework. We will need letters of support. If you are willing to write a letter of support for a funding application to progress the framework, please let me know.
cheers, Dan -- @danrandow +64-27-431-4928 +64-3-377-5377 Chief Wrangler http://onlinegroups.net . . . Lincoln 18 July 2011 Workshop Participants ------------------------------------------ Colin Meurk , Landcare Research Lynette Hartley, DOC James Mortimer, DOC Elise Arnst, Landcare Research Hamish Maule, Landcare Research Margaret Anderson, Landcare Research Kevin Richards, Landcare Research Zane Gilmore, Plant & Food Nick Spencer , Landcare Research Shane Orchard, NZBRN
The following file was added to this topic:
Hi Everyone, A quick message to accounce that we were successful in our bid to TFBIS to continue the Dataversity Biodata Management Framework. My special thanks to the Independant Supporters for the project, but also general thanks to you all for your contribution to the first phase, since demonstration of the original concept was critical to continuing this next phase. Dan and/or I will be making further accouncments and requests for your further input as the project progresses.
Regards, Jim
Loading…
Privacy | Acceptable Use | Terms of Service | About OnlineGroups.Net | Contact OnlineGroups.Net
Start an OnlineGroups.Net site for easier email collaboration in your organization.
Powered by GroupServer, the open source web-based mailing list manager.