WFO Machine Readable Plant List

This service provides a machine readable version of the taxonomic backbone of the World Flora Online. It is intended for technical users. This page is the only human readable part of it. If you are not interested in consuming raw data through a web service you probably want to go to the main website of the World Flora Online.

There are two ways to interact with the data: through semantic web compatible URIs or via the GraphQL query language. Both approaches use the same basic data model. Objects and properties are defined by URIs in the Semantic Web interface and in the GraphQL documentation.

Status: This service is now live. If you are using it in a production system please let Roger Hyam know so we can keep you informed of status updates. We are refactoring the code over the winter of 2022/23 which shouldn't introduce breaking changes but let us know if it does. We'd welcome any feedback you might have.

Data Model


For each major update of the classification in the main WFO database a snapshot of the taxonomic backbone (names and their statuses) is taken and added to this service. The data available here therefore represents multiple classifications of the plant kingdom showing how our understanding has changed through time.

In order to represent multiple classifications in a single dataset it is necessary to adopt the TaxonConcept model which differentiates between taxa (TaxonConcepts) which vary between classifications and names (TaxonNames) which do not, but which may play different roles in different classifications.

Taxon name/concept background: A good analogy for those unfamiliar with the TaxonConcept model is that of polygons and points within a geospatial model. A classification divides a plane into contiguous map of nested polygons (like counties, regions, countries, continents). These are the taxa. The names are points on the plane. The name used for a polygon is the oldest point that occurs within it. Other names that fall in that polygon are referred to as synonyms. Different taxonomic classifications are like the different maps of the same plane with different polygons but with points that are the same on all maps. Polygons on two maps might have the same calculated name but different boundaries and different synonyms. It is therefore necessary to refer to taxa in different classifications using unique identifiers rather than their calculated names.


All TaxonConcepts and TaxonNames are identified with URIs which resolve according to semantic web best practices (see below). These identifiers are also used in the GraphQL accessible data. They are intended to be persistent and can be stored. The URIs are based on the WFO IDs used elsewhere.

TaxonNames identifiers take the form The final part of the URI is the same as the identifier used in the live web pages for the current version of the WFO. There is a one to one relationship between names, as created under the International Code for Botanical Nomenclature, and these identifiers.

TaxonConcepts identifiers take the form The final part of the URI is a name identifier qualified by a classification version. The version format is the year followed by the two digit month.

Note that although the format of identifiers is described here (because it is useful for understanding and debugging) you should not construct them programmatically but treat them as opaque strings. It is possible to construct taxon concept identifiers for taxa that don't exist. If a name did not occur in an earlier version of the classification but you create a URI that consists of the WFO ID plus the version of that classification you will get a 404 NOT FOUND response.

We bend the semantics slightly for the sake of utility. If a record is a synonym it is semantically not a TaxonConcept but a TaxonName. The versioned WFO IDs for synonyms will therefore 301 redirect to the name entry only. The name (Comandra elliptica Raf.) Is a synonym in the classification 2022-12. The versioned URI of that name is this: If you click on it in a web browser you will be redirected to the taxon page in the WFO Plant List for the accepted name. If on the other hand you were to call for data for that name using an HTTP Accept header of application/json, perhaps with the curl command

curl -I -H "Accept: application/json"

then you would get a 301 redirect to the accepted name (Comandra umbellata (L.) Nutt.) in which Comandra elliptica Raf. is a synonym.


The diagram below shows the property relationships in the data model. Further documentation on these can be found either by dereferencing the URIs of the terms in the RDF responses or by looking at the GraphQL documentation using an IDE. The second way might be useful even if you intend to only use the Semantic Web API.

GraphQL Interface

The GraphQL endpoint is

There are many resources on the web about use of GraphQL. It enables self documenting APIs and all the objects and properties available here have been documented. The use of a GraphQL client or IDE are recommended e.g. the GraphiQL plugin for Google Chrome.

You don't need fancy libraries to access the GraphQL end point it and it might be the best approach for embedding the WFO Plant List in your project. Here are some examples of how to use the API with plain JavaScript.

Semantic Web Resources

The URI identifiers for TaxonConcepts and TaxonNames follow Semantic Web best practice in implementing content negotiation.

Calling a URI will always result in an HTTP 303 "See Other" redirect to an appropriately formatted source of data about that resource. Where the client is sent depends on the content of the Accept header in the request. When data of a recognized mimetype isn't contained within the header or when an HTML mimetype is found the client will be redirected to an appropriate page within the WFO website. This is to ensure human users are always sent to something appropriate and not confused by the data services offered here.

If a recognized mimetype is found then the client is redirect to a data resource of that mimetype. By convention the URI of that data resource will be the original URI with a slash followed by the name of the data type appended. This behaviour makes developing and debugging easy but should not be relied upon in code as it may change in the future. Production systems should always resolve the identifier URI and follow the supplied redirect.

Supported formats

Data can be returned in the 11 formats listed in the table below. These include graphical representations of the data.

Name Recommended Mime Type Recognized Mime Types Example
jsonapplication/jsonapplication/json, text/json, application/rdf+json/wfo-4000000718/json
ntriplesapplication/n-triplesapplication/n-triples, text/plain, text/ntriples, application/ntriples, application/x-ntriples/wfo-4000000718/ntriples
turtletext/turtletext/turtle, application/turtle, application/x-turtle/wfo-4000000718/turtle
rdfxmlapplication/rdf+xmlapplication/rdf+xml, text/xml, application/xml/wfo-4000000718/rdfxml
n3text/n3text/n3, text/rdf+n3/wfo-4000000718/n3

An example graph for a TaxonConcept

An example graph for a TaxonName