Quantcast
Channel: ProgrammableWeb - Open Data
Viewing all 412 articles
Browse latest View live

Startup Enables Smart City Innovation Via Sensor Hardware

$
0
0
Thumbnail Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Related Companies: 
Summary: 

VIMOC Technologies has open sourced sensor hardware design in order to help grow smart cities infrastructure and enable use of its Landscape-Computing API platform.

California startup VIMOC Technologies has launched Landscape-Computing to provide smart cities with a scalable API, sensor-data-driven platform. Currently testing the platform in Palo Alto, Calif., and Newcastle, Australia, Landscape-Computing uses a modular design and edge processing technologies to avoid overloading bandwidth with the weight of sensor data that, until now, has been a significant barrier to the design and deployment of smart cities applications.

In a move that echoes Elon Musk’s opening up of the source code for the Tesla vehicle to help grow the electric car industry, VIMOC has open sourced the sensor hardware technology so that cities, technology manufacturers and potential startups can build new sensor-based hardware products that can work with the API platform.

Open Source Sensor Hardware for Smart City Infrastructure Innovation

When opening Tesla’s vehicle patents, CEO Musk noted, “It is impossible for Tesla to build electric cars fast enough to address the carbon crisis. By the same token, it means the market is enormous.” VIMOC CEO Tarik Hammadou and Aaron Hector, VP of engineering and software development, share a similar mindset to Musk.

Smart cities” is a concept that recognizes that cities can be more efficient, make better use of resources, heighten livability and better engage citizens by making use of sensors and open data to manage and deliver government services. For the idea of “smart cities” to really take off, however, there first needs to be a rapid expansion in the availability of the sensor hardware that is able to track and better measure resource usage and community needs. Hammadou and Hector have open sourced the sensor hardware they are using on the Landscape-Computing computing platform so that sensor device manufacturing is not a bottleneck for the rollout of smart city infrastructure.

“We believe we need to open source the hardware in order to push innovation,” says Hammadou. “In our experience in dealing with sensory devices, in order to reduce the cost of sensors and push innovation, open sourcing the hardware is essential.”

Landscape-Computing’s approach to building smart city infrastructure is to create a network of sensors across the city. A mesh network then picks up all the data from the sensors. This data is then processed at the edge, via the open-sourced neural box (“nBox”) technology. From there, nBoxes transmit key data to the cloud so it can be accessed and integrated by the Landscape-Computing API platform as needed.

Hector explains:

The pipeline for the nBox goes from the input phase, acquisition, info processing, data classification for machine learning and so on. The entire system is designed in a modular fashion to allow additional functionality. It is a modular architecture; you can add more sensor types.

Sensor data gets collected on the nBox, so all the data is handled and processed at the edge. What goes through the access gateway is the state transitions (for example, with the parking sensors, we pass on the data about whether a parking space is occupied or not), all the other data gets stored at the edge key. We are capturing all diagnostic information, as well signal strength and so on, but we are only uploading the raw state transitions. This significantly reduces data flow. We are reducing to the bare amount the information that goes to the cloud, so we are talking kilobytes per day going to the cloud versus the kilobytes of data we are collecting per second.

API Integration

“We have a RESTful API, so it is quite standards compliant,” says Hector. “We have already created a sample app using the API. We did it as a proof of concept but got it up and running fairly quickly. We are happy to offer support to third-party developers who want to create additional applications. At the moment, we have the access to our data there. You can download the API key and gain access to the data and start testing straight away.”

The Landscape-Computing API provides functionality for accessing data related to a variety of sensors (at the moment, this is predominantly the parking sensors that VIMOC has in place for its pilot projects) and for performing queries on aggregated information about logical groups of sensors. The REST API is built on Apache tools, and supports queries in TEXT/XML, APPLICATION/XML and APPLICATION/JSON formats.

So far, VIMOC are making the data from its two pilot projects available via the Landscape-Computing platform.

Pilot Projects: Palo Alto and Newcastle

In pilot project trials in Palo Alto and Newcastle (just north of Sydney), VIMOC has placed wireless vehicle parking-detection sensors to better manage on-street parking. Sensors can collect data such as location of parking space, when it is occupied or vacant and for how long it is occupied.
 

