Interoperability

session

#1

Interoperability

Framing

It seems like there is much less than we’d like.
Especiallaly among open source projects that are building decentralized products.
There is a need for more.

There is a cultural and technical piece.

Culutural

Often not a good business model to have a product with open data model - people can steal it. You don’t have a silo.

People are not used to working together collaboratively.

Technical

We can look at schemas - the way data is described, stored, and used (APIs etc).

A lot of prior work has been done in data inter. space by W3C. They have models like XML, RDF, semantic web.
We could have a web where things move around like magic using APIS.
They’ve modeled a pathway.
It hasn’t been picked up.
It’s expensive.
Hard to think about working with others.

A lot of models weren’t created with users in mind, or in an iterative process, perhaps.

There’s a data formats discussion tomorrow.
Today we might want to look at cultural.
Or we can split into two groups perhaps.
What do people think?

There is a data and culture discussion at 3:40.

Why don’t we have a more interoperable world, across products?

Not automated onboarding.
There are a lot of commercial integrations, but not really interoperability.
“Facebook, Google” intergrations don’t count.

In hardware world: ANT for data communication.

There was a lot of discussion about the current tool landscape earlier.

Are there things people want to get out of this?

  • Conceptual models that people use when building. (halucinating about the world when you build your modeL)
    • Interfaces, starting with conceptual models.
    • What you’re doing, how you see it.
    • Everyone draw your schema!
  • Why don’t people interoperate more often?

Introductions / initial thoughts

Justin Fisk:
-Problem encountered frequently: working with research community.
- Priority is not sharing.
- Writing code that is bizarre.
- Don’t know standards.
- Don’t know how hard they are making it for themselves.

Weston:
-Couple of drivers at odds
- Commercial advantage - get the first-mover, crush competition
- Really hard. Herding cats, working with hidden agendas in commercial (and public, W3C etc)
- Counteracting those forces takes a lot of work.
- Sometimes the all encompassing standard leads to congitive overload.
- There are beautifully designed softwares, that get messy in implementation.
- Byzantine schema handbooks.
- Developers sometimes take a simpler approach, while ignoring standards, and it gets adopted.

Peter Donovan:
-The incentives are diverse. We tend to follow them.
-Disinteroperability is driven by focus on problem space.
-There’s a better kind of competition in the opportunity space. Less fragmentary.
-Two businesses taking advantage of market opp find ways to collaborate, as opposed to solving a problem they compete.
-Can’t get rid of incentives, without changing fundamental institutions.
-Focusing on opportunities is a position that could encourage solving the problem itself.

Ankita:
-There’s a lack of clarity in how/why we want to interop.
-It’s difficult to see what the flow looks like.
-Figuring out the workflow might help incentivize who/how to go about it.
-Get a clear picture of how we move forward.

Samuel:
-As a user, there are so many options - overwhelming. Service A doesn’t work with Service B.
-End up going with paper/spreadsheets.
-Overload of decisions.

Sia:
-It’s a design thing, and it has to do with people’s egos.
-People think they can do it better.

(no nametag)
-Potentially boring and nuanced, but licenses have a dampening affect.
-When fin service companies see GPLv3, “game over”.

Frank
-(sorry, my laptop battery died - didn’t capture this)

Carl:
-Socially, the incentives in the private sector: closed gardens = money.
-Some companies make a business model out of integrations.
-In the ag space, integrations is a not thought of as a competetive advantage like it is in the rest of the world yet.

Aaron:
-On tech level, a deficit of standards which are comprehensive and simple to implement.
-Not really a solid tool stack that thinks about your data as shareable.
-Shareable is second.
-There are lots of reasons that hasn’t been developed.

Patrick:
-Chicken and egg situation.
-Would be good to get a small set of apps that see the benefit.
-ie: OpenForest

Brandon:
-Barrier to adoption.
-Having a good demo that brings people into the community would help.

Greg:
-Need an MVP beacon on the hill.
-Ego is one thing, but natural human desire = once you’ve invested in something, hard to let it go.
-It’s hard to let go.
-It’s hard to ask someone to let it go.
-Human nature component that’s tricky.

(2 Breakouts)

Model the problem

Ankita and co breaking out to draw graphs of ideas/problems/solutions (photo and descriptions to be attached).

Discussion

Greg and co stay to talk about: Solutions to “Why interop fails”…

(The following is a stream of all thoughts expressed throughout the discussion.)

“Learner centered teaching” - teach in a way that is most effective to students.

