GMPTE Travelline meeting

[julianlstar]

I have just returned from doing a presentation at the national
Travelline meeting at GMPTE. I was invited to present on Open Data in
Manchester, the Open Data Cities project and DataGM along with
Victoria Moody from Trafford Council.

After the meeting there was a short discussion that orbited around the
twin issues of risk and control as far as releasing timetable data was
concerned. A couple of people raised the issue of data accuracy and
what happens when the data is wrong or not current, and who is liable
if a school trip gets stranded because the information that has been
supplied by an application was erroneous.

Although I get the feeling that Travelline is broadly supportive of
releasing their data openly, these issues are thorny ones to contend
with. So to bullet the questions that came up:

• What happens if the data gets used badly (not necessarily
maliciously) and who is responsible?
• Does the community want raw data, or does it want to access the data
through an api that handles individual requests?
• How and why would the currency of the data that an application uses
be maintained?
• What happens if the developers of the application decide they don't
want to support it any more?
• Can we rely on the community (developers) to interpret complex data?
• How do you deal with errors both in the raw data and from the
application?

A lot of these questions have come up with other sources of data, but
I would appreciate ODM thoughts on this, as these questions have to be
answered.

BTW I must thank Peter Stoner, from Travelline who invited us to speak
and who was at the last ODM event.

Julian

[Jag Gill]

Julian -

These are really good questions, that are relevant to a lot of open data initiatives. 

With your permission I'd like to use them as a basis for general discussion at Open Data Sheffield this month. Hopefully we'll have some useful contributions to feed back.

Best

Jag

--

Jag Gill

MundoJumbo Ltd

skype: jag-gill

phone: +44 7968 948527

email: jag...@mundojumbo.net

twitter: @jagusti

MundoJumbo Ltd is registered in England & Wales: Company No 07006390. 

Registered office: The Workstation, 15 Paternoster Row, Sheffield, England, S1 2BX.

 

The contents of this email are confidential to the addressee and are intended solely for the recipients use. If you are not the addressee, you have received this email in error. Any disclosure, copying, distribution or action taken in reliance on it is prohibited and may be unlawful.  Any opinions expressed in this email are those of the author personally and not MundoJumbo Limited who do not accept responsibility for the contents of the message. 

[Rob Gough]

Forgive me, but while some of these are indeed interesting issues at least three of them seem to have rather obvious answers to me.

• What happens if the data gets used badly (not necessarily
maliciously) and who is responsible?

The application developer. How could it not? Though in this case, the only "badly" that I can think of is writing an app and then failing to update it with the latest data (perhaps I'm being naïve here?), that leads onto the other point...

• What happens if the developers of the application decide they don't
want to support it any more?

Making data available does not (or at least, shouldn't) make you liable for the ways in which it's used and certainly doesn't make you responsible for any apps that are created using that data. Why would anyone think that it would? I would argue that they are responsible for the quality of that data, which leads on to...

... and who is liable if a school trip gets stranded because the information that has been

supplied by an application was erroneous.

Firstly, the teacher - for not verifying an important trip with the bus companies. Though surely there aren't many examples of this sort of thing (i.e school kids would go on a private bus on a trip, at least where I come from :P).

If the application is displaying incorrect data, incorrect as in what is displayed is different from the data supplied, then that is an application error (assuming a non-malicious alteration). It's a bug. Ultimately bugs can hardly be blamed on anyone but the developer. I'd like to think most developers (of which I am one) would agree with this.

If the data supplied was incorrect, the blame then lies with the person who released the data. In the case of bus timetable data presumably this error would also be reflected on their own timetable website, and is effectively no different from publishing the wrong data there. You apologise and release the fixed data ASAP. Incorrect data my cause people to miss appointments or meetings, and even make them a little angry/upset - but it won't cost anyone their lives. I can't think of any data that is likely to be released that ever would. 

This then raises another interesting question though. There will always be a delay from when the data is updated to when that change is reflected in any sites using that data. Who is then to blame? Or perhaps more appropriately, what is the expectable delay between new data being released and all third party apps being updated.

I don't know if there is a standard for that anywhere, as it will change wildly depending on application. Some data will be released once, and that's it (Crime Stats for 2009) etc. is not likely to ever be updated... you would get new figures for 2010, but that's separate data. The onus would be on the developer to not simply call their app "Crime stats for last year" - as that would change expectations!

For bus data though, things are some what different in that once new data is released the old times could be potentially be completely wrong. You would want that data updating as fast as possible. It's a bit off topic, but in cases like this I'd simply suggest that a bit of communication would be required - perhaps issuing the new data before it becomes current, so that developers could switch to the new data at a designated time. If a new timetable comes into effect on Monday, why not release the new timetable to developers the Friday before. I wouldn't imagine it was a secret anyway.

Perhaps even easier, though less ideal for the third-party apps, would be for data that changes over time - simply issue it with an expiry date and request(require?) that third parties to issue a notice to users once that data has expired.

---

I don't know what popular consensus is around this topic, but I don't personally understand why there is a concern from data providers that it is their responsibility for how that data is used. Any morale/ethical or legal implications of using data in a particular way should always fall upon those using that data in such a way to raise those questions. 

As an example, what if someone created a site with the tree data called "lets kill all the trees in trafford" and then had a map marking which ones had and hadn't been vandalised etc. Maybe it would even have a scoreboard. You wouldn't go after that site because they were misusing that data, especially if other third parties were using it productively. What you would surely do is go after them for what it is they're actually doing? (am sure it would be against some laws, I'm just not sure which ones!)

I see this as no different as to how car manufacturers are not held liable for all the car accidents that occur during the course of real life. What the manufacturers are held accountable for is the quality and safety of the car, which aim to reduce the amount of accidents due to faulty manufacturing (and of course damage that any accidents may cause to humans). Open Data should have "safety measures" too - ensuring that it is released in predictable ways such as at regular intervals (when relevant) and to as high a standard as possible, pick a sensible and clear format - and communicate any changes to developers explicitly (a simple change log should do this?). Maybe it would be worth solidifying what developers should be able to expect from open data, and using that to guide those that are releasing it. Maybe even a rating system for data, gold standard meets all of them, silver meets 3 or 4 etc....

Apologies for the rant, don't know what got into me. I should probably get back to work :)

Rob

Rob Gough

http://robgough.net