Event ID: 1980541 Event Started: 7/19/2012 2:00:00 PM ---------- >> Please stand by for real-time transcript >> Hello, everyone. I want to welcome you to our webinar today, API series, API for dummies a destruction to APIs. Before we get started, I would like to just go over a couple technical mount announcements if you're having trouble dialing in or getting connected, please send us an e-mail digital gov a GSA.gov. Can you hear me? I'm not sure, I'm not getting anything. I'm not getting anything on my screen. Let me see. Okay, great. Just want to make sure. I didn't see myself, myself on here. All right. Also, about the last 15, 20 minutes of our webinar, we're going to take some questions, so if you do have questions, please put knows in the chat box -- those in the chat boxer you'll see at the bottom of your screen, just type in your questions, and our panel will take your questions at the last 15, 20 minutes. So again, if you have any difficulties, send me an e-mail, and we'll start the webinar here in just a moment. >> I want to welcome to our webinar. I want to turn over our controls here to Greg brooks, who is the senior API strategist here at the digital services innovation center at GSA. Take it away. >> We found there's a particular amount of interest here, and one of the things you're going to see in the next hour, we're going to try not to boil the ocean, we're going to try to keep this at a very beginning, and introductory level, because we actually have a series of a total of seven webinar that we're making public. This is the first, APIs 101, but there will be six more over the next four months that we'll hear about, and it's actually there for the sake of not just beginning to in culture the initial concept of what is an API, but to begin to help content managers, web managers, executives and really, anyone in government to understand the role that API has to play in the role of government online. So thank you again for being here. We're looking forward to hearing from Fred and Jim and the work they're doing at NASA and CDC. But to begin, you can see I pulled up just the, what happens when you start to type in what is an API in google. A lot of people search that. The reason for that is it's been confusing. The actual, the term API, application programming interface, you really don't need to know what the letters stand for, and we'll oftentimes use the term API and web service interchangeably, but basically, the concept is quite understandable, and that's what we're going to talk about today. The agenda is to go through basically first what is an API, what are some examples in the private and public sector. How does the recently released digital government strategy involve APIs and what does it say about APIs? No matter where you're at, your agency or department, where do we go from here? How does my agency get started to that end, again, I won't encourage anyone to be asking questions throughout. We'll have a Q and A session at the end, and to make a note and when we get out the calendar of this, go ahead and put on your calendar, the upcoming 6 more webinar as we get into more case studies, the technical dynamics and the strategy and planning that goes into the use of APIs in government. All this is under the guise. GSAs. That was one of the aspect of the digital strategy is GSA needed to launch this innovation center in order to provide background context, information, and then the long run, guidance and tools, resources that any agency can use, because all of the requirements of the digital strategy are achievable, and one of the things we'll try to show you is APIs are your friends and they're quite adjustable. Without getting into that too much, I want to bring up a >> Fred, if I could throw to you for a moment. >> Here's a couple little definitions about APIs that have been pulled off various places and how they benefit you, but in short, we have heard the phrase "user interface" and that's the way an user interacts with your program. And at API, application prompting enter fast is the way another programmer application can interact with your system. And that's essentially all we're talking about here, it's just one way to automate a computer application to talk to another computer application, so that you don't have to rebuild things over and over and over again. If, for example, if you, if everybody who wrote a program had to write out the ways to save a file to the drive, it would be a lot of wassed and redundant work, so when Microsoft or apple builds their operating system, they build an API to say look, if you're writing a links, you want to save a document, you just us and we'll take care of the rest of it for you. So that's very quick high overview of an easy way of thinking of what an API is, and not letting the technology terms get in way >> Another way I want to suggest people to think about APIs are in the terms of match-ups. There's the work that we do at our agency, there's the projects that we can build ourselves, but then there's a really important dynamic, and I think one of the things we've seen in recent years is the aspect of, you know, what can happen out here in the Internet, you know, when people want something they actually go to Google or Yahoo, and look for it or they go to the app story. Every agency has data, has services that provide an increasing level, supporting third parties to develop around that so kind of think about what is a, what are mash-ups, what are APIs. The best place to start is to look at the private sector, so you actually go and, any website you can think of off the top of your head has an API for its content, the New York times has an API, flicker, Facebook, youtube. The reason they put them out is they understand that people can do really cool things with their content, so Craigslist, a great website. Lots of people go to crazy list.com, but you -- Craigslist.com, but they put out an API of their consent to third parties, like housing maps can build something cooler. What you're looking at is an example of when swanks takes the Craigslist API, and the google maps API, and put them together. to thinking about how your content could be useful to people, we have thoughts and ideas, but the real magic is in allowing the third party to use your content, your data for some purpose you haven't thought of yet. >> If you go to the app store or to, you know, android marketplace for apps, you find, you don't find just the Craigslist app or Facebook app, you find dozens of different apps that people have built to interact with Facebook, flickr, and that's because they put occupy the APIs, and allow that interact. Now we want to think how, what are some examples for that in the public sector and government. One of the things we're hoping you walk away with here is this idea of government as APIs. >>> To that end, you see a beginning focus online of citizens, developers, and news organizations and others start to talk about this, really, anything that we're making public to the people, whether it's information on a page, whether it's data that could be useful to someone, there's a market out there for consumption of that, via other parties, and it's one of the things we are talking about is supporting that. So what are some examples of APIs that are existing in the public sector? There's some you know of off the top of your head, and that is, you can go, and there are dozens of different ways, there's apps, websites, all kinds of ways to find out if your flight's delayed, or, I can say what time, or you know, what is the weather in Aspen, Colorado, we'll say. This is government data. It's the government that's, it's NOAA with temperatures, weather, rain, and TSA with flight information. That data is made public so that citizens don't have to go to TSA.gov, or weather.gov. They let third parties consume that and go forth and use it more. And one of the ways I think we're going to try to convey this is by the end of this viewing, you should have a good view of how you can actually find a lot of the APIs that are already being made in government, and it's more than you think, but it's also not enough, so to get to that, I want to take a little bit of time and go into two examples that are actually of a different sort, they're not the type of thing you necessarily google for, but you'll see why we're getting to this, and that's why it's not just reasons to just do APIs in support of the public. There's reasons to do it for your own internal purposes. There's a lot of pragmatic benefits that come from using this model instead of the older models of building stand-alone systems. To that end, I'd like to take a moment, I'm going to transfer over to Jim. Jim, if you're ready? Let's see >> Yes, I'm ready. >> Okay. All right. >> I'm the senior producer at NASA do the got, I recently wrapped up a 6 month detail working on the government strategies, so kind of what I want to talk about is my discovery as someone with more of a content management, web management editorial communications background, not a technical background, of how we were using APIs and data feeds to NASA.gov to talk about our story. Greg has talked about the big picture stuff, and at NASA, we are doing, doing a lot of stuff where we are releasing stuff to the public. It's not part of my group that I work with, but I want to talk about how we consume our own data, and so this is more of pooling APIs into our website, and it makes our lives a little easier on the one hand, but makes it easier to get our information to our customers. So I'm just, a couple things we do on the site. I'll run through the slides really quick. This is how we upload videos to the sites. A few years ago, we did it in a cumbersome way. Now we have a system that's kind of like a typical video management system, like a youtube upload, as you see here, you browse the video, give it a title, and this is where the fun comes N we have the collections that we can create in the system, and you can see it's a whole bunch of different NASA categories, Mars, space shuttle, Aquarius, and in addition to the collection, we have something we call genres, and those are broader categories, but means of example, you would have a solar system genre, and it would cover every mission to every planet in the solar system, but then there's a Mars collection, so and really, all that's required is when you upload the video is you check the box that applies to the category. Once we do that in the video up loads, it generates this page. This is it a page on our website, and our look and feel, but it's calling on the API of our system to pump in the actual videos did, pull -- pull in the why actual videos. And even, the why I circled these tabs, we're using it to pull in things like the most popular and top rated videos. Snow so instantly, it's more fish then the than what we used to do. This red box here is also pulling from the same video system API and it's put into one of our topical pages. I believe this is the universe page, so any video that's had the box checked that says universe will get pulled in, and this happens dynamically. As soon as the video is active with that tag, it's going to show up on this page. We also use it here on this, on the home page for video collection >> We use it on our mobile site, and this is just had mobileNASA.gov. But there are other sites to pull that feed in, so by simply uploading the system and tagging and building this API data, we can pull it in lots of different places, and most recent thing we started to do is set up a feed for our weekly, this week at NASA, so automatically go on twitter. We can always tweet anything manually as well, but we can set up the feed to be automated. Are just quickly before we had this process, it was laborious, we had to upload the video to a server, we had to generate the linking files so, involving captioning and all that, we had to cut all the images manually with photo shop or some other editor, we had to build the functional material, meaning wed to go into the C-mass a create it. We had to public multiple pages to make the stuff show up, and there was no real syndication, no way for anyone to subscribe, no way to put the feed in multiple places. It look a long time. Now, basically, you upload and tag the video, it shows upper where, and we have more time for the important stuff, so we like that. I want to show one more quick example. This is a special page we did for the final shuttle mission last July. So everything you see at the top of the page was kind of traditional static web content, but this area is data feeds, so you have a video feed on the left, latest news feed in the center, and images feed in the right, and they are all basically, these are sort of like our own APIs, internal, in a way. We are not calling on a third party in this case, but we are creating feeds by using metadate that -- metadate that to say everything we are using we'll tag. It gets put into a feed which we're consuming: Neatest one is a news field, somebody sends an e-mail, it builds a RSS, and it gets put here. Could you have a public affairs officer at the site typing in on his blackberry, and it goes to the home page and anywhere else that is consuming this. No quick, there's a lot of other places on the home page where we are using APIs, all the circles here, the add-this, sharing, twitter API, gov delivery, it's an e-mail service, what people are interested in box, which is pulling from another third party which ranks user visits, and even our own blogs are being pulled in. So point I wanted to make to wrap up is that for someone with my being, more of a content, less of a technical background, you know, it's easy sometimes to hear people talk about data and APIs, and think that's not my world, but it actually is. It's very useful in consuming your own data, it can make your life easier, number one, and just make it easier to get the material out to your users as quickly. That's all I had. I will will turn it over to Fred. >> Thank you, Jim. >> Sure. You should have it now. Here we go! Good morning, again, everyone. Just to continue on -- it's moving on me! Help. Okay. I am the technology team lead for the electronic media branch in the offices of the director at CDC, and we focus on building a lot of the tools used for our content maintainers to get their messages out to the public very well. And to echo what Jim said, we use our own APIs to help us in this process oh, similar to NASA, we consume content and feeds through APIs on our home page and various throughout our website D places throughout our website. But when we work in content delivery and trying to get content out to the public is, to as many audiences as possible, and not expecting everybody to get up in the morning and say what's new at CDC.gov? They get up and they say, well, what's aunt Sally done on Facebook? People are going to other places so our mission is to get or content out there where people are, and do it in a way that we can maintain that content and scale appropriately. So before an idea or without an idea of the APIs, to maintain content and multiple channels, it took a lot of work. Just like here, you have content in Facebook, so you have to maintain it there, you have to maintain your on RSS feeds, and do your mobile site, and if you have any mobile apps, you have to maintain, build that content in knows separately, widgits, and that takes time. Recently, Pinterest has grown up, you know, has shown up in the news. Again, four, five years ago, we weren't doing Facebook, people weren't talking about twitter. So this industry, this technology industry, web 2.0, communication, whatever cool buzz term you want to call it is changing very rapidly. And we don't know what's around the corner. so by using a system like or content services API, which people may have heard of, it allows us to use the same system to deliver the content and the channels, and it does allows you to scale better. So our content services, or syndication does allow us to push content out through the iPad app, iphone apps, or widgits it allows content shough to show up on partner websites, and we make the update, it automatically shows up as the new content on, say, the San Diego department of health. It allows us to go into new social net sites we may not know about, may not have been formed yet. It allows contents to go into games, whether we build them or somebody else does. An API has lots of benefits, and I do agree with it gray that one of the cool things about them is what is somebody going to build on top of your content? But the other aspect to think of, is what cool thing can you build, or what things do you want to build that you didn't have time for that you can now build, if you have your content available through APIs? Whether that content is textual, or images or video. It's, it really doesn't matter, but using the same sort of meddle, it really -- -- methodology, but it developing the learning curve, how are we going to get this in here. So benefits, just to reiterate these, allows you to update multiple channels quickly and you can control the changes of this content, you don't have to think this particular item has changed. Where all did we use it? We have to now update 17 iPad apps, android apps, three widgets. You change it in one place, and it ripples out. It allows, then it also, by steps of -- it allows it to be distributed. For example, if our HIV aids program updates their web page, our program doesn't have to go through and update the iphone app. It puts it out. It puts that content creation and content maintenance out to the subject matter experts where it should be. It allows us to go to the market term API. We need to develop -- we don't have the issues of where, how are we going to get the content in there. That's been determines, and ultimately , it helps lower our development costs. Initially setting up the APIs will be an investment, but it will pay off in the long run. And to find out more about, say, our content API, you can go to CDC.gov/syndication. And a quick note about generally finding APIs, there's a website called programmableweb.com. which is a vast depository of over 6000 public and private APIs, a great place to look for content. to with that, I will send it back to gray, if I can. >> Hello? Do you see my dark screen? >> Yes. >> I was in a panic, nothing was happening >> So Jim and Fred, thank you both. One of the things we're going to shift to now is more of a focus of where this con September of APIs and use of them is at government, and also, timely dynamic going on right now of digital government strategy, and so I want to tell you about what that says, and why it says what it says, and where we can go from here. And we're going to wrap up with a section on, you know, really, how does my HOC get started, no matter where you're at, where you go from here. And lastly, questions and answers at the end, so feel free to send in your questions in the meantime, but also we'll go through those and rely encourage a dialogue. So as many of you probably know, you know, late May, the digital government strategy launched and it touched on a number of elements but what we're discussing here, the role of APIs in government is definitely a central dynamic, and you can see that early on in the beginning of the actual document when it talks about the conceptual model, and what it's getting at is it is important to focus on final products. It is important to think about mobile apps, and websites, and how people will get this content. Boasts you can see from -- but as you can see from Fred and Jim both, and the CDC, there's a lot of different models by which people get their content. So it's useful to think about that in a separate fashion. That's how public interacts with content. But underneath that is just the content, the data, the uses that people have for our websites, for our information, etcetera. And that's the information layer so an important dynamic that is worth keeping in the back of your head, and it's a bit abstract, but it's your friend, is basically that you have information that your trying to get to different audiences. And then you have services that you are providing or people need to do. So filing my taxes with the IRS is a service, filling out a form to get my passport is a service. People don't actually care necessarily where they're doing that or how they're doing, if it's at the post office, online, they just want the easiest and most convenient, but the tomb service and data that you have is the content that we're talking about here, and using that conceptual model of thinking differently about what information and services do I need to provide, that's one layer, the information layer, and then the platform layer is where APIs come in. There's a lot more flexibility, and better efficiency with making the different presentation layers, so when you go down the first section of the digital strategy, it's all about this. And the encouragement and requirements, it's definitely something I recommend reading and reading several times, because this is your friend, this is something you should be able to hold in your manned, go to meetings -- hand, go to meetings, and urge others >> >> Issuing guidance, suggestions encouragement, and in the long run, requirements for adopting these norms, and it's because this is really where the Internet's going. It's not bad, it is the norm, and it has a lot of efficiencies that make it that norm. So there will be guidance coming out in November that's much Morrow bus and thorough. And then in the long run, agencies are going to be held to account to not just, you know, ignore this and kind of stick their heads in the sand, but move forward. And every agency will move forward at difference speeds and at a different age. The point is to move forward. So to that end, there's the actual steps of getting started. An important mantra you'll hear a lot is that of crawl, walk, run. Some agencies have been putting out APIs, we've going going across the web presence, and we know that a lot have. VHS, CDC, federal communications commission, PSA we could list off examples, and we'll point you in the long run to a place where you can see more examples, but we know there's enormous amount of content and data that's not been opened up that way. If a third party, if some app developer in Spokane found a way to build an app around this, it's still static content. You have to download it, they have to go and, you know, manually handle this content. So to make sure that every agency is getting started in this direction, it's, every executive department agency has been mandated by the president to be engaging with the public about taking two customer facing services that have some value or interest, and making them available via API. Now, something that's important, this is not a new burden to be placed just on like the web master's back, sorry this is not something that -- or this is not something that only the new media staffer has to care about. You'll notice, and this is really important, that every executive department agency is tasked to make sure that they are incorporating there entire apparatus to collaborate. So CIOs, CFOs, across the board, this is, you know, looking here and take this and let this be your friend because what's at issue is these requirements for agencyies. This is actually not going to be that hard, making two APIs, as we'll get to in a minute, is something, if you haven't done it already, you can do in fairly short order, what's important is to make sure every agency is getting started. To that end, we want to actually talk a little bit about how does government agency, you know, get started and where does it go from here? But the one other thing I want to put in your heads, I know it's ice take, is the "why." So there's 199 people on this webinar right now, and honestly, there's going to be a lot more meetings, conversations, you know, work that goes into this, and it's for good earrings not because it's just hip and cool. Like Fred and Jim were saying, there are very good reasons for taking the model to heart from even internal development perspective. >> You start out with active and flexible position. They will on their own be thinking along the lines, because we've gotten to a point where this is roundly considered a better mode of thinking. But honestly, after the product is built, intern management is, it's hard to describe, but basically, once you build something, whether it's a website, database or something else, you still have to deal with it, and the management of that is a lot easier whether you're dealing with something flexible and interactive, not something structural like a building. Of course, if it's content or data that's facing to the public, you're basically saying there's a reason why we put in the effort to make this available to the public. >> You don't allow -- in front of more eyeballs. You want this to be of service to what -- so supporting those third parties and making this data available via API is your half of bargain, in order to let that kind of, this ecosystem of apps and social networks and websites that are -- blossom, this is part of our agreement, and lastly, it's, there's reasons to do this within the agency as well. There's more people in your agency than you know, and there are different teams who polite benefit from this. And so, even within the building itself, when you make something available via API, you're actually letting anyone else around you interact with this material and in a dynamic way without having to go through you, and so it's more productive, efficient, and it's the right thing at the right time for us all. This is an industry norm, this supports a lot of automation, and lets us do a lot more online. Naked pictures is why we're having this -- that's why we're having this conversation. To that end, where do you get started? You know, the fact is some agencies already have a library of web services that they are making available, and they are working on this. But there's plenty of agencies, and plenty of folks in agencies, this is a new conversation, and we understand that. And that's why it's happening now. So the answer as far as where to go and how to get started is you look at what you have already. All that what you have. So the material of your website, the content, the actual pages, that's data, that's information you're providing. And do you have systems within your website. Do you have databases that the public user queerries, or interacts with or files a submission. So you want to start from the perspective of what's outside the firewall, what's already there. And then you start to ask yourself -- the initial steps for people, the crawl stage was you put this online, you make it available online. The float walk stage was we've been seeing more and more content be made available via RSS, so independent indication, someone can -- this is the run phase where you make any of that content, not just something somebody can subscribe to, but something that someone can build an entire other application. So thinking about the data that you have and the content you have front facing, holistic, somebody arrives as your home page, and starting to ask yourself, is this available via API? And oftentimes, the answer is no, so that's where you start. Then you say a couple things, first, if you have an application in development now, if you're about to put out a contract to build something, make a point right now to start inserts a few sentences into that contract, or into that work flow, and make sure you're including this, and this needs to be available API, it can really be much that simple. We're assembling some contract verbiage, but basically, getting in on contracts or projects that are under development or in the planning stages. It's simple to basically serve a requirement and you'll find you're not increasing the price substantially, not doing something, it might be a cost saving, but by getting them incorporated now, you make things easier going forward. That lead to the aspect of how do you handle material that's already out there, databases that already exist, and, you know, what do you do with what you currently have built, and how do you make that available. >> Greg, are you still showing the same green? >> Yes. >> I had a couple people asking >> I apologize, and that's -- I'll be changing the screen shortly. But the point is that basically, starting the conversation with your key departments, starting the conversation with your contractors, with your developers. The technical expertise is out there. The move is to start the conversation and if you want to see, the question has come out like where do we go from here. There will be things that come out and we'll talk about along the lines of security, and handling load, all of those aspects, I want to assure you that the Internet is these things out, there are solutions to this, there's ways to make sure you protect, that you protect your interests and you further your mission within the model, so if you want to know, like something to like at in the meantime, you want an example of some work along the lines, I'm biased because I'm on detail from the federal communications commission, but if you go to the communication commission -- FCC.gov/developer, you'll see the April awe've started -- you'll see the APIs we've put out, but here's what I want to show you. We went around and found all the agency developer hubs that we could find where they are putting out APIs, so I would encourage you to go to FCC.gov/developer, this is, you'll see a host of case studies, a host of examples, sometimes it's straightforward and easy to actually see how someone's done it and how you can follow in your paths, with some of the other data sections, they took the spreadsheet and uploaded it into sirkrata, and that is a great terms of service, solution, where you can go and use the free version next week, and then you upload a spreadsheet into here, you go over here, and you know what? There's an API for all the data, so this is one of the a dozen different ways going about this, and you don't need to worry about there being a right or wrong answer. What you need to understand is basically the water's warm, and it's worth getting in. Going forward, if you go to howto.gov. There's p a lot revolving and the strategy around un. Whether the requirements are 3, 6, 12 months, we'll be building a corpus of material that makes bailsly available all the information, all the resources, the tools you or anyone at your agency needs. >> That's a bit kind of a like tune in next time for the next exciting episode, but I gels I would encourage that -- I guess I would encourage that. There will be links here in the upcoming events, you'll see announcements with the next six webinar for APIs, and more documentation. Of course, this will be available afterwards, if you want to forward this to someone else and have them start to thinking about this as well. But, no, I always have to remind myself, watch out, after you've been talking too long, we would love to turn this over to any questions if you have, please submit them >> Yes. Greg. If you would just go ahead and leave the screen right where it is. >> Sure thing. >> We have quite a few, and I'm going to start off with one question from Mike, he says what if somebody my data/content in a mesh-up that I don't like? Why would I give them a chance to do that and hurt my reputation? He does say FYI, I know the answer to this, but it is the single biggest observation he get when talking APIs -- I'll open that question to either one of you >> Fred, Jim, would you like to talk about that? It's a question we all hear, but there's a good answer >> It is a question we hear all the time, and especially we heard that a lot here at CDC in regards though our web content. And. If it's on your website, people can do that already and don't know it. With API and proper tracking, you know where it's going, so you can at least finds those instances. If somebody goes to a web page now, copies the content, and pastes it someplace now, implore used your logo, you just don't know what that is. And with an API, you have a better chance of finding this out and generally talking with them, getting it fixed. You mutt in the terms of service, if you're inappropriately using our service, etcetera, etcetera, we have the right to shut you off of it. So that's the short answer, it's giving you control back >> It's worth basically adopting the solutions that are involved in this, not trying to avoid the problem, because the problems are going to happen. Like you say, our content is in the public domain, and people reuse it to gooder ill, in supports our friends, and gives us good re re throttle the usage >> I'm going to go to the very bottom of our questions oftentimes we have questions that people don't get, Jacob says hey, I'm not had a technical person by any means, how how do APIs relate to a service oriented architecture? >> Jim, Fred, you want to take that? >> Yeah. Service oriented architecture is a technical way of putting some back in -- how you serve out the interfaces at APIs. Generally when service oriented architecture is talking about the specific sort of format of requests, and all these other cool terms that we use, but in short, consider it the same thing. It's ways of breaking up the functionality of any of your systems into the discrete parts that could be used separately or altogether as a whole. Are >> All right. Flooding at subway >> I -- I think he's right. A service oriented architecture is built on APIs. >>> Next question comes in from Harry. At some point, how do you force a government organization to open their data via API? >> What digit tattle digital is trying to do is we're going to help you, we're going to help you along, and we're going to have, rolling out more means of you reaching to us, but digital.gov will help you do this. at the end of the day, we can't make, you can't make agencies fundamentally change, but the Internet is changing. This is, this is a -- it's not a scary problem in the long run, it's really good. It will be good for our and our constituents, but unavoidable, the Internet is going this way for a reasonable, Google, Facebook, twitter, any known brand that you can name. If you look at what they're doing, this is it. There's a reason why it's happening >> The other, another wave approaching that is you can't really make, again, any time you try to make it somebody do it the fun -- you find champions in the agency, not only from the technical perspective, but mainly from the business perspective, and there's several different reasons why this sort of approach to the content and data is very useful. From the low end of it can reduce your requests, -- those are costly to deal with. If you show how you could take your top 20 questions and have the data made available in Real-time or more or less real-enough time out through an API, your chief management officer will say why aren't we doing this. There are economic drivers in this. Are >> All right. >> I just want to jump in. I want to add one more quick thing. At some point, again, just echoing what they said, it's not really about forcing, it's just about sort of highlighting the people who are doing it and doing it well, and showing the success, so at some point, you have to do it, the people that are willing to do it, start doing it, and some people are going to get left behind, and some will embrace it. You can't put a lot of energy in trying to force someone who is resisting, you focus on the people who are having success. >> All right. Thank you so much. We had several questions coming in regarding C -- that is can you create data feed for your website if this is a static site, not a CMS driven site, and what form of CMS do you need, or what do you need to add to your existence to enable the content APIs. That's a mouthful! >> Let me start with that, and I'm going to logically throw it to my colleague at the CDC. So. Quick answer this is one of the reasons why it's really worthwhile being in a CMS, when you came in with the federal communications commission, we weren't, it's worth thinking about this going forward, that's a longer conversation. From are ways to handle, to make your content available via API, without a KMS, and it's very manual. But if you are in one, so if you go back to CDC.gov slash /-- there's about 100drupel, and we pit an open source, Busch built an open source, a module, and any drupel website can go to multiple websites, contents API, that's something which you can test, you can load into your staging environments tomorrow you can roll it out. And we did that with the onset of making this available to any other drupel website. There's a similar extension, basically, you can try out this week and launch with next week. We're going to be providing a larger Corpus of kind of background and links to all of this stuff here at howto.gov. So keep an eye on that. We're trying to figure out solutions for other CMSs as well, but Fred, do you have a second just to give a briefover view of how you handle this in a non-CMS environment? >> At CDC, we are transitions into a WCMS, so we built our consent issue significance indication system, built -- syndication system, it do the not have a CMS attached to T with our content syndication solution, anybody can syndicate content, but they could send -- but we're taking this, or content services project, we're releasing that, releasing all that code as open source, so that if you want to stand up your own version of content syndication, you don't have a CMS, the code's there. I'd be glad to share it with you. Glad to talk to anybody about this >> The point is, the solutions are out there, engaged with us, and follow up digital gov, and let us help you, because we have the technology. >> All right. We still have time for -- we have one person here, Karen. She says I am a beginner but eager to get started. I'm not technical, so cracking open a data set on data.gov probably isn't for me. Is there an easier first step that I can take? >> Yes. So part of it is context Yule to what material you're dealing with. But if you have, let's say you put out a spreadsheet that's a lot of important data and statistics, and your agency puts it out once a month, and you do it by hosting this ex-compel file, if -- excel file, if you go and sign up for sikrata, there's a term to service for, you can just upload that spreadsheet, just like a video to youtube, and it spits back something where you can embed the spreadsheet in a page, and you can offer an API of that spreadsheet. That's something which we could have the, you know, the least technology savvy person in the agency on board as a work flow, and it works! Now, with other things, and dealing with a database, or something more substantive, more significant the move is to engage with the person who is building and maintaining that system, and saying hey, I don't under the technical details, but you understand why this conversation is happening. Let's talk about how our agency gets to make this available at an API, and the technical people who maintain that understand that conversation if they tell you this is going to take two years, and $50 million, then they are being, now thinking about the right way, because the solutions here don't take two years and 50mm dollars. From are -- $50 million, there are was to make that available -- in short or the. Basically start with the conversation. With the right people >> Quick note of caution, get your security people involved in this, don't get in trouble by dumping data sets out to data.gov, or whatever. Make sure you're involved with them >>> When moving data like that, it gets into realms of policy that you may not be familiar with. >> You're absolutely right, and the one thing to factor in, there's difference types at all kinds of agencies, if you have that conversation and you're engaging with them, there shouldn't be any problem. If someone says what your trying to do is crazy and you know, you can't do it, but it's, but it don't make sense, it might just be because they're not familiar enough with this >> Right. >> And this is Fred, feel free to contact me, I talk security. >> All right. I think we have time for maybe one more question, this is from Monica. Is there a form for those in agencies who are leaving the efforts to talk to each other -- leading the efforts to talk to each other? >> That's a good question. So we're trying to start up a couple different avenues here, and keep an eye on howto.gov, we're hoping to have a calendar that will include open office hours where you can engage with GSA for helping, and other people who are there at that time. Probably going to do some experiments with google hang-outs about this. What I'd recommend doing, like I said, if you go to FCC.gov/developer and look on the right side, the agencies are the ones doing this so go there and you'll sometimes see like either e-mail sign-up or ability to reach out to the web plaster, and that's who you should be talking with. We've thought about other things, like monthly API meet-up, and then basically, I think starting there is a good way. Quickly, before people go, I'm just going to post up real fast everyone's e-mail address, I realize that's something I should have done before, but in addition to digital gov, and GSA.gov, so -- want to make a note of this e-mail address. One second. >> Are we can pass on the e-mail addresses in the evaluation that will go out >> Okay, thank you. >> Okay. Thank you. That's a better idea. >> Well, I want to thank Fred Smith, Jim Wilson, and gray brooks. Thank you for coming today and starting off an exciting series on API. We have more to come. Just quickly before everybody hops off, you'll have an opportunity to tell us what you want for hear more about APIs by completing the evaluation that each of you will receive, as well, we'll have all the slides and webinar that will be available later on today, and an entire list of up-coming webinars on APIs. I'm going to thank you, and have a wonderful day. >> Thanks everyone. >> Thanks. [ Event concluded ] the is