Skip to end of metadata
Go to start of metadata


The Profile Repository is a natural extension of the NameUsage pattern that underpins APNI and APC - currently demonstrated as principle support for APC comments, type citations and associated text.  This pattern is now used by IPNI, partially implented by TCS (taxon concept schema), extended by Berlin Model (to replace IOPI model) and the EDIT Common Data Model (CDM), accepted by Zoobank and about to be trialled by Global Names Index (GNI) and Index Fungorum.

The model requires that detail about a taxon is stored as objects associated with a Name usage and cross referenced to a taxon citation unless this usage is itself a taxon instance.  A taxon, in the NameUsage sense, requires that the "concept" instance is a protologue or subsequent revision or treatment with synonymic relationships or classification.  A profile containing NameUsage may reference many concepts or none at all, in which case it simply remains an linked usage of the name.  Data sets managed using this approach are always up-to-date, referenced content remains accessible and all documented acts reusable.  It provides a proven framework for both  creation and delivery of taxonomic content.

From IBIS point of view the simplest approach would be to attach instances of the distinct generic classes of profile objects to a Taxon (NameUsage), add a page to APNI and include the associated detail in data output: [I:output here]

Though the model is generic enough to be universally useful APNI has a distinct plant bias with respect to naming standards and high level domain rules.  This is not exclusively an APC/APNI issue. AFD, Flora on-line, Euclid, the Pea Key ... all do stuff in idiosyncratic ways.  And each of these add significantly to the dictionary of profile terms and the kinds of profile possible.

There is a need for a simple and generic profile repository supporting data integration and management at the taxon level and the development of tools and services supporting taxonomic content development and delivery.  Tools that should include updated interfaces for APNI/APC/Flora clients, Flora development and collaborative profile creation.

The requirement is itself generic and with other groups already ( EDIT, EOL, GBIF, ... ) working toward similar solution it makes a lot of sense to aim for a high level of collaboration.  We have discussed such a process at length within TDWG, with EDIT, CATE, IPNI and within the EOL/GBIF Nomina meetings  and as a result of these meetings we have made considerable  effort to investigate the EDIT WP 5 Common Data Model (CDM) which is currently the most advanced open implementation. Internally we have also committed significant resources toward extending AFD to meet these requirements.

CDM looks as if will do what we want ... eventually.

The CDM project is extremely ambitious in scope. The EDIT Work Package responsible also has an immediate need to keep the code base stable as they work toward targets for key milestones and deliverables. They are in fact at the stage of removing functionality to improve stability and the changes and extensions that we will require for even medium term support of existing systems and mandatory standards are not currently on the agenda. Our offer to collaborate, while accepted enthusiastically, is somewhat premature.

We do have access to CDM domain model and code base.

Currently in Version 1 release (1.4) CDM has funding through to 2011 and an expectation of a final release (3) during 2010 after version 2 later this year.

In the interim, because of immediate needs, we are proposing to take a simple  yet compatible approach. Informed by CDM while building on the existing framework of APNI/APC, FLORA and AFD to provide a generic platform to support directly the wide range of nomenclatural, taxonomic, descriptive and hierarchical content that we currently have available to us, including keys and trees.  CDM migration not to be precluded but  kept open until sometime during 2010.

This will mean deliberately working at the data layer providing for core deliverables and data management capabilities until the full range of CDM tools and services become available to us.  The basic layers that we develop will be designed whereever possible to eventually contribute directly to CDM. This process will enable us to deliver on immediate requirements for profile integration and delivery while investigating generic ways to manage profile data collaboratively and incorporating the flexibility required for ontology based profile development. More importantly it will promote the evolution of an integrated data set and contribute significantly to the maturity of this important information resource.


These proposed Milestones  are based on phased delivery of functional components . There is some flexibility within the project tree to accommodate shorter paths meeting specific funded requirements.  

  1. Documentation.
  2. Model review and integration.
  3. Ontolgy Store
  4. Generic Profile Repopsitory
  5. Import of key data sets
  6. Prototype Editorial interfaces
  7. Ontology (term) editor
  8. Standardized output
  9. Targeted profile delivery
  10. Formatted output (XSLT)
  11. Return data in the form provided
  12. Portable platform for the delivery of existing services
  13. Platform for updated editorial interfaces for APNI/APC
  14. Platform supporting tools for Collaborative profile management
  15. Migration to CDM.
  • No labels