[company] is interested in their profit, which is in meeting the consumer need. They haven’t put the consumer first, though, it’s still profit first.
If John Deere was really interested in farmers getting the most out of every acre, they might release more of that data.
Their first interest is the profit.
If they adopted that mindset, they would meet ever more need, but it’s a culture change.

There is a consumer-centered mindset - the people here thinking about open source.
Problems:
-fundraising
-status quo - people are used to their habits

Often times, people thing of collaboration as intuitive. But you need a new structure.
MSU has work on “transdisiplinary processes” - working across disciplines, and with end user.
You need to learn how to do it - it’s not intuitive. It’s a skill. There is a whole world of study.
Developers need to be willing and curious to learn about it - human psych, product dev, user prefs.
Bringing some of those people in would be valuable.
It won’t all be solved by caring more.

There are a lot of collaborative skills that are missing in most devs.

Software devs are usually on the cutting edge of the tech capacity of collab, but not on the social.

One approach might be to use synonyms.
Ontology working group is building taxonomies.
But differences still arise (“activities” vs “tasks”).
Perhaps a database of synonyms might be useful.

How do you make semantic web actually work?
“I’ve developed a cool ontology but no one’s using it.”

Do synonyms promote or discourage flexibility?
There’s a time and place for that, but how do we decide when to use it?

In crop modeling world, ontology is a big challenge.
You can express physical stuff in many ways (bushel/acre hectare, etc).
It gets to a point that there’s too much stuff to translate.
“If you’re going to have this model, use these units, acronyms, etc” (standardize for specific purposes),

In reality, if there are 21 previous “standards”, some may be useful, some not. It’s ok for multiple standards.
There’s always a tradeoff in relevance to a specific situation, focused systems (crops vs soils vs etc).
But there must be some optimum reached through consensus.

In w3C standards, (OWL etc), there are ways of describing that schemas are translatable.
The idea is that if you have a processor it could figure it out. Translate from one to another, etc.
In biology, it’s being used, but not in wider world.
Technical challenges.
Developers are working fast for profit. JSON is loosely structured - easy to use - works and is easy, but not interoperable.
There’s a tooling lack. How do I consume X ontology in JS?

What can we do as a community?

Need to define what it looks like to see what the steps are from point A to B.
People may have different definitions or visions of interopability.
Does there need to be more communication? What is the missing piece?

How do you figure out how to interact with other devs?

In research, you are time limited (similar). Time always adds constraints.

There isn’t a priority culture among developers for interoperability from the start.

Who provides the incentives to solve these things? Or to create this MVP?
There are a lot of standards boards for trying to deal with interop in specific way.
Is it possible for there to be an alternative to standards boards?
Maybe a role in negotiating communication between existing co/orgs?
Perhaps try to find funding to take pressure off that forces devs and orgs to skip the interop step.
Could someone shepherd that without being the institution that creates the standards?

FFAR conference talked a lot about interop, and they want to fly in and help interactions.

Good to have two groups: setting standards vs helping make them reality.

Is there a possibility to merge efforts? How hard is that? Can we have schemas between each other?
Maybe there’s an outside facilitator that doesn’t represent any of those groups, but helps join them up.

In large enough groups, each subdev could put a little into a pot, pay the facilitator.

A lot of open source devs start themselves small, hobby projects, they grow until this becomes a problem.

Some big companies open source their stuff.

It is very hard to talk about interop in general sense. Needs to be specific.
In specific, we don’t need 100% interop. We just need X% (<100).
Only need certain elements of data. That needs to be interop.
We never really need 100%.
Only need functional interop.
To get that in specific instances - if it’s needed, we get it done.

Don’t create a solution for a problem that doesn’t exist.

API first development solves the issue of not having interop a first priority.

Central place where you can see all the tools that were developed might help.

Achieving these goals would allow a whole service industry to grow into these tools.
Bookkeepers/consultants will start using these tools.
It’s a model that is going to emerge whether you like it or not, so do it in a way that we want to see it.

Direct market use-case:
In a world where you could host your own instance of “farm shop”, a mobile app could search across all apps using the same data standard.

Perhaps there is an industry filling the role of “interop” - with the right tools and APIs, they would become more efficient.
ie: Quickbooks became the standard in accounting.

One thing that helps with interop is better metadata in the first place.
Where did that happen? When did that happen?
Improving interop starts with a better idea of what you’re starting with.

One more thing we can do: agree that we’re going to have some basic rules within our organization to do this.
We can set rules among ourselves in a distict way: ie 5% of effort goes to interop.

Blockchain project are trying to provide technical infra to facilitate that.
Hopefully in the future these various apps can use that.


#2

Photos of @sudokita’s breakout drawings: https://imgur.com/a/nFPXdcR