For the Newcastle study, this is also being extended with sensor data collection on pedestrian movements. The goal in Newcastle is to collect data that can help local businesses better understand how shoppers interact with retail areas in order to help revitalization and economic development strategies.

Unlike more invasive and expensive surveillance techniques, privacy and confidentiality are maintained with the use of sensor tracking; no individual data is able to be recorded. This is not about identifying when someone should be fined for staying too long in a parking space, but instead about measuring city engagement around retail hubs and the related parking needs. However, the downside to this passive sensor data collection is that the fact the data even exists can remain hidden, with residents unaware that there is the opportunity to mine and use this data themselves to advocate for things like improved public transport access.

VIMOC sees the potential for a future in which cities like Newcastle will be able to make the data and API available via their open data platforms. At present, if citizens or hackers want to make use of the data to create new civic tech, they can do so by registering for an API key, but the initial intent of the pilot is that the data will be used by the city and the local business development association to understand shopper flow through the city’s retail hub.

Hammadou shares about the pilot experience so far:

The interesting thing for us is that it has been an extraordinary learning process. When we decided to inject the same concept from Newcastle into Palo Alto, it was a completely different urban environment. There is a cultural impact of putting something like this in two different cities. When you build technology in a lab in front of your computer, it is an easy process. But building something for the Internet of Things, you need the cooperation of users and to learn from their interactions. We saw different interactions from cities and business operators in each of the two pilot cities.

Hector explains the setup of the pilots:

It was architecture first: the Landscape-Computing with the edge processing. That has really paid dividends for us, and that has really impressed the cities as we have been able to demonstrate a robust and easily expandable infrastructure. The pilot has worked really well for us because we have the technical underpinnings. It’s been a very unique way to bring hardware and software technologies together.

The approach is already gaining interest among leading smart cities and IoT forums. Cisco singled out the approach as a top-placed submission among 812 submissions to its IoT Global Challenge, while Hammadou has been invited to speak on "injecting intelligence into the DNA of the city" at the upcoming Smart Cities Expo in Barcelona, Spain (to be held directly after the first International Predictive APIs and Apps Conference, which also includes discussions of using data to help cities improve service delivery and resource use in diverse areas, from bike rental schemes to waste management).

Developers can review API documentation, test the API live in a sandbox environment and register for an API key at VIMOC Technologies'Landscape-Computing website.


Diabetes Prevalence & Clinical Research in the U.S.

$
0
0
Diabetes Prevalence & Clinical Research in the U.S. is a web application that contains an interactive map showing the U.S. prevalence of diabetes along with diabetes clinical research sites. This application allows users to view diabetes prevalence by raw number, percentage of population or incidence density per square mile. An additional layer lets users view recruiting diabetes clinical trials throughout the U.S.
Eli Lilly Clinical Open Innovation
Image: 
Company: 
Lilly Clinical Open Innovation
Mashup/App Type: 
Web
Deadpool: 
0
Primary Category: 
Secondary Category: 

One.Stop.Transport

$
0
0
API Endpoint: 
https://developer.ost.pt
API Description: 
The One.Stop.Transport platform (OST) is a platform for open data aggregation, transformation and delivery, following modern Open Data principles, standards and directives. The type of data the OST currently manages includes transportation (mass transit), traffic data (highways), points of interest and territory (mainly OSM), which are all open data. The data APIs support static and real-time data, although data providers currently contribute with static data only.
Protocol / Formats: 
Differentiators: 
A few things: 1 web store and client-side application hosting 2 real-time data through pubsub 3 there's raw data as well as aggregated data 4 several transportation protocols, not just mass transit
SSL Support: 
Yes
API Provider's Home Page: 
www.ost.pt
Twitter Url: 
https://twitter.com/OSTsupport
Developer Support: 
https://support.ost.pt/everyone/
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

SurgeProtector

Banking API Standardization Considered By UK Treasury

$
0
0
Super Short Hed: 
UK Treasury Mulls Banking API Standardization
Thumbnail Graphic: 
Featured Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Summary: 

A new initiative from the U.K. Treasury aims to move toward an open banking API standardization for the industry.

U.K. banking is soon to feel the brunt of API disruption with moves by the Treasury Department to commence an agenda that will create standardized APIs for the industry.

