What is the purpose of this session? Get to a shared vision of how we see interoperability in the future, and what are the steps to get there. Figure out where OFN is now, what it is we need
What outcomes/deliverables do we want? A vision statement and roadmap (which then needs to be prioritized obviously)
Who is facilitating? Myriam
Who is scribing? Gen
Context:
We had 2 external people in that session Sylvain (HappyDev, Startin’blox) and Simon (Virtual Assembly) to get inspired by their prospective analysis of the evolution of the web, their understand of standards, the prototypes and functional projects they have built toward that vision.
Morning:
Morning is about all getting on the same page of understanding.
OFN shares about current features, API current reflection, use cases for what we need the API, etc. Objective = shared understanding of what there is today and the unmet needs.
-
OFN lead devs share the current situation:
- general architecture overview
- API current status and what exists beyond what has been documented so far
- first integrations experiments (Lynne already shared Zapier experiment, and Pau shared Metabase one)
-
OFN product people share a summary of the use cases that mean we need to go much further (20 min)
- ex: custom standalone websites, specific integrations need with warehouse / accounting / invoicing / CRM / … tools, producers who sell through multiple hubs using various platforms having to refill their inventory, etc.
-
Sylvain and Simon share about the vision and prospective analysis of web evolution toward semantic and distributed standard, and illustrate that with their functional prototypes and live applications, showing also the backside of them.
-
Myriam and Rachel share the status of Data Food Consortium (DFC) and the problems we faced in technical phasing and UX issues and the plan we came up with.
Afternoon:
Afternoon is about brainstorming from all the co-sensing of the morning.
- Determine whether a shared vision of where we want to go has emerged
- If no, what are the hot points/divergence points? How to leverage them?
- If yes, then how we get there, what are the steps?
- How much of a priority do we feel this is compared to all the other things?
- Is there any way to cooperate more broadly (with GRAP, with CERES, etc.) to co-fund things, like some open source module in web-component for hubs BI and reports, etc.
Lunch can be about what it triggers within ourselves, hope, excitement, fears, etc. and that could crystallize into prototyping some shared vision and plan in the afternoon that could lead to some system change (theory U pattern !).
Summary:
Luis and OFN team described the main OFN features : multi-tenant marketplace, shops, catalogs + inventory, order cycle notion, tags, directory, flexibility in payment and shipping methods, etc.
Luis share his vision about evolution of OFN API : https://docs.google.com/presentation/d/1dWbxwekBLtUMzj-9XuCXDH0Yib10P-tL6G7VcsmZ2n8/edit?usp=sharing and use cases.
Sylvain share about political vision on evolution of the web and the standard. Economic models evolution, other than monopolies can work, and lobby / GDPR might impose data portability in open standard.
We then went more into technical aspect of those standards ! LDP (API standard), SOLID (universal standard), etc. And presented various prototypes, Transiscope and Data Food Consortium with Simon, chat application with Sylvain.
That led us to discuss technical aspects of SOLID, LDP, web components, new architectures in that new tech world. Myriam shared new business opportunities it could open in our ability to enable food hub to have custom software, built easily from small interoperable web components, like you build a website on wordpress. We somehow agreed that this dream was great and that it can be good if a research team wanted to work on it, BUT there is some uncertainty about if/when those standards will become mainstream and broadly used, and given the resource scarcity we are in and all the mess we have to sort out to answer the most urgent users needs and maintain the current platform, we cannot use time and money from current OFN product team/pipe. So this research group has to self-fund itself somehow, but the community is happy to stay connected with research progress, so we should maintain a flow of info to keep the team aware of how it’s moving forward.
Actions:
- Do a quick spike about what it would take to respect the LDP standard when reworking on our API (beyond the current plan which is JSON-api). To see what it would cost to start respecting the standard from now open opportunities to be interoperable asap. If it happens to be not really more costly / marginal, we can discuss and decide if we want to do it.
- @paco is joining Data Food Consortium and will make the connection to pass info to the rest of OFN tech team about the tech progress, discussions, decision to keep tech awareness of DFC ptototype.
- The research team (mainly @MyriamBoure with support of @sylvain and Simon) will see if they can find money to finance some prototype within OFN context on shopfront / reports, and work on business plan / fundraising strategy to finance that project.
Detailed notes:
Kirsten - these questions have been with us forever - how much should OFN do internally versus connecting and cooperating with other projects
There’s never been an opportunity to address this before because we were always in crisis mode
We’re now in a position where we can ask “how big can we think about what’s possible”
Maikel - OFN was sold to him as a distributed network, so he was disappointed that this hasn’t really been realized by OFN thus far, but exciting now that we’re talking about realizing this aim. “Single instance” feels like it could be the wrong direction in this regard, but open to discussion.
1. OFN’s current position
Luis offers an overview of OFN’s future architecture for Simon and Sylvain
Link to full presentation
For any enterprise, permissions are assigned to owners and managers, but also other enterprises
Food Hubs can draw from own and producers’ stock, which can be listed with different prices in the database
Tags used to allow e.g. different payment methods for different user types on the same product
Main user types:
- Basic profile (enterprise) - on map
- Online shop (enterprise and shop) - producer selling own products / producer selling own and others’ products / food hubs selling others’ products - these statuses are handled with flags in the system
1 server for each instance, built on rails
Angular used for the shopfront
2. OFN’s vision for interoperability
Luis - “We’re not an app, we’re an API” - distributing control and development opportunities
OFN API is one of the tools offered by OFN
Could integrate with Odoo through the API
Control layer: who has permission to have what data and do what with it
Zapier can hook into the API or the database
Different types of API: Catalog, Checkout, Order Management, Directory, Content
Luis: this will be expensive - it’s not the shortest, cheapest path, but it’s the right way to go
Kirsten: should we also be asking whether there is another path that’s more achievable within the resource constraints?
Myriam: better to discuss alternatives this evening. Let’s see if we can agree on an ideal, blue sky path first
e.g. Shopfront in UK can use a catalog in France
Use cases:
Could allow others to create new business models around OFN - e.g.developing better shopfronts, etc.
Swagger is the de facto tool for documenting APIs
Some students have already started this for OFN
https://app.swaggerhub.com/apis/haseleyi/ofn-staging/0.1#/
Very different use cases for e.g. frontoffice and backoffice tools - important that the API for the shopfront is simple, while the back-office needs to have lots of functionality
For simplicity, we might start with 1 API with everything to start, but keep in mind that these will separate in the code structure in future
The major issue with APIs is that they can’t be changed once they’re established, as it’s a promise to integrating clients. that’s why standards are so important (DTF)
API to do list:
Make Spree API usable OR Luis proposes deleting it, as it seems that nothing important depends on it - will test
Luis - in terms of BI, API is not obviously more expensive than the alternatives
Pau - expresses some concern on this point - seems that it might require more ongoing dev attention than the alternatives
Maikel - scope query - there’s been a lot of focus on reporting and business intelligence - is this the main application of API? Or is there just implicit agreement that it’s the most important for OFN right now?
Kirsten - there’s an immediate business need for BI, whereas e.g. building a global shopfront isn’t at the top of the list of priorities, but it is one of the applications of the API approach
Pau - this is a way of replacing existing ad hoc solutions
— Coffee break —
3. Sylvain from GRAP
Missing - will catch up later
4. Sylvain and Simon’s presentations
Political vision:
- Sylvain: The internet is becoming more and more centralized, but it was not supposed to be this way. Tim Berners-Lee intended that the internet would be distributed. But data exchange standards were missing, and this has led to centralization. Now trying to roll this back by establishing the standards.
- Simon: interoperability between heterogeneous systems is possible, but it’s expensive. To do it affordably, we need great homogeneity through standards.
- Sylvain: SOLID is about giving people the opportunity to store their data wherever they want and still access whatever networks they want (opposite of lock-in of Facebook, for example). SOLID covers a variety of standards, including Semantic Web.
- Sylvain: The HappyDev/OFN application can thus be a commodity/service rather than the platform.
- Simon: big recent evolution in SOLID is triplestore - subject- predicate-object.
- Sylvain: was in Boston earlier this year to meet with Tim Berners-Lee’s company, Inrupt. No public announcement yet, but expected soon. GDPR includes rights re: data portability, but doesn’t say anything about the format - Sylvain suggests that a law will be passed to say the standard should be open.
- Sylvain: Big question is whether OFN a software or network of people
- Simon: explains interoperability in terms of ontology, semantic web
- Myriam: briefly introduces Elziard, a new project which takes advantage of Semantic Web
- Sub-project - Greenhouse of Knowledge - open-source platform for sharing best practices
- Open source
- No need for hierarchy and centralization, importance of transparency
- Very close to OFN except selling digital services instead of food products
- Same undergirding model
- Has established a network local small collectives
- used Solid to build a toolbox for developers
- Can be understood as a replacement for Slack that operates at the network level. Extra features: skill directory, job board
- every local group of HappyDev will create their own instance and can choose which features to include - these instances can then link up with one another, or with the general HappyDev directory, so users in one org can communciate with users of other orgs
- Open source, coop
- Spinout from HappyDev
- Startin’Blox provides technology that helps groups build apps based on Solid
- Startin’Blox is a cooperative
- building an application in place of a website. Collectives build the “bricks” they need, and these “bricks” can fit together like lego
- offers a vision of the web for tomorrow
- A lot of value for today’s actors.
- A digital tool through which they can talk to everyone in the network
- Non-profit
- “We can’t break the social silo without first breaking the technical silo”
- e.g. Transiscope
- 3 systems of authentification
- Silo (local)
- Common (centralized)
- Distributed
- Very likely they’ll get funding next year for developing this for food systems within France and across borders
- Ontology - structure of the objects - what things do you have
- Taxonomy - relationship between objects - how do you describe the things you have
- Myriam - the choice of ontology/taxonomy is a political choice - e.g. it was a political choice to align our ontology/taxonomy with Open Food Facts
- Community gathering around the DFC project - Open Food France, La Cagette (?)
- 2 years focused on the ontology
- Now, proof-of-concept: a 2-step use case prototype of sharing catalogs between organisations, mapping of data flows
- Responding to the problem of lacking unity of information across databases - chose to partner with Open Food Facts to develop the ontology - global system for creating unique IDs for each food type
- The ontology will always be driven by the use case
Luis: What’s the relationship between Solid and the OFF food ontologies? - Solid is the infrastructure, the ontology is the (format of the) content
Kirsten: What’s the stage of development of other DFC members? - Food Assembly is not doing well (pulled out of UK, downsized in France), so they don’t want to dedicate resources to DFC.
Have we got a shared vision at this point?
Lynne - fear about starting from scratch to get to an impossible ideal
Sylvain - vision the ideal, the figures out next steps from where we are now
Pau - what’ I’m missing now is a reflection of our discussion in terms of business needs, user needs
Kirsten - coming at the question from a resource-constraints perspective. Seems like DFC is valuable only to OFN France. Better to articulate in terms of a use case so we can see how this relates to user needs across instances.
Sylvain presents the general Solid app logic
- 1 server with 4 functionalities:
- Data validation
- Permissions
- Storage
- Notifications
- Client and agent apps can send and retrieve data from this server
- Based on HTTP
- no need for data transformation because all data is LDP
- Provision of server space to users would be an optional service - the software works equally well whether the data is stored by OFN or elsewhere by the user
- Potential OFN use cases:
- Client app could be a reporting tool for enterprise reports
Pau: How does the dynamic aspect fit into Solid? Through the DFC ontology
Lynne: this is great theoretically and politically, but I can’t see the pathway from where we are now to this.
Maikel: suggests transferring to Solid gradually - treat Solid, in the first step, as a standardized way of storing data rather than a whole new way of building OFN.
Myriam: OFN instances could mutualize funding around the components that are moved into Solid
Luis: This is great, but it’s radically different from everything else we’re doing.
Kirsten: seems that DFC ontology is compatible with what OFN is now, and necessary, so we can at least start that step.
Luis: Suggests that Kirsten is thinking of standard API, and this is very different and separate to DFC ontology and semantic web.
Lynne: I struggle to see a business here - easier to maintain? speed of development? would be a big gamble on there being a critical mass of users to develop
Kirsten: maybe we can keep our investment low to start with to reduce this gamble
Myriam: dream business case - we could become the WordPress of food enterprises
Matt: we would need to do a hell of a lot of work to get to the point of evaluating the potentialities here
Pau: can we not use the shared vision for the future to solve the problems that we have right now Kirsten: i.e. if there are multiple solutions to a current problem, do we pick the short-term efficient solution or the solution that takes us closer to the long term vision
Kirsten: part of OFN’s problem in recruiting devs is the fact that we are using outdated technology. Maybe this is an exciting new software for attracting devs.
Pau: I feel the opposite - we’d be severely reducing the pool of devs to draw from, as today it’s niche
Luis: feels like Bye Bye Spree can happen in the next two years, transitioning to Solid is more like 10 years.
Kirsten: Is Solid only readable to some? Would we need to duplicate? i.e. create a general API and a Solid API
Maikel: Solid is as normal an API as any
Luis: JSON API is very simple, significantly extra work for Solid API - not necessarily too much extra work, but significant
Simon: The most time-consuming aspect would be data transformation - Semantic Bus
Myriam: but DFC could potentially fund this work through 150,000 euro raised for adaptation of data from the first platform
Simon: this isn’t a technical cost - it’s a conceptual and functional cost
Myriam has in fact already done at least some of this work for product lists
Myriam: is the a potential for a partnership with Startin’Blox? Co-funding web components, prototyping, etc.
Sylvain LB: hard to say at this point, when it’s not clear right now whether OFN is on board, but certainly interested.
Kirsten: seems like these are two tracks. OFN isn’t going to move all of its resources into transitioning to Solid right now, but it seems like it could be developed alongside at the same time. I can see the value add of Solid, and it aligns with the goals of OFN, and its a direction that we definitely want to pay ongoing attention to.
Luis: 2 pain points: 1) software learning curve; 2) risk - value of buying into a new standard is dependent on buy-in from critical mass of others.
Sylvain LB: if you’re going to implement an API anyway, it’s less risky to do so by adopting at least a standard
Simon: what’s the cost to OFN if DFC finds the funds the do the data transformation and Simon volunteers to do the work. Sylvain LB also volunteers to do some work on this.
Myriam: important to avoid splitting the OFN community
Kirsten: reassures that this isn’t a case of splitting, it’s just a case of exploration
Maikel: emphasizes excitement about the potential here, even if we don’t have a use case right now
Kirsten: would be so exciting for OFN to be at the cutting edge of technology for once!
Pau: 3-month funding cliff too much of a burden right now to get excited about this
Myriam: DFC is the baby of OFN through Open Food France. We should think about this not as a funding drain but as a way of raising funds.
Kirsten: Myriam and I are very aware of the funding constraints. But we’re in a better position than we have been for years. So we can do both and we can get money for both.
Rachel’s summary:
- There are different types of standards - web standards and DFC
- The DFC ontology has only been taken up within Franch so far, so there is a risk there
- Unclear how much work the data transformation for DFC will take, so we need to assess this
- Maybe we need to determine whether this work is appropriate for the platform OFN or the network OFN
- Recognises the risk of splitting the community
- So we need to determine whether there’s a step that we can already take now, or do we need to assess the risks first
Pau: as long as it’s a separate exploration project for now, that’s fine. But OFN as a whole shouldn’t
jump in until we have enough information to correctly assess the risks.
Francois: this is just a presentation - we don’t have to make a final decision right now
Luis: next steps fairly obvious - if DFC has some money and manpower, we should just do this, since there’s obviously a POC coming out of this.
Lynne: seems like this is a request from Myriam, Simon and Sylvain LB to be an R&D team within OFN - in which case permission granted
Closing discussion: what next?
It seems that we’ve landed on pursuing two paths in parallel:
- Within current roadmap:
- 2-hour spike compare API LDP effort vs JSON API (could be done at the gathering in the work session tomorrow morning?)
- Semantic Bus to make OFN API compatible with LDP
- OIDC implementation?
- R&D project - to be done by non-OFN devs:
- Make external shop in web component - Myriam and Sylvain
- Explore the reports for use cases - Myriam and Sylvain
- Build a business plan and raise money - Myriam
Kirsten: there needs to be no cross-subsidization of the R&D project from the OFN global budget right now. Any and all costs must be covered by the DFC testing budget.
Resources:
- Simon can do the test of Semantic Bus for free; would cost to implement for the full API translation
- Francois volunteers (2hrs/fortnight)
- Pair OIDC expert with Francois and Simon
- Myriam will chase funders to fund this experiment