7

I'm developing recommendations for local councils publishing event listings. Compared to other kinds of data, events data seems very likely to be used by web and mobile apps (as opposed to downloaded for analysis), and is inherently chronologically ordered and time sensitive.

I'm really not sure which format to recommend:

  • CSV is the format I recommend for most non-spatial data. It's easy to process and supported by lots of software.
  • JSON is the preferred format of web and mobile developers.
  • RSS remains probably the most widely used format for feeds of information like blog posts
  • Atom is a better format than RSS, but from memory is a bit more work.

Are there any recommendations on the topic I can follow?

EDIT

By "events", I mean public events like concerts, workshops, festivals etc. They generally have specific locations, but the people that produce the data don't seem to include lat/longs.

Here's an example.

Improve this question
2
  • 2
    The real test is to determine who the largest consumer of your dataset is going to be, and then determine what they want/how they will use it. If there are going to be thousands of people pulling it into their RSS feeder, that trumps the 100 who consume the CSV. If you expect app devs to want to integrate, then giving them a JSON endpoint will make that easy. It also begs the question why not push out multiple formats. Most modern web frameworks will give multiple renderings for free (as in free beer). But each has its merits and is tailored for a different use case.
    – Shawn Mehan
    Commented Nov 24, 2015 at 16:45
  • What type of events are we talking about? Stuff like meetings, festivals, concerts and such? Or even things like which days are trash picked up, or deadlines (taxes paid, registering for an election)? Or are they monitoring type events (police/crime reports). For anything in the future where you're notifying the general population, I'd recommend looking into calendar formats (hCalendar, vCalendar, iCalendar, etc.). It's just been so long since I've used 'em that I don't know which are the most popular / easily consumed these days.
    – Joe
    Commented Nov 24, 2015 at 21:52

5 Answers 5

Reset to default
6

The format should fit the data structure not the need of the comsumer (or the one who uses the data).

If the data is semantically stored in a json structure you can easily export the data in different formats.

So my answer is: json

Check https://schema.org/Event

Improve this answer
1
  • I agree. CSV is handy for quick tasks, but almost all serious problems require a structure of some sort. Btw, jq tool is irreplaceable: stedolan.github.io/jq
    – Anton Tarasenko
    Commented Nov 26, 2015 at 16:30
5

There is no correct answer, but here's some pointers:

Its relatively painless to convert from JSON to CSV and vice-versa. what matters is the structure of your data. If its properly formatted, you should have very little problems converting/conforming to standardized formats.

Speaking of formatting, you should keep in mind that RSS is a great route to go here, but thats more for consumption via apps than humans. When converting to JSON/CSV/RSS/etc., you should also port this out to HTML, using the correct markup (typically <table>, perhaps <ol>), while also applying semantic attributes to make the data more portable. In this case, I'd use microformats to mark up the events, so I'd apply hCalendar, as well as hEvent, and when possible, hCard and others that are applicable per event (I'm sure that will vary for each).

Whichever route you choose, I'd also be keen to implement Add To Calendar functionality for each event; what I mean is, on a page with an event on it, give users the option to add the event to their calendar, pretty much exactly how eventbrite and meetup do when you are on an events page.

W3C is working on making JSON and CSV web standards, as well as Linked Data standards for both, so again there is no wrong answer here.

Keeping the data well structured (aka prepped and ready) will allow it to be ported to standardized/supported formats, literally as many as you want to convert to. Which facilitates the spread of information, as your data is now extremely portable.

Improve this answer
1
  • 1
    I agree. the OP could build an API that offers all three data types.
    – Karsten W.
    Commented Nov 26, 2015 at 17:28
2

Just to add another format: iCalender (.ics) might be a nice add-on if the events are to be booked/bookmarked/scheduled by visitors interested in attending some/all of the events. Although the support for spatial data is limited to a plaintext field, it might be worth adding.

Improve this answer
1

It depends.
In my opinion CSV is more usable. It is older and supported by almost anything.

Is this data user will download? Stay on CSV and everyone can enjoy it, even with Excell o Libreoffice.

Is this data provided as web service? Json can be the choice.

Also consider format of the data. CSV has limitations. Array and complex things does not fit well in CSV.

Improve this answer
1

I would go with CSV. It will help your clients reach most of the audiences they interact with on a regular basis. There is no shortage of packages to read, arrange, and manipulate CSV files in languages like R and Python, which the data diggers will love. The less computer-literate will at least be able to open a CSV in a spreadsheet reader or text file application.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.