The move is part of a wider U.K. government agenda aimed at ensuring that citizens have better access to their consumer data. The government has previously encouraged banks, energy companies and utilities, and telcos to provide consumers with greater accessibility to their personal data in machine-readable (i.e., API-enabled) formats.

After some empty threats to legislate to ensure consumer rights to personal data held by businesses, the U.K. Treasury is trying a different tack: the chancellor of the exchequer (the U.K.’s national treasurer) issued an Autumn Statement this month with financial policies for the year ahead. According to section 1.171, "the government is keen to enable more innovation around bank data and will launch a call for evidence on how to deliver standardized application programming interfaces in the banking industry."

Industry analysts have been foreshadowing the disruptive forces facing banking for some time. Gartner analyst Kristin Moyer wrote in June that “new competitors are using open banking technologies (like APIs and app stores) and ecosystems (like partners and third-party developers) to disrupt the industry faster than ever before. For example, nonbank APIs from Amazon, PayPal, Zillow and others are two to five years ahead of retail and commercial banking APIs. Continuing on a path of isolation will lead to dwindling market opportunities and customer irrelevance for banks.”

Adrian Hausser, CEO of PayX, which provides advice to global financial and banking institutions, spoke last month at API360 in London to propose a way that banks can reinvent themselves by reorienting to become platforms that are able to make use of the transactional data they collect in big data sets all the time.

A recent study by the Open Data Institute and Fingelton Associates found that globally, some banking institutions already recognize and are responding to the disruption created by APIs, but banks in the U.K. "by and large" have yet to do so.

This is the "race to remain relevant" that Moyer argues needs to occur:

Open banking is the self-service discovery, provisioning and creation of new business models and services by ecosystems inside and outside the bank. APIs, apps, app stores, developer/partner ecosystems and other technologies provide CIOs with the ability to enable mobility and innovation, increase product and service accessibility, and create new business models.

Paddy Ramanathan, head of digital confluence at the Bank Solutions Group, sees great potential in a move toward open banking APIs. Writing on LinkedIn, he sees four opportunities that will emerge when banking APIs become the new normal:

  • “Exposing APIs and expanding community of digital developers will enable banks to innovate at scale”: As Hausser advocates, Ramanathan hopes future banks will enable an ecosystem of developers to create new products that leverage banking functions and transactional data.
  • “Monetized APIs and data will represent a significant source of revenue”: Ramanathan quotes industry sources that estimate the value of commercializing financial data in the region of $300 billion per year.
  • “Distribution of services will become ubiquitous”: Ramanathan believes banks will be able to return to relevance by being able to leverage third-party apps to meet end customers where they are, rather than remaining the monoliths that customers must come to as a destination.
  • “Overall risk in the system will go down with a connected financial ecosystem reducing losses and cost from fraud and defaults”: Ramanathan hopes that open banking APIs will mean better fraud detection and suspicious activity monitoring, and more efficient and accurate regulatory reporting, and that data-based risk assessments will reduce costs and strengthen security.

Some of these changing trends are already evident. Marc Torrens, CTO at consulting firm Strands, spoke at the International Predictive APIs and Analytics Conference last month in Barcelona, Spain, to demonstrate how APIs are enabling the firm to create innovative predictive and recommendation engines based on transactional data made available via banking APIs.

At PAPIs.io, Marc Torrens showed how Strands uses banking APIs to create new personalization and predictive products.

Torrens quoted Spanish bank BBVA’s CEO, Francisco Gonzalez, who echoes Hausser’s take on the industry. Gonzalez said that banks have a significant advantage: “the vast array of financial and nonfinancial data we accumulate.”

This view of open banking is also the model behind the Open Bank Project. Speaking at API Strategy and Practice in Amsterdam earlier this year (and as highlighted by Axway’s Mark O’Neill at the recent APIdays in Paris), Ismail Chaib from the Open Bank Project demonstrated that banks are able to utilize Open Bank’s APIs to “foster a customer-centric open innovation system.”

At API Strategy and Practice, Ismail Chaib showed how the Open Bank Project is helping banks create new innovative products by using open banking APIs.

While the Open Bank Project is creating a model and selling it to banking customers, the U.K. Treasury is investigating the potential of moving toward a more regulated approach that insists on open API standards.

