Tip:
Highlight text to annotate it
X
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 *** 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