Royal Library of Belgium

Sven Lieber

Hello everyone,

welcome to today's Halloween edition about *data anti-patterns* that
hopefully will scare you so much you don't do them :-) Things you better
avoid when aiming for FAIR data.

Anti patterns? In short they are the **opposite of best practices**.
Common or obvious solutions that are not only *ineffective* but also
*risky*. Similar to biases, it is good to know about them so you can try
avoiding them. I mainly know the term from software engineering, but
apparently it is at least also known for project management and business
processes ([Q76438](https://www.wikidata.org/wiki/Q76438),
[Wikipedia](https://en.wikipedia.org/wiki/Anti-pattern)).

In the following I will list some anti patterns I have seen "in the
wild" that directly relate to the FAIR principles, their evil twins if
you like 🧛

::: {.captioned-image-container}
<figure>
<a
href="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg"
class="image-link is-viewable-img image2" target="_blank"
data-component-name="Image2ToDOM"></a>
<div class="image2-inset">
<img
src="https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg"
class="sizing-normal"
data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:960,&quot;width&quot;:1280,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:null,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:null,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:null}"
srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg 1272w, https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F76805904-80e4-4327-a1d9-207dc9916382_1280x960.jpeg 1456w"
sizes="100vw" data-fetchpriority="high" width="1280" height="960" />
<div class="image-link-expand">
<img
src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgdmlld2JveD0iMCAwIDI0IDI0IiBmaWxsPSJub25lIiBzdHJva2U9IiNGRkZGRkYiIHN0cm9rZS13aWR0aD0iMiIgc3Ryb2tlLWxpbmVjYXA9InJvdW5kIiBzdHJva2UtbGluZWpvaW49InJvdW5kIiBjbGFzcz0ibHVjaWRlIGx1Y2lkZS1tYXhpbWl6ZTIgIj48cG9seWxpbmUgcG9pbnRzPSIxNSAzIDIxIDMgMjEgOSI+PC9wb2x5bGluZT48cG9seWxpbmUgcG9pbnRzPSI5IDIxIDMgMjEgMyAxNSI+PC9wb2x5bGluZT48bGluZSB4MT0iMjEiIHgyPSIxNCIgeTE9IjMiIHkyPSIxMCI+PC9saW5lPjxsaW5lIHgxPSIzIiB4Mj0iMTAiIHkxPSIyMSIgeTI9IjE0Ij48L2xpbmU+PC9zdmc+"
class="lucide lucide-maximize2" />
</div>
</div>
<figcaption>daryl_mitchell from Saskatoon, Saskatchewan, Canada, CC
BY-SA 2.0, via Wikimedia Commons</figcaption>
</figure>
:::

<div>

------------------------------------------------------------------------

</div>

## Findability: the needle in the haystack

Findability is probably *the* most important principle to get started:
if you don't know that something exists or you know it but you don't
know where it is, then you simply cannot use it.

Providing unique and **persistent identifiers** for things is the common
solution to deal with findability. As easy as it sounds, there are many
possible pitfalls, some obvious and some more tricky.

- 😱 reusing identifiers

  ➡️ Recycling is good, but reusing identifiers is bad: identifiers
  should be **unique**!

- 😱 implementation details as part of the identifier

  ➡️ If you change your software or provider the identifier will change,
  hence "identifiers" such as `http://my-url.com/items?query=abc` are
  bad.

- 😱 thinking that persistent identifiers are only a technical problem
  for the ICT department

  ➡️ Providing and maintaining the technical infrastructure is
  important, but knowing the data, use cases, stakeholders and community
  best practices is just as important

From a very practical perspective, searching nowadays often happen via
Google. Did you ever try to google a persistent identifier? Often you
won't find much. The following paper investigates how FAIR persistent
identifiers actually are and which role validity can play (DOI:
[10.3233/DS-190024](https://doi.org/10.3233/DS-190024)).

By the way, there are different ways to implement persistent
identifiers. You can check out the Persistent Identifier Guide of the
Dutch Digital Heritage Network to know which system works best for you.
Just answer 25 questions.

[Read the Persistent Identifier
Guide](https://www.pidwijzer.nl/en/){.button .primary}

<div>

------------------------------------------------------------------------

</div>

## Accessibility: what's in the box?!

To stay in the Halloween theme, imagine you've *found* a secret door,
but you don't know how to open it. You would be more than happy getting
some *information* about how to *access* the room behind it: that would
be metadata about accessibility.

- 😱 not providing any metadata

  ➡️ *"~~Pics~~ metadata or it didn't happen"*. Help others to find out
  more about something (something that possibly is no longer available).
  I have heard that the phone number of a research projects' PI can be
  the most valuable piece of metadata :-) (DOI:
  [10.5281/zenodo.8344854](https://doi.org/10.5281/zenodo.8344854),
  [YouTube](https://www.youtube.com/watch?v=3J-jAFldeac))

- 😱 not using an open standard for metadata

  ➡️ After all the effort of making data available, please go the extra
  mile of easy accessible metadata, your users will thank you!

<div>

------------------------------------------------------------------------

</div>

## Interoperability: it just works

FAIR\'s tongue-twister that even grammar checkers have trouble with.
Exchanging information between computer systems without re-inventing the
wheel each time. It's all about standards (again).

- 😱 not using a standard

  ➡️ Standards are important, not just to charge your devices via USB,
  also for your data! Think of the amazing feeling when you can simply
  double click on a file and it just opens without problems.

- 😱 using a standard in the wrong way

  ➡️ Read the docs to use the standard (vocabulary) you are using to
  describe your data in the correct way. Imagine you annotate your
  website wrong and therefore it will rank worse on Google and other
  search engines.

- 😱 using a proprietary format

  ➡️ You have done an amazing job to create some valuable data, don't
  make its value and success dependent on an untrustworthy commercial
  product that may cease to exist or that only a fraction of your users
  are able to use.

<div>

------------------------------------------------------------------------

</div>

## Reusability:

You found something online, for free ... how valuable do you think is it
for your use case and to which extend are you allowed to use it?
Likewise, if you create something you probably want to be credited for,
so you should indicate how someone else can reuse what you created.
These questions concern the reusability (of data). There are a few
things to avoid.

- 😱 no license

  ➡️ No one likes to be sued! Indicate a license to give security to
  your users on the one hand, and tell them how you would like them to
  use it on the other hand.

- 😱 don't mention any sources or provenance

  ➡️ Everything has its origin, knowing it is important to assess its
  value for reuse. Based on which criteria did you curate the data?
  Which software did you use? Which data sources?

- 😱 too complicated

  ➡️ make it easy for anyone to reuse your data/software. Once again,
  this can be achieved by following standards. For example, when
  providing code try to follow common coding and installation
  guidelines.

These were just a few anti patterns standing opposite to some of the
FAIR principles. Feel free to google to find more specific data anti
patterns. Happy Halloween 🎃

<div>

------------------------------------------------------------------------

</div>

That's it for this week of the FAIR Data Digest. If you found the
content interesting, please share and subscribe. See you *in two weeks*!

Sven

::: {.subscription-widget-wrap attrs="{\"url\":\"https://fairdata.substack.com/subscribe?\",\"text\":\"Subscribe\",\"language\":\"en\"}" component-name="SubscribeWidgetToDOM"}
::: {.subscription-widget .show-subscribe}
::: {.preamble}
Thanks for reading FAIR Data Digest! Subscribe for free to receive new
posts and support my work.
:::

::: {.fake-input-wrapper}
::: {.fake-input}
:::

::: {.fake-button}
:::
:::
:::
:::


Hello everyone,  welcome to today’s Halloween edition about
<em>
 data anti-patterns
</em>
that hopefully will scare you so much you don’t do them :-) Things you better avoid when aiming for FAIR data. Anti patterns?

FAIR Data Digest #20

Imperial College London

Henry Rzepa

The site [fairsharing.org](https://fairsharing.org/) is a repository of
information about FAIR (Findable, Accessible, Interoperable and
Reusable) objects such as research data.  
![](https://www.ch.ic.ac.uk/rzepa/blog/wp-content/uploads/2018/04/240-1024x478.jpg){.aligncenter
.size-large .wp-image-19605 loading="lazy" decoding="async" width="450"
height="210"
srcset="https://www.ch.ic.ac.uk/rzepa/blog/wp-content/uploads/2018/04/240-1024x478.jpg 1024w, https://www.ch.ic.ac.uk/rzepa/blog/wp-content/uploads/2018/04/240-300x140.jpg 300w, https://www.ch.ic.ac.uk/rzepa/blog/wp-content/uploads/2018/04/240-768x358.jpg 768w, https://www.ch.ic.ac.uk/rzepa/blog/wp-content/uploads/2018/04/240.jpg 2044w"
sizes="(max-width: 450px) 100vw, 450px"}

A project to inject chemical components, rather sparse at the moment at
the above site, is being promoted by workshops under the auspices of
e.g. [IUPAC and
CODATA](https://iupac.org/event/supporting-fair-exchange-chemical-data-standards-development/) and
the [GO-FAIR initiative](https://www.go-fair.org). One aspect of this
activity is to help identify examples of both good (FAIR) and indeed
less good (unFAIR) research data as associated with contemporary
scientific journal publications.

Here is one example I came across in
2017.\[cite\]10.1021/jacs.6b13229\[/cite\]. The data associated with
this article is certainly copious, 907 pages of it, not including data
for 21 crystal structures! The latter is a good example of FAIR, being
offered in a standard format (CIF) well-adapted for the type of data
contained therein and for which there are numerous programs capable of
visualising and inter-operating (*i.e.* re-using) it. The former is in
PDF, not a format originally developed for data and one could argue is
closer to the unFAIR end of the spectrum. More so when you consider this
one 907-page paginated document contains diverse information including
spectra on around 60 molecules. Thus the spectra are all purely visual;
they are obviously data but in a form largely designed for human
consumption and not re-use by software. The text-based content of this
PDF does have numerous pattens, which lends itself to pattern
recognition software such as OSCAR, but patterns are easily broken by
errors or inexperience and so we cannot be certain what proportion of
this can be recovered. The metadata associated with such a collection,
if there is any at all, must be general and cannot be easily related to
specific molecules in the collection. So I would argue that 907 pages of
data as wrapped in PDF is not a good example of FAIR. But it is how
almost all of the data currently being reported in chemistry journals is
expressed. Indeed many a journal data editor (a relatively new
introduction to the editorial teams) exerts a rigorous oversight over
the data presented as part of article submissions to ensure it adheres
to this monolithic PDF format.

You can also visit this article in Chemistry World
([rsc.li/2HG7lTk](https://rsc.li/2HG7lTk){rel="nofollow"}) for an
alternative view of what could be regarded as rather more FAIR data. The
article has citations to the FAIR components, which is not published as
part of the article or indeed by the journal itself but is held
separately in a research data repository. You will find that at
doi: [10.14469/hpc/3657](https://doi.org/10.14469/hpc/3657) where
examples of computational, crystallographic and spectroscopic data are
available.

The workshop I allude to above will be held in July. Can I ask anyone
reading this blog who has a favourite FAIR or indeed unFAIR example of
data they have come across to share these here. We also need to identify
areas simply crying out for FAIRer data to be made available as part of
the publishing process beyond the types noted above. I hope to report
back on both such feedback and the events at this workshop in due
course.

::: {.wp_orcid_field}
[https://orcid.org/0000-0002-8635-8390](https://orcid.org/0000-0002-8635-8390){target="_blank"
rel="author"}
:::


The site fairsharing.org is a repository of information about FAIR (Findable, Accessible, Interoperable and Reusable) objects such as research data. A project to inject chemical components, rather sparse at the moment at the above site, is being promoted by workshops under the auspices of e.g. IUPAC and CODATA and the GO-FAIR initiative.

Messaggi di Rogue Scholar

FAIR Data Digest #20

Examples please of FAIR (data); good and bad.