Independent integration and APIs consultant Chris Wood believes the U.K. government will face several hurdles as it tries to progress this agenda. Having previously worked with Visa Europe, Wood identifies five potential barriers facing the U.K. government as it moves toward an open banking API standard:

• U.K. government projects are notorious for poor requirements, scope creep and lack of governance over suppliers.

• U.K. retail banks have complex and aging back ends with complex integration challenges. Many banks are also paranoid on data security.

• Complexity of U.K. banks' internal processes generally matches their technology challenges. The aggregate of this will make delivery across the industry challenging.

• Regulatory compliance (Data Protection Act, Payment Card Industry Data Security Standards) will need to be addressed in a sustainable manner. 

• Whilst this was prompted from an external report, any government support might be rendered null and void next year, and support this year could be electioneering.

However, Wood also suggests three ways the U.K. government could succeed:

• By ensuring a sensible, concise scope and many small, incremental deliverables.

• By doing the design up front and well. Solving the regulatory and data security issues will allow the banks to follow guidelines rather than engage in their own design process (which will takes a long time). They also need to solve the process issue. A standard API that each bank implements is one thing. How is access governed? Who can call the API? When? What life cycle does access being granted follow? Is there a subset of resources that anyone can mine that is not deemed “personal”?

• Ensuring government support lasts beyond next May.

With governments increasingly interested in mandating machine-readable data formats for business and their own departments, as interest grows in consumer rights to personal data (as is happening simultaneously in the health care sector), and as industries like banking are themselves trying to reorient in the face of massive disruption, a new strength of APIs is becoming clear. The trends that can be seen in the banking industry in regard to APIs reflect a new kind of benefit of API-enabling industries: to foster intraindustry data portability, whether it be government-regulated or industry-provoked.

New U.S. DOJ APIs Expose Legal Jobs and News

$
0
0
Thumbnail Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Related Companies: 
Summary: 

This week, the United States Department of Justice launched two new APIs: the DOJ News API and the DOJ Law Jobs API.

This week, the Department of Justice launched two new APIs: the DOJ News API and the DOJ Law Jobs API. The content available through APIs includes thousands of press releases, speeches, blog posts and law job vacancy announcements published by the DOJ. The APIs consolidate thousands of website documents into an easily accessible, interactive data set. Once an app has integrated either API, the app can search, sort and filter the data behind the API.

“The APIs are part of an effort to replace aging technology with a cloud-based, open source platform," Joseph F. Klimavicz, deputy assistant attorney general, information resources management/CIO, said in a press release. "Website content that has been migrated to the new platform automatically adjusts to fit any device, including mobile devices and tablets, as well as desktops, making the department's information assets more accessible than ever before. The open source platform also enables the department to refresh content rapidly, providing better access to information to the American public."

The two APIs further President Obama's Digital Government Strategy and Open Data Policy, which have driven significant innovation across government agencies over the past few years. The API launch resulted from an initiative led by the Office of the Chief Information Officer to replace legacy Justice.gov infrastructure with open source, cloud-based technology. The office collaborated with the U.S. Digital Service and the General Services Administration's 18F program to develop the new platform. Hundreds of DOJ component offices across the country will utilize the platform to streamline access to government data.

API documentation for the new APIs is available. Applications can sort, search and filter data from Supreme Court briefs, legal opinions, Freedom of Information Act court decisions, congressional testimony and much more. To learn more about the APIs, visit the DOJ developer portal.

The DOJ hosted a successful "usability" testing session with the GSA prior to the launch. The DOJ received positive feedback and looks forward to the launch. The team encourages developers to continue offering feedback through its GitHub page. Those interested can learn more and participate in a broad range of government API projects through the U.S. Government APIs Google Group.  

Apps For Europe Will Reward Best Open Data App With 5,000 EUR

$
0
0
Thumbnail Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Headline on Actual Article : 
Competition now open - enter your app and win 5,000 euro
URL To Article: 
http://www.appsforeurope.eu/blog/competition-now-open-enter-your-app-and-win-5000-euro
Name of Host Site: 
Apps For Europe
URL To Home Page of Host Site: 
http://www.appsforeurope.eu/
Summary: 

Apps For Europe, a support network for turning ideas for data-based apps into viable businesses, is running a competition to find the best open data applications and startups in Europe.

