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.
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
One thought on “Bridging the Gap Between Data & Audiences (part 2): Building an Open Source Website”