Wendi Fan

#### Let's explore MLflow together. {#lets-explore-mlflow-together.}

<figure>
<img
src="https://cdn-images-1.medium.com/max/371/0*7hbpTxs-CGhYWztO.png" />
<figcaption>MLFlow logo</figcaption>
</figure>

### Author

- [Wendi Fan](https://www.linkedin.com/in/wendi-fan-265996310/)
  (**ORCID: 0000--0003--0284--9166**)

### Introduction

MLflow is an open-source platform designed to manage the entire
lifecycle of machine learning projects. It helps developers and data
scientists streamline their workflows by tracking experiments, managing
models, and deploying them efficiently. MLflow's core components
include:

1.  **MLflow Tracking**: This component enables the logging and querying
    of machine learning experiments' parameters, metrics, and models. It
    allows users to track hyperparameter configurations, and training
    outcomes, and compare the performance of different experiments.
2.  **MLflow Projects**: This component provides a standardised format
    for defining machine learning projects, and facilitating team
    collaboration. Through MLproject files, MLflow Projects define
    dependencies and entry points, making it easier to reproduce and
    share projects.
3.  **MLflow Models**: This component focuses on managing and deploying
    machine learning models. MLflow supports multiple model formats,
    allowing trained models to be saved and later loaded in different
    environments.
4.  **MLflow Registry**: This component provides model registration and
    version control, helping teams manage the entire lifecycle of a
    model, from development and testing to deployment and updates.

MLflow is compatible with various popular machine learning libraries,
such as TensorFlow, PyTorch, and scikit-learn, and integrates seamlessly
with containerisation tools like Docker and Kubernetes, enabling rapid
model deployment.

### Setting Up MLflow

Before exploring the rich features MLflow offers, it's essential to set
up the foundational components: the MLflow Tracking Server and the
MLflow UI. This guide will walk you through the steps to get both up and
running smoothly.

### Step 1: Install MLflow from PyPI

MLflow is readily available on PyPI, and installing it is as simple as
running the following pip command:

    pip install mlflow

### Step 2: Launch the MLflow Tracking Server

Next, let's test if the MLflow UI is working properly. To start, you'll
need to launch the MLflow Tracking Server. Make sure to keep the command
prompt open during the tutorial, as closing it will stop the server.
Here's the command you need to run in your terminal:

    mlflow server --host 127.0.0.1 --port 8080

After running the above command, you will see the URL for the running
MLflow UI displayed in the terminal, as shown in the image below.

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/0*Ulas6Qq9bFIZnjkT.jpg" />
<figcaption>MLFlow server is running in the terminal</figcaption>
</figure>

By opening this URL in your browser, you will see the UI as depicted in
the following image:

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/0*KI_NTlQyagXVO4ZU.jpg" />
<figcaption>MLFlow UI</figcaption>
</figure>

### MLflow Tutorial

In just a few minutes, this quickstart will guide you through key MLflow
concepts, including how to log parameters, metrics, and models, the
basics of using the MLflow fluent API, how to register a model during
the logging process, how to navigate to the registered model in the
MLflow UI, and how to load a logged model for inference.

Here, we use a simple example to train a model. This code primarily
focuses on training and testing a **Logistic Regression** model using
the **Iris dataset**, and calculating the accuracy of its predictions.
The code loads the classic **Iris dataset**, a public dataset containing
150 flower samples, each with 4 features (sepal and petal lengths and
widths), and divided into 3 categories: Setosa, Versicolor, and
Virginica. The model predicts the flower category based on the 4
features (sepal length, sepal width, petal length, and petal width).
Additionally, the code splits the dataset into training and test sets,
with 80% of the data used for training (X_train and y_train) and 20% for
testing (X_test and y_test).

### Step 1: Set the Tracking Server URI

If you're using a managed MLflow Tracking Server or if you're running a
local tracking server, ensure that you set the tracking server's
uri using:

    import mlflow
    mlflow.set_tracking_uri(uri="http://<host>:<port>")

### Step 2: Train a model and prepare metadata for logging

In this section, we will log a model using MLflow. The steps include
loading and preparing the Iris dataset, training a Logistic Regression
model, evaluating its performance, and then preparing the model's
hyperparameters and metrics for logging.

    import mlflow
    from mlflow.models import infer_signature
    import pandas as pd
    from sklearn import datasets
    from sklearn.model_selection import train_test_split
    from sklearn.linear_model import LogisticRegression
    from sklearn.metrics import accuracy_score, precision_score, recall_score, f1_score

    # Load the Iris dataset
    X, y = datasets.load_iris(return_X_y=True)
    # Split the data into training and test sets
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, test_size=0.2, random_state=42
    )
    # Define the model hyperparameters
    params = {
        "solver": "lbfgs",
        "max_iter": 1000,
        "multi_class": "auto",
        "random_state": 8888,
    }
    # Train the model
    lr = LogisticRegression(**params)
    lr.fit(X_train, y_train)
    # Predict on the test set
    y_pred = lr.predict(X_test)
    # Calculate metrics
    accuracy = accuracy_score(y_test, y_pred)