Body: 

Apps For Europe, a support network for turning ideas for data-based apps into viable businesses, is running a competition to find the best open data applications and startups in Europe. The winner will receive a prize of €5,000 and an invitation to Brussels to pitch for network partners and European Commission representatives. The competition is open until Dec. 31, with the final being held at Future Everything in Manchester, U.K., Feb. 26-27.

Apps For Europe is committed to encouraging developers and businesses to build new applications with open data, and by bringing an investor network to already existing competitions or hackathons across Europe (by way of its Business Lounges), it provides an opportunity to introduce open data development to investors, accelerators, incubators and the like. With this in mind, the Apps For Europe competition is about finding the best and most exciting open data apps and startups that Europe has to offer.

Anyone can enter, but entrants must use some form of open data, including at least one open data source that originates in Europe. Judges will be looking for apps that are geared toward creating viable businesses and services and that show the world the potential of open data. Applications can be entered online on the Apps For Europe website.

USC Open Data

$
0
0
API Endpoint: 
http://westernusc.ca/api/
API Description: 
The University Students' Council (USC) at the University of Western Ontario provides a web portal where students can access information on clubs, events, campus news, jobs, and volunteer opportunities. As part of their commitment to openness and transparency, the USC offers the USC Open Data API, which provides programmatic access to the USC's data.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
http://westernusc.ca/
Twitter Url: 
https://twitter.com/WesternUSC
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

football data

$
0
0
API Endpoint: 
http://www.football-data.org
API Description: 
The RESTful football-data.org API can be used to retrieve data on European football (soccer) leagues. The data, returned in JSON formats, includes information on fixtures (scheduled games), soccer seasons, teams, and more. The API is intended to hold accurate data, but the site states their may be lags with changes as data is not completely in real time. The football-data.org API is developed and maintained by Daniel Freitag, an independent software developer based in Germany. Developers can register for a free API key by visiting this link: http://www.football-data.org/register.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
http://www.football-data.org
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Data.Gov Domains

$
0
0
API Endpoint: 
http://catalog.data.gov/dataset/gov-domains-api
API Description: 
Maintained by the U.S. General Services Administration as part of data.gov, the .Gov Domains API provides a dataset of Federal Executive Agency URLs. The dataset includes agency name, URL, domain status, redirect information, and a corresponding ID. The list can be downloaded in CSV format or accessed over HTTP to view a JSON formatted response.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
http://catalog.data.gov/
Twitter Url: 
https://twitter.com/usdatagov
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Localo Aims To Connect UK Waste Services

$
0
0
Thumbnail Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Headline on Actual Article : 
Two minutes with: the Localo waste standard API development team
URL To Article: 
http://www.ukauthority.com/local-digital-news-blog/entry/5108/two-minutes-with-the-localo-waste-standard-api-development-team
Name of Host Site: 
Local Digital Campaign
URL To Home Page of Host Site: 
http://www.ukauthority.com/
Summary: 

An initiative in developement by LocalGov Makers could reduce costs and spark innovation by sharing web data protocols across waste management systems.

Body: 

Recently conceived at a LocalGov Makers Hack Day, Localo is attempting to improve UK government waste management services by developing data specifications for use in an API and web services.

The goal is to set standards across government councils and IT systems. This "end-to-end"automation is expected to decrease overall program costs, and even allow smaller authorities to deploy automation. 

The API is expected to enable users to quickly check bin collection times. It is also assumed that this standardization would help prevent vendor lock-in. 

"A more modular architecture has the potential to reduce reliance on a single supplier by allowing components to easily be replaced without having to redevelop neighboring systems," writes LocalGov web developer Ben Cheetham."It can also help increase competition between suppliers and support new entrants including civic coders because they don’t have to supply an all-or-nothing solution and the specification for the interface is open."

It is also Cheetham's belief that Localo can help to increase collaboration and industry innovation through sharing and syncing open web data regardless of internal system architecture.

Development of the Localo specification is in an Alpha state. Currenly an open Trello page is tracking user suggestions and being used as an industry research tool with the aim to priotize development features and increase overall user experience. 

Open New York Health Facility Certification Information

