 Good afternoon, everyone. Thanks so much for joining us and for coming today. We have a few more folks coming in. Thanks for joining. Good afternoon. My name is Brandy Byrd, and Gaurav Ramakrishna is here with me. And today, we're going to talk about a project, an open source project called Agstag. And before we get into what that is, you can see from the screen that Agrec, excuse me, not Agstag, Agrec is agriculture recommendations. And before we get into the specifics of what that means, I'll go into the next slide to give you a preview of what we'll talk about. First, I do want to talk about the team, because without our team, Agrec or Agstag, for that matter, wouldn't exist. I'll also talk about the vision, what Agrec really means, and the vision, the impact that we hope Agrec to actually make in the community. And then we'll talk a bit about the players. We'll talk about Clemson University and their partnership, as well as partnership with the Linux Foundation and Agstag. And also, we'll talk a bit about Call for Code, which is the organization that Garov and I are from. And lastly, Garov is going to talk about the Agrec solution and some of the technical decisions and frameworks and tooling that was used in Agrec and why we made those decisions. And finally, Garov is going to take you through what our roadmap looks like ahead. All right, so the core team, a year ago, probably a little over a year ago now, none of us knew each other except for Garov and myself. But as I said, Garov and I come from the Call for Code team, and I'll talk more about what Call for Code is for those who don't know. I see a couple of folks in the room with a Call for Code t-shirt on, so I know you guys know, but for those who don't, I will give you an overview of what that is. I'm a software development manager and Garov is our lead developer for Agrec, among other projects, and it just so happened that Garov has become our lead for all of our agricultural open source projects. And Sumair Jihal, some of you may know him, but he's the executive director for AgStack, which is a consortium that came out of the Linux Foundation, and he has been instrumental because each person on this core team has been able to contribute and develop Agrec through AgStack, so we certainly wouldn't have the project without Sumair. And the other two individuals, Kindle and Mallory, are from Clemson University. In full disclosure, I'm a graduate of Clemson University as well, but Kindle, he's a precision agriculture engineer, but he's also the director of the Edisto Research Center, which is in Blackville, South Carolina, and Mallory is his program director, and they work closely together, so this is the team. You can tell that Kindle and Mallory, with an agriculture background, have been instrumental, but I'll get into more details about the exact contributions that they've made. So the vision, and before we get into the vision, I do wanna give you a little more personal background about me and why this project is special to me and why I was most interested, and not just because I'm a graduate of Clemson University or because I work in Call for Code, but growing up, one of the things that I always remembered my grandfather saying, and for me, I grew up in South Carolina, so he was always granddaddy, and that's what we called him, and we were really close, and one of the things that he always said was never sell the goose that laid the golden egg, and for a kid, it's like, well, what does that mean, right? And it took me a while to realize that he was referring to land as the golden egg, and it was so valuable to him. It was valuable to my great-grandfather, my dad, and every generation I can remember growing up, everybody had a farm, and I grew up in a really small, rural part of South Carolina, and everybody in the community had a farm. You had to drive everywhere because nothing at that time was within walking distance, but whenever you drove through town, you would see farms, you would see cows, and we had cow crossing signs, and we still have those because agriculture and farming was just so instrumental in our community, and there was so much built around the land and the farm. It was family, it was community, it was growing up in these environments. So for me, growing up, these were staples that I saw, and when I came to call for code and had an opportunity to work on open source agricultural projects that were meaningful to real farmers, the same small farmers that I saw growing up in my family and in the community, it was meaningful to me. So this is not just a project. I think all open source projects are meaningful to us, but it was important to me personally to be able to participate in this one. So with that, I do wanna give you a bit about what vision we had when each of us came to this project. Like me, growing up in a small, rural town, there are others and some of you may know about the Cooperative Extension Service. I see a couple of heads nodding. Well, where I grew up, there were these regional offices where farmers could go into the office and if they had a problem with their farm or if they had crops that weren't growing, they could go into these regional offices and get help from these agents, Cooperative Extension agents, and it would be free that they could get this help. So that was a huge part again of the community. And today, rural farmers still use this service. I went to vote earlier this month and I looked up and I saw this sign that said Clemson Cooperative Extension Service. So it was one of those small, rural regional offices for Cooperative Extension. So having said that, rural farmers are still using the Extension Service, but it has evolved a bit in the hundred years that it has existed, but the problem was that rural farmers were using these books or manuals and they would be out in their fields on their tractors with these books and flipping through pages and figuring out, okay, what is this disease? Is it a disease or why aren't my crops performing or my soybeans or peanuts performing and growing like I think that they should? So if you can imagine yourself, especially in Austin heat, it's hot, your plants are not growing and you've got a book and you're sitting on a tractor, that is not the best experience. So that was a real problem that we saw and we had a vision to modernize that whole experience. So that farmers would have access not just in their one region, but what if we were to imagine a framework where rural farmers in the small South Carolina town where I grew up to farmers across the world and India and other places that have the same Cooperative Extension network, if they were able to make use of a framework where they could get recommendations and advice and information and community, even from a framework where they don't have to drive into an office. They don't have to have a physical manual that they carry with them when they ride their tractor out into their fields. What if we had a system? What if we could build that? And by the way, what if it's open source that anybody can use this framework? So that was the vision that we had and we just started to build and build and build on top of that. And we said, well, we've got all these extension services around the world. What if we bring them together and every person, every extension service has some different information that they can contribute. But what if we make the framework open and all of these contributors and data providers? And even if you're not a part of an extension service, but you're a researcher and you have data that you can provide, what if we create a framework where anyone can lend that data and make it available to farmers across the world? So that's what we came up with. And we hope that's what the impact will be. All right, so I talked a little bit about Clemson extension, Clemson Cooperative Extension. And this is not a plug just for Clemson, but they're the first ones that contributed and the first ones that we've been working with. So we kind of use them as a model when we talk about cooperative extension. And so this picture in the top right is an aerial view of the Edisto Research Center. So you can see they've got farm animals, they've got their crop production fields, they've got on farming demos and research. They've just, they've got youth education. They've got all of these different resources there in one place at their research center. And in addition to that, they still have the regional offices that I mentioned. So cooperative extension, and not just for Clemson, but I'm sure this is the case for other extension services across the world, they focus on research, education and outreach in the community. And that's really important for what we wanna do. Let's go into the next slide. All right, so that was the cooperative extension. Their role in ag rec. So they were one of our partners. The other partner in this is Call for Code. And there are a couple of folks here from Call for Code. Yep, a few people. And Call for Code is, it is the largest humanitarian open source effort of its kind in the entire world. And I've been at IBM for a few years and it wasn't until 2021 last year that I discovered that Call for Code actually existed. And it exists within IBM, but certainly is open to developers, both technical and non-technical alike. But it's like no other organization that I had ever heard of that focuses on open source solutions that make a real impact on people, real people in the world. All of the other projects that I had participated in at IBM were commercial products and projects, which is expected because that's what IBM does. But for IBM to make room and to make space for this particular open source effort that focuses on helping real people in the community, like the farmers that I mentioned and many others, I thought was just amazing. And the next slide shows some of the solutions that Call for Code has supported over the years. And Daniel is here, he was with Call for Code from the very beginning back in 2018. And beside him, Charlie, he participated in the first winning solution that Call for Code sponsored through its global challenge back in 2018, five years ago. And that's when it all began. Charlie, his solution was called Project OWL. And it's all about providing a mesh network so that first responders and others can communicate when natural disasters happen. And there's no internet, for example. We need a lot of that now with climate change. Also, Prometato in the following year was a way to protect firefighters by having predictive analytics so that they could measure toxicity exposure. So, harmful and toxic gases, for example, measuring their temperature, making sure that they're okay as they're going into these stressful environments. And we've had other solutions over the years from agrily last year to SAFEQ and our Call for Code for Racial Justice solutions, which happened in 2020 after the murder of George Floyd and Ahmaud Arbery and Breonna Taylor and so many others. Call for Code really stepped up and people across the community within IBM and even outside of IBM wanted to be a part of these solutions that tackled racial justice. And those solutions are still being deployed and piloted today. And finally, this year through our Global Challenge, which started in April, this is our fifth year and not to make this about the Global Challenge, but it's our huge contest every year that makes each one of these solutions possible. And it's an opportunity for developers all over the world to participate. So I think we've got a QR code at the end for those who are interested in participating. You can go to Be My App, which is the platform that we're using this year for the Global Challenge. And there is a $200,000 prize for those that win if that's an incentive. And finally, there's a third partner in this Beyond Call for Code and that's the Linux Foundation, which we obviously all know about. And I'll just briefly say here that the Linux Foundation is the one that was the reason for AgStack and why it exists. AgStack came out of the Linux Foundation. And also I'll mention here that all of the, or most of the projects that were on the previous slide, you can see listed here and they're deployed within the Linux Foundation website. So if you're interested, you can go to the Linux Foundation website and participate there. I'll quickly mention AgStack, although we want to work with those third-party agriculture applications and developers, which we are doing, but AgStack itself is about building the stack, you see in the middle. So if you look at this at like a sandwich, the meat is in the middle. And so where it says frameworks, that's where most of the open-source solutions that AgStack develops, that's where we sit. That's where AgRec sits. And Gaurav is going to talk more about that. Hi, can you hear me? Hi, everyone. Yeah, so AgStack is, you can say, call it as a repository or a space where all the, there are a couple of projects under AgStack like user registry, pest models, ML data sets, repositories. One of them is the AgRec project. So it's a circles around everything around agriculture-related projects. They wanted to create this open-source space where it's vendor agnostic and where it's friendly for everybody to utilize some of these frameworks, either on your own deployment infrastructure or to integrate with your existing applications. Again, this is to enable all the recommendations or informations related to agriculture to come under one repository so that globally it can be accessible and utilized. Because as we see today, there was a biggest challenge. When we look at agriculture-related information online, you have to go to respective websites which are all in the form of PDFs or HTML contents. And there's no easy way of integrating with any of today's modern technologies, especially when there are data intensive where you want to retrieve the data. You have to pull it, you have to parse through the data, pick up all the key words and points that is useful and then leverage into your solution. But with AgStack, coming up with this concept where they're providing an infrastructure or space where projects are designed to easily integrate with existing applications or enable to run on self-deployment to utilize that information to help local communities or farmers. That was the goal of AgStack. And I pass it off to Brandy again. There's one slide, I think, so it's yours. All right, so this slide, and I'll speak to this really quickly so that Garov can get to some of the technical solutions that we made for AgRec. But this slide basically shows how AgRec was born from contributors from AgStack, Clemson and Call for Code. And I'm gonna let Garov talk about the APIs that are a part of AgRec and what makes it what it really is. But again, this slide was just to show that this really truly was a community and collaborative effort between the three of us but also to stress the fact that we don't want it to just be the three partners. We want more and more people to contribute. We want more ideas and we want to grow the community. So I think Garov has a slide where he's gonna talk about that. Okay, thank you, Brandy. So we know that Clemson Extension Services were storing all their recommendation informations as part of their PDF files or HTML content of their website. Now, for anybody to leverage that information, it could be farmers or third-party agriculture-based applications. There was a lot of work they had to do, either download it, use it as a printed files around or take their manuals of extension services offices or for applications like AgRole or Liquor Prep which are focused around helping farming communities for them to leverage these recommendation information. Integrating or pulling these data sets was the biggest challenge. So at the same time, when we decided about creating this AgRec project, one of the biggest challenge, we wanted a database to store this recommendation information, but we didn't know how to extract that right information from these files. So we asked Clemson team to help us in extracting this important information by referencing to some of the information shared by FAO which is a food and agriculture organization from United Nations, a couple of other agriculture-based applications to understand how would the data sets look like and what are the important information that usually farmers would need into day-to-day activity based on the experience Clemson University were interacting with their farmers. So that user journey experience from them helped us to create a sample data set that Clemson University actually shared with us and we decided that we'll have a database to store this information. Now, to access this information, we wanted user-friendly interface. That is one for data providers such as Clemson extension services or any other extension services on the world to easily upload their data sets from an user interface and that data sets to be very protective. This is because if we allow users to access these data sets to manipulate tomorrow, they can change anything. So the goal was to create a user interface dedicated to data providers such as extension services or anybody who has recommendation or knowledge about farming data that they think it will help to upload easily and protected at the same time. And also we wanted to provision this user interface to scale tomorrow to enable other categories to such as pest models or diseases information. So we initially wanted to start off with just crops because that is abundantly grown everywhere but slowly we want to scale that user interface to allow data providers to add information about pest, diseases or anything related to other recommendations in agriculture domain. The other side of user interface we wanted is access of this useful information from the community which could be farmers, which could be day-to-day gardeners or anybody who's interested to leverage this information into their day-to-day work. So we wanted to provide that user friendly interface with simple search options, provide some sorting and filtering to navigate them easily to the right information they're looking for. And also we thought that we should have a backend service to interact between the front end and backend and also enable some APIs that we can publicly expose it as an open APIs, especially the ones which can share this information. So we initially started work with crop but slowly we want to expose some of the other APIs related to different categories of agriculture data. And then finally we wanted to open source this solution by deploying at Axtac Cloud Infrastructure. So this was the initial requirements we gathered up and we came up with this high level architecture design where you can see we have a central server which has user interface, a backend service and a database. And again, as I mentioned, we wanted the user interface to help data providers to add data easily. And then we have another side users who could be farmers, day-to-day gardeners who can quickly access this information through a user friendly UI. And also we wanted to provide APIs that could be exposed publicly to programmatically integrate into other applications who want to quickly integrate this information or use this information to provide more better recommendations or for their solution work. That was the goal. And some of the benefits as you can see here is easy access of this recommendation information, easily programmatically integrated from other third party integration. And it provides an easy user interface for both data consumers and providers to share their information and access this information over the browser. Coming into the user interface that we are planning to design, we would like to thank Mojo.net team who are volunteering to contribute in designing and developing the user interface. And I also take this opportunity to thank Dr. Kendall Kirk from Clemson University who helped us introduce Mojo.net team and contribute to this project in helping and creating this user interface. So we are connecting with them. We are currently at the stage of designing the user journeys and also some of the initial wireframes to come up with the user friendly interface for both data consumers and data providers. Some of the discussions we discussed was we wanted a very responsive user interface that is to support on multiple portable devices or cell phones. This is because usually farmers walk around in like wide fields where they need portable access to quickly access this information. That was one of the reasons we wanted to make it mobile first friendly interface. And we chose React framework over here. One of the things we wanted to keep in mind was we wanted to make this project open source. We wanted to leverage open source technology. We had discussions about other frameworks like Angular, Vue.js, and React. Some of them suggested Flutter, but the whole goal was we wanted the whole community, including the contributors to easily contribute. So that's why we picked a framework that is widely used today in designing user interfaces and mobile first applications and native applications. So we decided to go with React user interface. And finally, we wanted to make this application a progressive web app packaged into a progressive web app because we understood most of the farmers, when they go to their fields in remote regions, they have very less access to the internet or network connectivity over there. So we wanted to enable the offline functionalities. That's why whenever they have network, they wanted to download the data sets or useful information and store it in local cache. And then when they have no connectivity, they can go and utilize or see this information. For the back end service, to align with the front end, we want to stick with the same JavaScript level. So we decided to go with Node.js here and combine with Express so that we can easily spin up some APIs, which comes with ready-made functionalities and packaging from Express. And we also wanted to represent our responses, all the API responses in JSON representation. So we have created a couple of sample data models to bring back the response in JSON representation, as you can see in the image. This is one of the response body, which will be returned back when you query for a crop information. And we also wanted to create a back end service that way that tomorrow, if we want to integrate any services along with this back end, it's easy to integrate. And also, if we want to create other services tomorrow to enhance our recommendations for the farmers, we can easily create those services on the back end service. A couple of APIs, which we have created at this initial point based on the sample data that is shared by the Clemson University, that is for the crop data, are just as simple as get plans, which will bring a list of all the plans that is stored in the database. Get a plan based on an ID. If they are based on the list of plans, if somebody wants to query specific plant information, then they can query based on it ID. And then it will bring back another operative information about all the plans. And also, we want to provide other crude operations, for especially the data providers from extension services to easily manipulate the data or change in future, because we learned these data sets will change over time with all the climate change happening around. The recommendations will change so they want to go back and change. So we want to provide options such as update and delete if that don't exist and create. And we have one post to add new for data providers to add. And the other thing I wanted to highlight is we wanted to protect all the APIs such as post update delete, which is specific to the data providers. That way, other users will not have access to certain information that is published by a particular author from an extension service. For the database, we know we wanted to have a database to store all this recommendation information. We had big discussions initially, which one to pick, whether should we go with the NoSQL database or a SQL database. I think that debate never ends. I think it all comes down to a preferential of what is comfortable for individual developers or contributors. And again, I have no personal opinion in either of technologies. It's widely both NoSQL and SQL databases are widely used today. And both have great open source databases available. Since a lot of our community in participating in this project were interested in the relational databases, because we also saw the crop data structure, which the sample data which was shared by Clemson University had many structure. For example, if you take a metadata level of information, then there is other sub-level of information, like where is this crop based off? We had to add location information. Then we had to add information such as, what are the related diseases that is possible to affect this particular crop? And also, we wanted to add other information, like seeding rates, the irrigation information. So there were so many related information for, if you take just a crop as a high-level metadata. So that's what we thought, OK, let's go with the relational database. And since Postgres is well known and widely used database in the open source community, we thought let's go with Postgres over here. And we chose Postgres. Couple of other things we had kept in mind was we want to normalize the data. Although the data we all came with research papers or information in PDF files and HTML contents, we want to extract the key information and normalize it and store it in a database that way there's no heavy sentence or pages involved. So that's why, as you see, I have a small ERM diagram that I extracted from Postgres to showcase what are the key attributes that we're using over here. Another thing, relational, as I explained, we wanted to make it relational to add more information to a particular meta-level information. For example, if you take crop, we wanted to add anything which is related to crop as a separate table or separate schema for that to expand, and also to provide an option to scalable tumor if there's additional information which we have missed. Let's say there's another extension service. They think that this particular crop has some other attributes that is relevant to a different location. We can easily add that object as for a different location and then also scale it up to a different model to integrate easily to the existing crop. And also we wanted to avoid redundancy which we think is one of the great challenges today where when we don't have track of the datasets which has been accumulated, we easily start accumulating redundant data, so that's why we want to keep it simple and so we want to use relational over here, and finally to make it open source. There are a couple of, as we are speaking for the project, our immediate steps right now is currently we're working with Mojo.net team in creating the user-friendly user interface. They're helping us and working with the Clemson team on the user journey in order to create wireframes, so they're helping on that. At the same time, we are working with the Clemson team to validate some of the plant information and the sample data that they have shared and if there is possible to add more information. And also we are gathering more requirements to enhance our whole application to accommodate more categories of agriculture related information apart from crop which we are currently working on to scale it to and provide more information there. And finally, also Axtac has other topics of interest where we wanted to integrate authentication process which Axtac is also creating another project called user registry for which we want to integrate our project with to enable login authentication and authorization. As a midterm, we want to test our application, get feedback from different stakeholders that could be any user who is interested to learn about ag-rec or use the solution and integrate into their solution that way we can work on it and create more robust and enhanced application. We want to deploy the solution on Axtac Cloud. We are also thinking about containerizing them and deploying it into a container or Kubernetes environment. Finally, we want to add documentation so for external contributors to easily contribute to the project as well as deploy on their systems or regions for their local communities to help access this information. And finally, as a long time, we want to invite other extension services and communities to help us grow and we want to continuously integrate over the solution and make it improvised and more robust for the family community and help sharing this information from the Clemson or any other extension services. As I said, we want to welcome a large contribution here. It's not dedicated just for developers. Test us on the tech level. We want a contribution. We welcome contributions from a large community who can help us to scale this application in as simple as even like validating the application, creating tasks where you can say, hey, some functionality is not working or somebody looking at the documentation process and telling, hey, some of this information is not working as expected. Can you make a change? Simple as that. And again, we want to welcome anybody who is an expert in agriculture field who can help us validate some of this information or the solution we are creating so that we can always improvise it and make it better for our users. I would like to welcome everybody to join us in this effort and take part in this project. You can go to our Slack. ActStack has created a Slack. That is the link which I've shared over here. We also have public bi-weekly meeting on Zoom on alternate Thursdays from 11 AM to 12 PM ET on a Zoom link which I've shared here. Also, we have a public Google Drive where we capture all the initial documentation requirements which we have created for this project and we'll be posting continuously as a public shareable knowledge for somebody to access and be part of this project contribution. Also, I want to like to take this opportunity to mention that how today open source technology is ubiquitous and accessible for everyone. At the same time, we all know it's also vulnerable for some of the attacks. So that's why I want to highlight that how IBM is taking steps to help improvise this security where we are giving education and knowledge for free for everybody to take part in it and then contribute back to us. So feel free to explore this blog post where you can learn more about the IBM knowledge store of sharing the security aspects on how they're working with OpenSSF to improve the security for the open source industry. IBM has hosted a code cafe. Please feel free to drop by. There's some fun stuff happening over there. And feel free to pick up some of the cool slags whenever we get a chance. And thank you, everybody, and open up to questions. I'll take yours first, since you lifted it. That's a really good question. I'll let you answer some of that. But I do want to repeat it for those who are virtual. I think I heard you say, do we provide or does AgRec provide recommendations on crops that are non-food crops, such as textiles? Did you want to answer that? Yeah, sure. Like I said, at this moment, we have not tapped into that side of the data sets, because we are working from one piece by piece. Like I said, we initially started off with crop. That's one of the main extension knowledge that Clemson is offering. I'm pretty sure there are other similar information, like you mentioned, which we want to scale. So that's why we are designing AgRec in such a way that, like you mentioned today, this is a very good feedback that we can take back and work towards provisioning that in our application tomorrow, so we definitely will consider that. Thank you so much. I think we got a new contributor. Yeah. And I think we have time for one more question. OK, and the question is, how are we thinking about scaling this to more prevalent farmland areas, especially for those that don't have access to internet? How do we scale up? I think you spoke a little bit about scale. Yeah, so if you see in our user interface, we wanted to package our whole interface as a progressive web application. The reason for that is to enable this offline functionality. Well, at least we recommend that farmers will go to a region where they have this internet facility to go and quickly download the information that they want on their application level. So the idea is here to locally store it or cash that information for them for that day. So whenever they go to the remote places where there's so internet activity, they can easily see that information so that they can take activity. And again, we can always scale this application. We have other COFACOR projects related to this liquid prep, which measures the soil moisture value in real time and provides recommendation for a farmer to crop their, sorry, what are their crops today or not? Similarly, we have other project or agrily, which gives them a crop management tool, which studies the weather they have created an AI ML model that looks back five years old weather history and recommends for this year, for this season, what is the right crop they have to grow and what are the right weather conditions and what are requirements. So there are other applications which have been designed, but we are definitely looking to work with them collectively and make it more extensible. And we just have open arms for suggestions on how we can scale, because that's such an important aspect of this in the roadmap, how we scale up. So certainly open to not only contributions, but thought leadership and how we can scale. So I think that's an important question and would love to have even more feedback. And I think that's all we have time for, but thank you so much for listening for your questions. Thank you. Thank you, everyone. Thank you so much, everyone.