Data Sources

The previous post explained why a streamlined structure for organising cultural event data is necessary for creating an open data source and what currently is offered in terms of a method for this type of event schema.

Turner Contemporary (photo: Benjamin Beker)

Once a standardised method of tracking cultural event data online is decided upon, it can be utilised by any organisation that aims to add others’ event data to their website or downloadable app. All this related data has to be stored somewhere, and most websites store data in databases. There are several options available; some you might already have access to if you have Microsoft’s Office Suite, which includes Excel and Access, and some are free, like MySQL, an open source database. In addition, if you do not already have a website, there are several user-friendly methods of creating your own website either from scratch or using site-provided templates. Excellent sites that allow users to create their own websites are WordPress, Drupal, Blogger, Google Sites, and Jekyll.

Additionally, there exists online software that focuses on facilitating open data websites, such as CKAN and DKAN. Both CKAN and DKAN are mostly utilised in government-related websites, not events or culture-related data. Currently, the UK government uses CKAN alongside Jekyll, which is primarily a blogging platform, just like WordPress and Blogger, and the US government uses CKAN alongside WordPress. CKAN is built using the Python programming language, while DKAN uses the PHP programming language. DKAN is preferred by those who already use PHP or Drupal since users do not have to learn a new system or programming language. DKAN has many of the same functionalities as CKAN, and it’s seen as a complimentary offering to CKAN.

Whichever platform is chosen to build an open data website, the standardised vocabulary discussed in the previous post needs to be utilised in the website’s HTML to document all cultural event information. Most websites allow users a choice of editing the HTML either as text or through a more user-friendly interface. The text version is necessary for embedding the metadata for the cultural event data. While this may seem intimidating for those who do not have a programming background, it really is a simple task. All that is required is the addition of tags around the pertinent information. The difficult task is deciding upon a standardised vocabulary!

Have you thought about creating a website listing cultural events data or adding cultural events data to your current website? What types of problems have you encountered? Please leave your comments below!

In the next post, we’ll take a look at some of the apps that are possible when you have access to cultural event data that is also open data.

Read the previous post: Bridging the Gap Between Data & Audiences (part 1): Background for Creating an Open Data Source for Kent Cultural Events

This is the third blog summarising the challenges around setting parameters for our ambitious data pilot. At this point it is probably a good idea to remind ourselves of the guiding purpose of the pilot:

The aim is to create a single data source that can be used as the basis for a variety of digital platforms and applications that can, in turn, help to:

Showcase Kent’s cultural assets to the broadest audience possible.
Promote the county as a cultural destination for residents and local, national and international visitors.
Ensure people are aware of what’s going on in every part of the county, wherever they are.

It’s also important to remember that the project has grown a bit since its first inception and now includes more qualitative experiments in collaboration and engagement to achieve the three bullet-points – but which can also feed into the data-driven work.

As the last two posts have shown, with data collection and management, the devil is in the detail. We now have to wrestle with some specific decisions on how to progress.

It doesn’t seem reasonable to expect people to input data into a new, separate database so, if they only input data once, should it be into a central source from which relevant information is pushed out to their websites? Or should we make something that pulls that information from what they are already doing into our central data-pool? Or could we just select one of the data sources currently available and adapt it and encourage others to use it (e.g. the Visit Kent website, the Kent Online website)?

Which are the organisations whose information is essential to give us a worthwhile critical mass? How do we make sure it is still relevant and easy for smaller cultural organisations to take part? What’s our definition of cultural? Would it be useful to have information about restaurants, bars etc as well as the traditional arts / culture organisations? Could including this kind of information lead to an application which would help visitors plan whole itineraries? Or would it dilute our primary purpose?

Should we try to work out one big master plan? Or should we try to use more Agile-like processes?

And when we have our amazing data pool, what are we going to use it for? Probably not yet another website, given the proliferation of websites currently available … maybe an app or, what? And once whatever it is built, how will we market that tool? Questions that we will begin to answer over the next little while. We’ll let you know how we get on!

Read the previous post: Tracking Down Cultural Data in Kent (part 1)

Read the previous post: Tracking Down Cultural Data in Kent (part 2)