$
0
0
API Endpoint: 
https://health.data.ny.gov/resource/health-facility-certification-information.json
API Description: 
The Open New York Health Facility Certification Information API is a service part of the State of New York's data.ny.gov open data initiative. The API is meant to assist developers in creating health or healthcare related applications. The API provides access to a searchable dataset that holds information on certifications for New York healthcare facilities, including hospitals, nursing homes, treatment centers, long term healthcare programs, and hospices. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Open New York Health Facility General Information

$
0
0
API Endpoint: 
https://health.data.ny.gov/resource/health-facility-general-information.json
API Description: 
The Open New York Health Facility General Information API is a service part of the State of New York's data.ny.gov open data initiative. The API is meant to assist developers in creating health or healthcare related applications. The API provides access to a searchable dataset that holds general information on New York healthcare facilities such as hospitals, nursing homes, treatment centers, long term healthcare programs, and hospices. Accessible information includes the location and contact information for facilities, filterable by city, state, county, zip code, phone number, type, and more. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Open New York Food Service Establishment Inspections

$
0
0
API Endpoint: 
https://health.data.ny.gov/resource/food-service-establishment-inspections-beginning-2005-active-.json
API Description: 
The Open New York Food Service Establishment Inspections API is a service part of the State of New York's data.ny.gov open data initiative. The API is meant to assist developers in creating tools that interact with the data on Health Data NY. This API provides access to a dataset that lists all New York Food Service Establishment Inspections beginning in 2005. The searchable API can be used to retrieve the name and location of active establishments that are currently running, as well as any associated violations that were found during the inspection. The dataset is updated on a monthly basis, and therefore may not reflect any remediations made and the current establishment status. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Does Open Data Demand an API-first Approach?

$
0
0
Thumbnail Graphic: 
Primary Target Audience: 
Primary Channel: 
Primary category: 
Secondary category: 
Summary: 

Government open data initiatives are flourishing, but are they at risk of falling short of their potential without an API-first approach?

Body: 

Government open data initiatives are flourishing, but are they at risk of falling short of their potential without an API-first approach? According to Jason Hare, Program Manager of the Open Data Project for the City of Raleigh, the answer might be yes.

Hare came to that conclusion after conducting a survey of the public on the Open Raleigh website and looking at its usage.

Great Data, Not-so-great Experience

Hare’s survey found that while Open Raleigh users liked the data provided, the experience left a lot to be desired. “The public showed a favorable response to the types, frequency of updates, and the quality of the data available, but they resoundingly did not like the interface. Most of the interface comments were about latency and, sometimes, display incompatibility,” he explained. Exacerbating the challenge of building great interfaces is the constantly growing number of web and mobile browsers and platforms.

If the City of Raleigh had adopted an API-first approach, Hare suggests, “we might find that developers, to fit on current and future devices with less work on the part of the City of Raleigh, could modify the data and the exploration widgets that go with it. That would give them a better ability to build great experiences and support new browsers and platforms.”

Machines Versus Humans

If the ultimate goal of government open data initiatives is to ensure that the public has access to government data, it’s important to consider how that data gets to the public. Here, Hare made an important discovery:

“If we look at how data sites are actually used rather than how they are marketed, we start to see some patterns emerge. Open Raleigh has had 1,115,125 human page views in the last 18 months, with a majority of that in the last six months. In October 2014, we peaked at 17,000,000 API calls. In one month, we had 17 times more views [from] machines than humans.

What’s more, as Hare observes, “data consumed by humans has lower reuse value in that it is not being redistributed.” So in theory, API requests are more valuable than human page views because they have a multiplier effect.

API-first is Part of the Answer

A web/mobile-first approach that results in poor user experience and limited data reuse can come with a high cost. Hare points to the poorly received launch of the Minneapolis open data portal as an example. He also calls out CKAN, which launched a data portal for the Ebola crisis that was of limited use on mobile despite the fact that members of one of the groups most likely to benefit from the portal were likely to consume it on mobile and tablet devices.

But is an API-first approach, despite its advantages, really a panacea for open data initiatives? While API-first development is increasingly popular and API-focused development tools are proliferating, designing and implementing high-quality APIs is still far from being a walk in the park. What’s more, great APIs don’t guarantee the creation of the great end-user experiences that ultimately are required for open data initiatives to be successful.