### Step 3: Log the model and its metadata to MLflow

In the next step, we will log the trained model, the hyperparameters
used for fitting the model, and the loss metrics calculated from
evaluating its performance on the test data to MLflow. The process
involves the following steps:

1.  Initiate an MLflow run context to start a new run where we will log
    the model and related metadata.
2.  Log the model's parameters and performance metrics.
3.  Tag the run for easy retrieval in the future.
4.  Register the model in the MLflow Model Registry while saving
    the model.



    # Set our tracking server uri for logging
    mlflow.set_tracking_uri(uri="http://127.0.0.1:8080")

    # Create a new MLflow Experiment
    mlflow.set_experiment("MLflow Quickstart")
    # Start an MLflow run
    with mlflow.start_run():
        # Log the hyperparameters
        mlflow.log_params(params)
        # Log the loss metric
        mlflow.log_metric("accuracy", accuracy)
        # Set a tag that we can use to remind ourselves what this run was for
        mlflow.set_tag("Training Info", "Basic LR model for iris data")
        # Infer the model signature
        signature = infer_signature(X_train, lr.predict(X_train))
        # Log the model
        model_info = mlflow.sklearn.log_model(
            sk_model=lr,
            artifact_path="iris_model",
            signature=signature,
            input_example=X_train,
            registered_model_name="tracking-quickstart",
        )

The purpose of this code is to log the machine learning model's training
process, including the hyperparameters, performance metrics, and the
model itself, and save this information using MLflow. It also registers
the model in the MLflow Model Registry, allowing the model to be reused
in different environments. This greatly facilitates the tracking of
experimental results and the replication and deployment of the model in
the future.

