Are Riverscapes-Compliant tools FAIR?

[joewheaton]

Please see this discussion of FAIR in the warehouse inspired from Wilkinson et al. (2016; DOI: 10.1038/sdata.2016.18).

@KellyMWhitehead and @jtgilbert you both should read that paper and think about how we make our tools FAIR. The purpose of this discussion is to propose that Riverscape Compliant Tools should also be FAIR.

In one sense, they are partially through F, A and R by being open-source GitHub repos. However, the Interoperability part is one we need to think about. I guess with an API to Riverscape Tools through cybercastor they are? @MattReimer and @philipbaileynar what do you think?

Our current criteria for compliance are:

Tools are designated as “riverscapes-compliant” when they meet the following criteria:

• Tool Status of Operational-Grade or Higher
• Code produces riverscapes projects as output of all analyses
• Project Type is registered with program.xml in Program Repo
• Has been vetted by the RS Science Committee (i.e. has a “Report Card”)

I don't think that we want to raise the bar that for tools to be Riverscapes Compliant they have to be fully FAIR. I think that the I is most typically going to translate into needing to have an API to access it and I think that is too restrictive. I could see this being something that we add to tool grade and discrimination (i.e. Production Grade Tools might get this)? I could also see adding it to report cards. @MattReimer and @philipbaileynar what do you think?

[joewheaton]

Maybe I'm thinking too narrowly about interoperability? Maybe just by being riverscapes-compliant and writing project files they are interoperable with RAVE and hostable in the warehouse and therefore good to go?

[MattReimer]

In my mind Interoperability

To be Interoperable:
I1. (meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.

XML is our language of choice. It is formal (i.e. validatable using published and public XSD), accessible, sahred and broadly applicable.

I2. (meta)data use vocabularies that follow FAIR principles

No idea what this means. I don't understand how a vocabulary follows FAIR principles. Is this as easy as making sure our Metadata keys are unified and recognizable by people in our field?

I3. (meta)data include qualified references to other (meta)data

This we already do in that our RSContext project layers reference the ScienceBase dataset they came from. Also projects that derive from RSContext are able to cite which projects their inputs came from.

Always room for improvement though.

[joewheaton]

I2. (meta)data use vocabularies that follow FAIR principles

No idea what this means. I don't understand how a vocabulary follows FAIR principles. Is this as easy as making sure our Metadata keys are unified and recognizable by people in our field?

That is all I took from the paper @MattReimer. In fact, I think it falls on us (the scientists in the riverscape consortium, not the developers... so you're off the hook) to define and agree on that vocabulary. To a certain extent, things like the Fluvial Taxonomy do just this. Then where it comes back to the likes of you, @KellyMWhitehead, @nick4rivers and @philipbaileynar is to realize this why I will be insistent at times about business logic, naming, file names, organization of projects, etc. It is not because what you guys have done is NOT technically correct or workable. It is so that it is consistent with the vocabulary used in the field. There are also really important pedagogical implications to this when we align our tools and data with our theory and how we teach... everything makes more sense.

I3. (meta)data include qualified references to other (meta)data

This we already do in that our RSContext project layers reference the ScienceBase dataset they came from. Also projects that derive from RSContext are able to cite which projects their inputs came from.

Always room for improvement though.

Exactly my interpretation... we're already doing much of this just like they suggest!

[philipbaileynar]

I will do some more thinking on this, but I think we should celebrate that we are already extremely FAIR:

• Switched to using OGC data formats (ditched proprietary ShapeFiles and File GeoDatabases).
• Riverscapes tools are free.
• Tools use extensive (but still could be better) metadata, the definitions of which (XSD) are published.
• Most tools have documentation (obviously always could be better).
• We use APIs extensively and our APIs themselves are self documented.

I will read the paper and happily tackle low hanging fruit. But I'll take the FAIR pepsi challenge with most other scientific initiatives.

[joewheaton]

I think we should celebrate that we are already extremely FAIR:

That was my impression to @philipbaileynar! I think we should pat ourselves on the back as we're following these principles without really knowing it. The other really good news is this is mainstream standard of practice in other fields of science (most of these guys seem deep in the biomedical and biological sciences) and we can point to that for making the case that our discipline needs to get its act together!