This, however, doesn’t mean that an API-first approach can’t help address some of the shortcomings seen in many open data initiatives. An API-first approach, done right, can help organizations focus on the various use cases they need to support before they jump into building end-user applications. It can also make it easier to iterate and extend functionality without dealing with the technical debt that often builds up around APIs designed to support an existing end-user application.

Finally, an API-first approach gives organizations the ability to engage meaningfully with third-party developers from Day 1. While organizations cannot rely on third parties to make their open data initiatives successful, a good API that makes it easy for external developers to build great open data applications could pave the way to good user experience and more sharing of data.


Open New York Liquor Authority Quarterly List of Active Licenses

$
0
0
API Endpoint: 
https://data.ny.gov/resource/liquorauthorityactivelicenses.json?
API Description: 
The Open New York Liquor Authority Quarterly List of Active Licenses API is an open service of the State of New York's data.ny.gov open data initiative. The API provides access to information published by The State Liquor Authority (SLA), an organization that regulates the manufacture and sale of alcoholic drinks throughout New York. The API can be used to query active liquor licenses, and is made searchable by field types that include: serial number, license type, agency office, office number, licensee county name, licensee business name, address, city, state, issue and expiration dates, and geographic coordinates. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Open New York Daily Traffic on Metropolitan Transportation Authority (MTA) Bridges and Tunnels

$
0
0
API Endpoint: 
https://data.ny.gov/resource/mtadailytrafficbridges-tunnels.json?
API Description: 
The Open New York Daily Traffic on Metropolitan Transportation Authority (MTA) Bridges and Tunnels API is an open service of the State of New York's data.ny.gov open data initiative. The API provides access to a catalogue of data on the vehicles that pass through all 9 bridges operated by the MTA each day. Cars, buses, trucks and motorcycles are accounted for, and the dataset includes field types that such as date, bridge name, number of vehicles that paid in cash per bridge, and total vehicles per bridge. The dataset is updated on a weekly basis, and can be accessed through HTTP communication with available response types in JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Open New York Transit Subway Entrance And Exit Data

$
0
0
API Endpoint: 
https://data.ny.gov/resource/nyctransitsubwayentrance-and-exit.json?
API Description: 
The Open New York Transit Subway Entrance And Exit Data API is a service part of the State of New York's data.ny.gov open data initiative. This API provides access to a dataset including varying information fields pertaining to subway station entrances and exits. Accessible information includes the corresponding station name, division, line, and exact longitude and latitude coordinates for these subway terminals. The dataset is also filterable using any of these variables. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

Open New York Fare Card History for Metropolitan Transportation Authority

$
0
0
API Endpoint: 
https://data.ny.gov/resource/mtafarecardhistory.json?
API Description: 
The Open New York Fare Card History for Metropolitan Transportation Authority API is an open service of the State of New York's data.ny.gov open data initiative. This API provides access to raw data collected from all MetroCard swipes made weekly by each subway customer entering any station of the New York City Subway system. The data is also collected from swipes used with PATH, AitrTrain JFK, and the Roosevelt Island Tram. This data is posted every Sunday by 1AM. The data has a corresponding date and day of the week and is sorted in biweekly units. The API can be accessed through HTTP communication, and available response types include JSON, XML, and CSV. The documentation features a live testing interface to run example requests. All requests must posses an app token in order to be authenticated.
Protocol / Formats: 
SSL Support: 
No
API Provider's Home Page: 
https://data.ny.gov
Developer Support: 
opendatanydoh@health.state.ny.us
Contact Email: 
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0

iCity

$
0
0
API Endpoint: 
http://www.icityproject.eu/
API Description: 
iCity Project is a project that was developed with the intention to build up a Linked Open Apps Ecosystem based upon the vision of Linked Open Data. The iCity API offers ways to obtain information about a device or a group of devices. With this API, developers are able to interact with the iCity data, and to develop applications with the public interest as focus.
Protocol / Formats: 
SSL Support: 
Yes
API Provider's Home Page: 
http://www.icityproject.eu/
Twitter Url: 
https://twitter.com/icityproject
Developer Support: 
http://icityproject.eu/content/contact
Other: 
0
Other options: 
Authentication Model: 
Primary Category: 
Secondary Categories: 
Popularity: 
0
Viewing all 412 articles
Browse latest View live