To view the results of our run, we can navigate to the MLflow UI. Since
the Tracking Server is already running at
[http://localhost:8080](http://localhost:8080/), simply enter that URL
in your browser.

Once the site opens, you'll see a screen similar to the one below:

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/0*pA_xgtcZ_tUPdZeo.png" />
<figcaption>The main MLflow Tracking page, showing Experiments that have
been created, downloaded from MLflow website</figcaption>
</figure>

By clicking on the name of the experiment we created ("MLflow
Quickstart"), you'll be presented with a list of all the runs associated
with that experiment. In the table view on the right, you'll see a
randomly generated name for the run.

Clicking on the run's name will take you to the run details page, where
you can view all the information we've logged. The key elements are
highlighted below to show how and where this data is displayed within
the UI:

<figure>
<img
src="https://cdn-images-1.medium.com/max/1003/0*X4VHgXRwolBgAPMR.png" />
<figcaption>The run view page for our run, downloaded from
MLflow website</figcaption>
</figure>

Our model has also been saved in the Registered Model section named
"tracking-quickstart":

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/0*0sbVjnycI_e2j_R6.jpg" />
<figcaption>Registered model page</figcaption>
</figure>

### Step 4: Load the model as a Python Function (pyfunc) and use it for inference

After logging the model, we can perform inference by:

1.  Loading the model using MLflow's pyfunc flavor.
2.  Running predictions on new data with the loaded model.



    # Load the model back for predictions as a generic Python Function model
    loaded_model = mlflow.pyfunc.load_model(model_info.model_uri)

    predictions = loaded_model.predict(X_test)
    iris_feature_names = datasets.load_iris().feature_names
    result = pd.DataFrame(X_test, columns=iris_feature_names)
    result["actual_class"] = y_test
    result["predicted_class"] = predictions
    result[:4]

This code loads a previously saved model from MLflow and makes
predictions on the test data. It then combines the actual labels of the
test data with the predicted results into a table, displaying the first
four rows. This allows us to verify the model's performance on the test
data and visually compare the predictions against the actual labels.

The output of this code will look something like this:

<figure>
<img
src="https://cdn-images-1.medium.com/max/872/0*okvNyjGiPwZSuTmE.jpg" />
<figcaption>Outcomes of Prediction by loaded model</figcaption>
</figure>

Of course, we can also specify the pre-trained model we want to run by
selecting the run_id, and we can provide new data for it to make
predictions. Below is a simple code example:

    import mlflow.pyfunc
    import numpy as np

    # Set the MLflow Tracking URI to your server's address
    mlflow.set_tracking_uri("http://127.0.0.1:8080")
    # Load the model using the run ID logged in MLflow
    run_id = "Your_run_id"  # Replace with the run ID found in the MLflow UI
    model_uri = f"runs:/{run_id}/iris_model"
    loaded_model = mlflow.pyfunc.load_model(model_uri)
    # Define new test data
    new_data = np.array([
        [5.1, 3.5, 1.4, 0.2],
        [6.7, 3.1, 4.7, 1.5]
    ])
    # Use the loaded model to make predictions
    predictions = loaded_model.predict(new_data)
    # Print the prediction results
    print("Predictions:", predictions)

In short, MLflow makes it convenient to train our models and save them
for future use. When needed, we can easily load a previously trained
model to run predictions, or even share it with others. Additionally,
MLflow allows us to record detailed results from each training session,
enabling effective version control of our models.

### Differences Between Runs and Registered Models

Sometimes, we might wonder about the difference between a run and a
Registered Model, especially since both can be used to load previously
trained models.

- **Run-based models**: Best suited for development and experimentation,
  allowing for quick iteration and debugging.
- **Registered Models**: Ideal for production, offering version control
  and lifecycle management, making it easier to manage and update models
  in a team environment.

#### **Key Differences Between the Two**

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/1*EDnXpaXr85PQ0L7MjhzeFQ.png" />
</figure>

If you want to use a registered model in a production environment, you
can either register the model during training or register an existing
model from a run as a Registered Model. For example:

    mlflow.register_model(model_uri=f"runs:/{run_id}/iris_model", name="tracking-quickstart")

Here's an example showing how to use registered models as loaded models:

    import mlflow.pyfunc

    # Load the model using the Registered Model name and version number
    model_name = "your_registered_model_name"
    model_version = 1  # Specify the version to load
    model_uri = f"models:/{model_name}/{model_version}"
    loaded_model = mlflow.pyfunc.load_model(model_uri)
    # Use the model to make predictions
    predictions = loaded_model.predict(new_data)

### Conclusion

MLflow is a powerful platform that simplifies the management of machine
learning projects, offering seamless integration for tracking
experiments, saving models, and deploying them across various
environments. By providing easy-to-use tools like the MLflow Tracking
Server, Model Registry, and the flexible pyfunc interface, MLflow
enables developers and data scientists to streamline the entire
lifecycle of their models. Whether you are in the experimental phase or
deploying models to production, MLflow's robust features ensure that
your workflow is organised, scalable, and reproducible. By leveraging
MLflow, teams can efficiently manage models, track results, and
collaborate more effectively, all while ensuring the scalability of
machine learning efforts from development to production.

### References

- *MLflow Tutorial Page --- Getting Started with MLflow* [Read
  me](https://mlflow.org/docs/latest/getting-started/index.html),
  accessed on 18 Oct, 2024. 2) *MLflow Team --- MLflow Tracking
  Quickstart*
  [Read me](https://mlflow.org/docs/latest/getting-started/intro-quickstart/index.html).

![](https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4c64c0822fa4){width="1"
height="1"}

Let’s explore MLflow together. Author  Wendi Fan (
<strong>
 ORCID: 0000–0003–0284–9166
</strong>
) Introduction   MLflow is an open-source platform designed to manage the entire lifecycle of machine learning projects. It helps developers and data scientists streamline their workflows by tracking experiments, managing models, and deploying them efficiently.

MLflow Beginner’s Guide: How to Get Started with MLflow

University of Glasgow

Roderic Page

One of the most interesting aspects of EOL is "TraitBank", which has been described in a recent paper:  TraitBank is available in JSON-LD, and so is potentially part of the Semantic Web.

EOL Traitbank JSON-LD is broken

Each year about this time, as I ponder what to devote my time on in the
coming year, I get exasperated and frustrated that each year will be
like the previous one, and biodiversity informatics will seem no closer
to getting its act together. Sure, we are putting more and more data
online, but we are no closer to linking this stuff together, or building
things that people can use to do cool science with. And each year I try
and figure out why we are still flaying about and not getting very far.
This year, I\'ve settled on the lack of \"platforms\".

In 2011 Steve Yegge (accidentally) published a widely read document
known as the [\"Google Platforms
Rant\"](https://plus.google.com/+RipRowan/posts/eVeouesvaVX). It\'s
become something of a classic, and I wonder if biodiversity informatics
can learn from this rant (it\'s long but well worth a read).

One way to think about this is to look at how we build things. In the
early days, people would have some data and build a web site:

![Rant1](http://lh6.ggpht.com/-cP5PfvRzaCA/VK_N9T7ZA9I/AAAAAAAADos/t2w3g_0QDxo/rant1.png?imgmax=800 "rant1.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="400" height="211"}

In the diagram above \"dev\" is the web developer who builds the site,
and \"DBA\" is the person who manages the data (for many projects this
is one and the same person). The user is presented with a web site, and
that\'s the only way they can access the data. If the web site is well
designed this typically works OK, but the user will come up against
limitations. Why do I have to manually search for each record? How can I
combine this data with some other data? These questions lead to some
users doing things like screen scrapping, anything to get the data and
do more than the web site permits (I spend a lot of my time doing
exactly this). In contrast, the person (or team) building the site
(\"dev\") can access the data and tools directly.

Eventually some sites realise that they could add value to their users
if they added an API, so typically we get something like this:

![Rant2](http://lh5.ggpht.com/-JrlLy30Rbk8/VK_N-8GeOVI/AAAAAAAADo0/C98CXvyOYVE/rant2.png?imgmax=800 "rant2.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="371"}

Now we have an API (yay), but notice that it is completely separate from
the web site. Now the site developers have to manage two different
things, and two sets of users (web site visitors, and user programming
against the API). Because the site and the API are different, and the
site gets more users, typically what happens is the API lacks much of
the functionality of the site, which frustrates users of the API. For
example, when Mendeley launched it\'s API its limited functionality and
lack of documentation [drove me
nuts](http://iphylo.blogspot.co.uk/2010/08/mendeley-api-we-bring-awesome-if-you.html).
Similarly, the [Encyclopedia of Life (EOL) API](http://eol.org/api) is
pretty sucky. If anyone from EOL is reading this, for the love of God
add user authentication and the ability to create and edit collections
to the API. Until you do, you\'ll never have an ecosystem of apps.

A solution to sucky APIs is
[\"dogfooding\"](http://en.wikipedia.org/wiki/Eating_your_own_dog_food):

![Rant3](http://lh5.ggpht.com/-xENnQgeuOqg/VK_OAvJTQiI/AAAAAAAADo8/sK3tu5CAq-Y/rant3.png?imgmax=800 "rant3.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="282"}

Dogfooding is the idea that your product is so good you\'d use it
yourself. In the case of web development, if we build the web site on
top of the same API that we expose to users, then the site developers
have a strong incentive to make the API well-documented and robust,
because their web site runs on the same services. As a result the
interests of the web developers and users who are programmers are much
more aligned. If a user finds a bug in the API, or the API lacks a
feature, it\'s much more likely to get fixed. An example of a
biodiversity informatics project that \"gets\" dogfooding is
[GBIF](http://www.gbif.org), which has a nice API that powers much of
their web site. This is a good example of how to tell if an API is any
good, namely, can you recreate the web site yourself just using the API?

But the example above leaves one aspect of the whole system still intact
and not accessible to users. Typically a company or organisation has
data, tools, and processes that it uses to manage whatever is central to
its operations. These are kept separate from users, who only get to
access these indirectly through the web site or the API.

A \"platform\" takes things one step further. Steve Yegge summarises
Jeff Bezos\' memo that outlined Amazon\'s move to a platform:

> 1.  All teams will henceforth expose their data and functionality
>     through service interfaces.
> 2.  Teams must communicate with each other through these interfaces.
> 3.  There will be no other form of interprocess communication allowed:
>     no direct linking, no direct reads of another team\'s data store,
>     no shared-memory model, no back-doors whatsoever. The only
>     communication allowed is via service interface calls over the
>     network.
> 4.  It doesn\'t matter what technology they use. HTTP, Corba, Pubsub,
>     custom protocols \-- doesn\'t matter. Bezos doesn\'t care.
> 5.  All service interfaces, without exception, must be designed from
>     the ground up to be externalizable. That is to say, the team must
>     plan and design to be able to expose the interface to developers
>     in the outside world. No exceptions.
> 6.  Anyone who doesn\'t do this will be fired.
> 7.  Thank you; have a nice day!

All the core bits of infrastructure that powered Amazon were to become
services, and different bits of Amazon could only talk to each other
through these services. The point of this is that it enabled Amazon to
expose its infrastructure to the outside world (AKA paying customers)
and now we have Amazon cloud services for storing data, running compute
jobs, and so on. By exposing its infrastructure as services, Amazon now
runs a big chunk of the startup economy. By insisting that Amazon itself
uses these services (dogfooding at the infrastructure level), Amazon
ensures that this infrastructure works (because its own business depends
on it).

![Rant4](http://lh6.ggpht.com/-BSJnYR8LNXg/VK_OEK0m3WI/AAAAAAAADpM/0329OP5qb1I/rant4.png?imgmax=800 "rant4.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="331"}

There are some things Google does that are like a platform (despite the
complaints in the [\"Google Platforms
Rant\"](https://plus.google.com/+RipRowan/posts/eVeouesvaVX)). For
example, you could imagine that most workers at Google use tools such as
Google Docs to create and share documents. Likewise, Google Scholar is
unlikely to be a simple act of altruism. If you have a team of world
class researchers you need a tool that enables them to find existing
research. Google Scholar does this. If you then expose it to the outside
world you get more users, and an incentive for commercial publishers to
open up their paywall journals to being indexed by Google\'s crawlers,
and incentive that would be missing if Scholar was purely an internal
service.

Now, giant companies like Amazon and Google might seem a world away from
biodiversity informatics, but I think there are things we can learn from
this. Looking around, I think there are other examples of platforms that
may seem closer to home. For example, the NCBI runs GenBank and PubMed,
and these are very like platforms. GenBank provides tools, such as
BLAST, that it provides to the user community, but which it also uses
internally to cluster sequences into related sets. Consider PubMed,
which has gone from a simple index to the biomedical literature to a
publishing platform. PubMed has driven the standardisation of XML across
biomedical publishers. It is quite possible to visit the NCBI site,
explore data, then read full text for the associated publications in
PubMed Central, without ever leaving the NCBI site. No wonder some
[commercial publishers are deeply worried about PubMed
Central](http://scholarlykitchen.sspnet.org/2012/09/20/is-pubmed-central-complementing-or-competing-with-journal-publishers/).

A key thing about platforms is that the people running the platform have
a deep interest in many of the same things as the users of that platform
(note the \"users\" scattered all over the platform diagram above).
Instead of user being a separate category that you try and serve by
figuring out what they want, developers are users too.

To try and flesh this out a little more, what would a \"taxonomic\"
platform look like? At the moment, we have lots of taxonomic web sites
that pump out lists of names and little else. This is not terribly
useful. If we think about what goes into making lists of names, it
requires access to the scientific literature, it requires being able to
read that literature and extract statements about names (e.g., this is
the original description, these two names are synonyms, etc.), and it
requires some way of summarising what we know about those names and the
taxa that we label with those names. Typically these are all things that
happen behind the scenes, then the user simply gets a list of names. A
platform would expose all of the data, tools, and processes that went
into making that list. It would provide the literature in both human and
computer readable forms, it would provide tools for extracting
information, tools to store knowledge about those names, and tools to
make inferences using that knowledge. All of these would be exposed to
users. And these some services and tools would be used by the people
building those services and tools.

This last point means that you also need people working on the same
problems as \"users\". For example, consider something like GBIF. At the
moment GBIF consumes output of taxonomic research (such as lists of
names) and tries to make sense of these before serving them back to the
community. There is little alignment between the interests of
taxonomists and GBIF itself. For GBIF to become a taxonomic platform, it
would need to provide the data, tools and services for people to do
taxonomic research, and ideally it would actually have taxonomists
working at GBIF using those tools (these taxonomists could, for example,
be visiting fellows working on particular taxa, rather than permanent
employees). These tools would greatly help the taxonomic community, but
also help GBIF make sense of the millions of names it has to interpret.

It\'s important to note here the the goal of the platform is NOT to
\"help\" users - that simply reinforces the distinction between you and
the \"users\". Instead it is to become a user. You may have more
resources, and work on a different scale (few business Amazon\'s
services support will be anything like as big as Amazon), but you are
ultimately \"just\" another user.


Each year about this time, as I ponder what to devote my time on in the coming year, I get exasperated and frustrated that each year will be like the previous one, and biodiversity informatics will seem no closer to getting its act together. Sure, we are putting more and more data online, but we are no closer to linking this stuff together, or building things that people can use to do cool science with.

GBIF, biodiversity informatics and the "platform rant"

![2etoq0zjwxicokm1woge](http://lh5.ggpht.com/-lgZdE0boCE0/UdwCvwl1N8I/AAAAAAAAC6U/0M-xbAOioEo/2etoq0zjwxicokm1woge.jpeg?imgmax=800 "2etoq0zjwxicokm1woge.jpeg"){border="0"
width="200" height="200" style="float:right;"}  
Jonathan Eisen recently wrote that the [PLOS Hub for Biodiversity is
soon to be
retired](http://phylogenomics.wordpress.com/2013/07/03/plos-hub-for-biodiversity-soon-to-be-retired/),
and sure enough it\'s vanished from the web (the original URL
[hubs.plos.org/web/biodiversity/](hubs.plos.org/web/biodiversity/) now
bounces you straight to <http://www.plosone.org/>, you can still see
what it looked like in the [Wayback
Machine](http://web.archive.org/web/20130430161435/http://hubs.plos.org/web/biodiversity/)).  
  
Like Jonathan, I was involved in the hub, which was described in the
following paper:  

> Mindell, D. P., Fisher, B. L., Roopnarine, P., Eisen, J., Mace, G. M.,
> Page, R. D. M., & Pyle, R. L. (2011). Aggregating, Tagging and
> Integrating Biodiversity Research. (S. A. Rands, Ed.)PLoS ONE, 6(8),
> e19491.
> [doi:10.1371/journal.pone.0019491](http://dx.doi.org/10.1371/journal.pone.0019491)

  
In retrospect PLoS\'s decision to pull the hub is not surprising. The
original proposal imagined a web site looking like this, with the goal
of building a \"dynamic community\".  
  
![Proposal](http://lh4.ggpht.com/-jyti4Rqeoas/UdwCxsLpiwI/AAAAAAAAC6k/1orC_7ICyjs/proposal.png?imgmax=800 "proposal.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="600"}  
  
From my perspective the PLoS HUb failed for two reasons. The first is
that PLoS weren\'t nearly as ambitious as they could have been. The
second is that the biodiversity informatics community simply couldn\'t
(an arguably still can\'t) provide the kind of services that PLoS would
have needed to make the Hubs something worth nurturing.  
  
After a meeting at the California Academy of Science in April 2010 to
discuss the hub idea I wrote a ranty blog post ([Biodiversity
informatics = \#fail (and what to do about
it)](http://iphylo.blogspot.co.uk/2010/04/biodiversity-informatic-fail-and-what.html))
where I expressed my frustration that we had a group of people (i.e.,
PLoS) rock up and express serious interest in doing something with
biodiversity data, and biodiversity informatics collectively failed
them. We could have been aiming for a cool database of \"semantically
enhanced\" publications that we could query taxonomically,
geographically, phylogenetically, etc. (at least, that\'s what I was
hoping PLoS were aiming for). Instead it became clear that most of the
basic services were simply not available (we didn\'t have a simple code
to extract GenBank accession numbers, specimens codes, etc., we
couldn\'t link specimen codes to anything online, and woe betide you if
you asked what a taxon name was).  
  
In fairness, it also became pretty clear that PLoS weren\'t going to go
too far down the line of an all-singing portal to biodiversity data.
They were really looking at a shiny web site that housed a collection of
Open Access papers on biodiversity. But my point is it could have been
so much more than that. We had a chance to build a platform,a knowledge
base for biodiversity data that had an accessible front end (e.g., the
traditional publication) but exploded that into its component parts so
we could spin the data around and ask other questions.  
  
Inspired by the possibilities I spent the next couple of months playing
with some linked data demos (see
[here](http://iphylo.blogspot.com/2010/05/linking-biodiversity-data.html)
and
[here](http://iphylo.blogspot.co.uk/2010/05/linked-data-part-2.html),
the links in these demos have long since died). The idea was to explore
how much of what I imagined the PLoS Hub could be it was possible to
build using RDF and SPARQL. It was fun, but RDF and SPARQL are awful
things to \"play\" with, and the vast bulk of the data had to be wrapped
in custom scripts I wrote because the original data providers didn\'t
supply RDF. As I\'ve written elsewhere, I think the cost of getting to a
place where RDF enables you to do meaningful stuff is just too high. Our
data are too messy, we lack agreed identifiers, and we either have too
many or too few vocabularies (and those we do have invariably spark
lengthy, philosophical debates - vocabularies are taxonomies of data,
need I say more). The RDF approach is also doomed to fail because it
assumes multiple decentralised data repositories are the way forward. In
my experience, these cannot deliver the kinds of things we need. The
data need to be brought together, cleaned, aligned, augmented, and
finally linked together. This is much easier to do if all the data are
in one place.  
  
So where does this leave us? In many ways I\'d like to attempt something
like PLoS Hubs again, or perhaps more precisely, think about building a
**platform** so that if a publisher came along and wanted to do
something similar (but more ambitious) we would have the tools in place
that could make it happen. What I\'d like is a way more sophisticated
version of [this](http://iphylo.org/~rpage/challenge), where you could
explore data in various dimensions (geography, taxonomy, phylogeny),
track citation and provenance information (what papers cite this
specimen, what sequences is it a voucher for, what trees are built on
those sequences). If we had a platform that supported these sorts of
queries, not only could we provide great environment upon which we could
embed scientific publications, we could also support the kinds of
queries we can\'t do at the moment (e.g., give me all the molecular
phylogenies for species in Madagascar, locate all the data -
publications, taxonomic identifications, sequences - about a specimen,
etc.).  
  
I\'ll leave you with a [great rant about
platforms](https://gist.github.com/chitchcock/1281611). It\'s long but
it\'s fun, and I think it speaks to where we are now in biodiversity
informatics (hint, we aren\'t Amazon).  


Jonathan Eisen recently wrote that the PLOS Hub for Biodiversity is soon to be retired, and sure enough it's vanished from the web (the original URL hubs.plos.org/web/biodiversity/ now bounces you straight to http://www.plosone.org/, you can still see what it looked like in the Wayback Machine).  Like Jonathan, I was involved in the hub, which was described in the following paper:  In retrospect PLoS's decision to pull the hub is not surprising.

Messaggi di Rogue Scholar

MLflow Beginner’s Guide: How to Get Started with MLflow

EOL Traitbank JSON-LD is broken

GBIF, biodiversity informatics and the "platform rant"

The demise of the @PLoS Biodiversity Hub: what lessons can we learn?