NetworkedPlanet

Using DataDock to publish to shared data collections

Wed, 10 Jan 2018 17:00:00 +0000

Using GitHub as the backend to your data storage has a few obvious benefits straight off the bat:

All the files produced by DataDock — the original spreadsheets, the RDF triples making up the Linked Data, the dataset metadata, and the static HTML files that display your data portal — are hosted on your own GitHub account.
Each update to a dataset via DataDock produces a new “commit” in the GitHub history, producing over time a full revision history of that dataset.
It has secure authentication which can be used for logging in to your DataDock management portal, meaning you don’t have to remember yet another username and password combination!

But there’s another great feature of GitHub that we can leverage on DataDock for use in data publishing, and that’s Organizations.

Organizations are shared accounts where groups of people can collaborate across many projects at once. Owners and administrators can manage member access to the organization’s data and projects with sophisticated security and administrative features. - GitHub

Our last release of DataDock completely rebuilt the dashboard structure to be able to make use of the way in which GitHub user accounts can be added to organizations. This means that as you create organizations on GitHub, or are added to someone else’s, you will see them appear as options on your DataDock dashboard ready to publish data to.

A GitHub “organization” does not need to be a company you work for, you can set up organizations for projects, meet-up groups, or crowdsourcing pushes. As GitHub states, even on the free GitHub plan you can have “unlimited collaborators on unlimited public repositories” - fantastic!

If you don’t see your organization pop up on your dashboard, that’s most likely because you set your DataDock-GitHub access permissions before you created the organization, simply check your access settings and allow DataDock access to the new organization.

Due to the built-in data portal page building, each project / group / organization set up in this way has a data portal automatically, with catalog lists and navigation along with the deep dive into the Linked Data as is standard on all DataDock published data.

That’s all for now, but I’ll be writing a few more DataDock related blog posts over the next few months as we draw near to the end of our Preview Release. Watch this space!

Go To DataDock.io

This article is part of the Data Dock Intro series

Evaluation, Data Protection and Innovation Workshop

Tue, 27 Jun 2017 14:00:00 +0100

This workshop will help you learn about the upcoming changes to Data Protection law (General Data Protection Regulation – GDPR) in relation to evaluation data, for both existing data and future data collection. During the interactive sessions, you will master new terms and concepts covering GDPR, Linked and Open Data, and the role a Theory of Change can play in data strategy design.

This exciting afternoon promises to help you:

Navigate data collection and evaluation under the GDPR with practical advice and guidance
Meet (and begin collaborating with) other professionals dealing with data in their day-to-day work
Get to know leaders in data innovation

Led by The Social Innovation Partnership (TSIP), NetworkedPlanet, and Digital Catapult Centre, the interactive workshop will be presented in four parts:

Adrienne Monteath-van Dok from TSIP will introduce the role that a Theory of Change can play in data design. Adrienne will use Camp Ballot, a mock organisation that collects data in real time via SMS to improve the quality of services offered to refugees in refugee camps, to help you work through the data challenges you face with a safe and practical example.
Jen Williams, Software Developer and Data Consultant from NetworkedPlanet, will further build on this example, explaining the world of Open and Linked Data and guiding a discussion of how thinking across the web-of-data could support Camp Ballot’s mission.
Lea Gorgulu Webb from NetworkedPlanet (a lawyer and data strategist) will then provide an overview of the GDPR in the UK (given the current status of Brexit), again, using Camp Ballot to gain experience working with the data protection laws of the EU and UK.
Once you’ve mastered the main elements of the GDPR, Lucie Burgess, from Digital Catapult Centre will discuss innovative concepts and approaches to help you comply with data protection and privacy.

The session will end with details of where to turn for further help, followed by networking drinks.

If you are a manager, Monitoring and Evaluation (M&E) professional or responsible for data in your organisation, this session is for you if:

You need to provide guidance and informed leadership advice to an agency that works with people
You understand that there are serious and institution-threatening penalties for failing to handle data carefully
You are a professional who works with data, but data and data design is not your realm of expertise
You are considering what to provide to your teams for training over the next year
You would like to meet other professionals and managers in the public, social and tech sectors

Costs: £90 (Book by 31st July for our Early Bird price: £60)

Cancellation policy:

If cancelled by mid-August attendees will receive a full refund.
If cancelled by September 1st attendees will receive a 50% refund.
If cancelled by September 12th attendees will receive a 25% refund.
And after this date there will be no monetary refunds.
Attendees can transfer their tickets to someone else should their plans change (but please notify the organiser)

Workshop date: 20th September

Timings: 13:30 – 18:00 (networking drinks from 16:45)

Book On Eventbrite

Stakeholder Engagement in Data Sharing

Thu, 20 Apr 2017 17:00:00 +0100

I’ve been working on a project called The Way Ahead: The Future of Support for London’s Civil Society for the last few months¹. It offered a chance to work on designing a great data sharing strategy (foundation).

The project started by meeting people from “civil society” organisations in London. Many of these organisations are very small or operate in only a single community. It was really nice to meet them and work with them, but raised this odd conundrum of how I introduce myself. I find it difficult to briefly reveal the full range of my consultancies. When I introduce myself as a Data Strategist, I think some people take an impression that I am unlike other social researchers - maybe people assume that I am purely interested in numbers and tech. If I introduce myself as an impact evaluator, they don’t understand why I focus on data and getting the use of tech right. The truth is, I am a mathsy, techy, social scientist. Data strategy, for me, begins with the messiness of humanity. I relish the imperfect and human side of social science, and in social science practice, I press to work as much as possible with stakeholders, because it helps figure out how to best understand and organise data issues. It isn’t something that a lot of organisations expect of a data strategist, but data strategy is like any other evidence-based practice - it is best when stakeholders are involved.

Let’s explore the way stakeholder engagement can make data richer. I will use myself as an easy and available example. I was a stakeholder engaged in the process of developing The Way Ahead. Like experimenting with inoculation², though, I’ll be careful.

The first question for me as a researcher and data strategist is who are the stakeholders… today? Why “today”? Because when pulling together a data strategy for ongoing, multi-issue, research data, the answer changes constantly. One day, we consider the end beneficiary, and another day we are consider data users. At another moment, we might consider data providers.

All of the categories of stakeholders are full of diversity. The end beneficiary can be anyone who has any contact with the issues affected by civil society. That really includes everyone I can think of – a real cradle-to-grave range… with billions of different experiences. It includes settled residents, commuters (like me), visitors, and internationals who may never be physically in London, men, women, every sexual orientation, every look, every language, every ability, every happiness, and every sadness. It even includes pets, wildlife, and the environment. I can go on for ages, here. I am just one of a near infinite number of stakeholders. Today, I am commuter, adult, woman, parent, educated, fortunate, English-speaking, literate, and working remotely via the internet. I can’t afford to live in London. I’m not a British citizen. I can see and hear and walk. I have seasonal allergies. Any of these traits might make me a stakeholder in a research project in London. Likewise, they might exclude me as a stakeholder.

Now, get this: If we just consider me as a commuter, and do a few seconds internet search for, “data about London commuters,” we get a report from two years ago. It is from the Greater London Authority. It summarizes some statistics calculated from the 2011 census data³. This is what it says about commuters, in brief:

Sentences in the 2011 Census Data about Commuters	How typical am I of these stakeholders? Why does it matter?
18 per cent of people who worked in London commute from outside the capital.	I am not alone. I am part of a minority. It is a significant part of the workforce, though.
Those who commuted-in were more likely to be male, in managerial/professional occupations, and more likely to work in Finance/Insurance or Public Administration than their London-resident counterparts.	Oh, well, I am not totally typical. This is good to know. Sometimes, my view or need, as a stakeholder, will reflect a different gender-experience, a different income stream, etc., than most of the rest of the group.
On average, commuters are older than those who lived and worked in London.	(First thought: Aargh. Don’t remind me.) More reasoned thought: Interesting, I am sure we have some age-related issues to consider sometimes. (Like how much more awesome we are as we age!)
Individuals living outside London were more likely to commute to the capital for work if they reported non-White British ethnicity. Those with Black ethnicity were five times more likely than their White British counterparts to commute to London.	I am not British - related to this lack of native-experience is that the term “Black Ethnicity” doesn’t really make any sense to me. I might miss lots of local meanings to common English words. I might not always understand or communicate as clearly as a native Britain.
In the week before census those working in London travelled a total of 39.7 million miles
from their residences to their work. Assuming that this distance was travelled twice a day, in a five day week London workers commuted the equivalent of travelling from Earth to the Sun and back.	This could spark loads of snarky remarks from me, but seriously, it underscores that considering commuters is reasonable, as this is a big number of miles travelled.

As you can see in my chart above, I want to know about stakeholders, but I must be careful not to assume they are representative of the wider audience/target/group. Collecting information from stakeholders does not necessarily mean that it is true, but more that there are times when it seems true to the stakeholder (I would not describe myself as older, for example). Stakeholders are always individuals. Few individuals are perfect samples of any group, unless it is a group of one. One of the reasons we get to know stakeholders, though, is to decide what issues to look into further. The data is best, when it has actual individuals, participating as stakeholders, and good quantitative data, letting us check the weight we give to the guidance of the stakeholder. When I find that there is a barrier to certain stakeholders showing up in the data, then I have to really dig in and figure out how to remedy the exclusion, and be open to the fact that the quantitative data is faulty in some ways. Improving granularity, or what we can see in the detail of data, sometimes means we are simply describing a section of the data that is missing. Understanding and communicating the complexity of the data adds real value to the analysis and findings of any report.

We have countless examples of how more granular data allows us to find insights that really change peoples lives for the better, and I soon become really excited, when I consider the possibilities of who the stakeholder is! Let’s consider the wide breadth of London data stakeholders again. Who might my work affect? Maybe we will design a strategy that ends up helping a young person escape violence and grow up feeling safe in London! Or maybe we’ll help create the solution for a working parent who needs to take a sick child to the doctor during a break from work! Maybe we’ll manage to create the right data strategy for cyclists to ride through London without risk of being in a fatal accident! This is why I love my job! There are endless ways that my little part of strategising can help create awesomeness in a place.

There are other stakeholders, who are not end-beneficiaries. When we move up the chain (away from the beneficiary and toward the digital information), we encounter the social workers, the housing providers, the stalkers (who might want data for destructive reasons), the police, the policy analysts, the politicians, the app developers, the data visualisation professionals, and on and on. Each problem brings a different collection of data users and providers. Sometimes that means we will want the data to be held in a different way and shared in a different way.

Stakeholders are everywhere. It can seem overwhelming. We’re able to decide who are the stakeholders of the moment and narrow our list by focusing our work on one problem/issue at a time. Like: how do we solve the problem of inequality between men and women (or White British and Black Ethnicity) in managerial and professional roles, in London’s financial sector? Who are the stakeholders? How can they help design our research? What barriers to their involvement do we know of? Where should meetings and working groups convene? Etc.

In The Way Ahead report, we recommended a plan that allows for constant stakeholder engagement, problem focus, and flexibility. It will seem very un-techy to many readers, because the tech comes secondarily to getting the data strategy right, and a good data strategy begins with stakeholder engagement!

When the report is published, you can see it at: http://www.lvsc.org.uk/programmes/the-way-ahead.aspx.

Footnotes

I cannot give the impression that I did anything alone in this project. I had a great time working closely with Kate White (of Superhighways) and dozens of collaborators.
Sort of like Lady Mary Wortley Montagu.
I am not going to discuss the age of the data. There are other places to get information that allows for improvement of the data. That is a discussion for another day.

The Way Ahead - Data Sharing

Wed, 12 Apr 2017 11:00:00 +0100

In April 2016, The Review of the Future of Civil Society Support in London was published by London Funders, working closely with Greater London Volunteering and the London Voluntary Service Council. The Review’s emerging findings report The Change Ahead described the rapidly and dramatically changing world in which civil society operates. The Review Team believed that organisations and individuals that support civil society need to adapt, evolve and innovate at a systems-wide level to address these changes, so that the best outcomes can be achieved for Londoners.

The report made twelve recommendations for action, gathered under five key themes, each addressed by a Task and Finish group. In November, Lea began working with Kate White (of Superhighways), co-chairing the Task and Finish group for the “Data Sharing” theme.

The Way Ahead proposes a system that puts London’s communities at the heart of the way we all work. It begins with co-producing an understanding of need and how to tackle it with our communities, through to better sharing of intelligence and data across all sectors, and making sure that civil society’s voice is heard in decision-making at a strategic level.

The GLA (Greater London Authority) currently plays an important role for other sectors in collating data, analysing it and making it accessible. Civil society is a large and important contributor to London, and as such the GLA should extend its data role to encompass civil society. As co-produced needs data is developed, it could be pulled together by the GLA. Over time, this data would provide a clearer and shared understanding of need as it evolves across London, which is accepted by funders, civil society and communities themselves, and could be incorporated into strategic planning at all levels. Data about the sector itself is also important for planning, for example on the size, location and nature of civil society in different areas of London as it correlates to communities needs; the nature of volunteers, including where they volunteer, and to what issues they contribute. - The Way Ahead - Thematic Groups

Since the Data Sharing Task and Finish group was set up, Lea and Kate have been meeting with funders, voluntary sector leaders, and charities in order to produce a report of recommendations to The Way Ahead’s steering group. The report has now been submitted, but the work doesn’t end here! To stay up to date with news, visit the newly launched thewayahead.london website. We’ll also continue to post updates here on the blog about the intelligence gathered during our meetings throughout The Way Ahead’s Data Sharing research. Stay tuned!

DataDock and CSVW

Wed, 01 Mar 2017 10:00:00 +0000

When we publish anything on the web it should go without saying that in order for that distributed information to be usable, we must adhere to standards when we publish it. If everyone had their own way of marking some text in a web page to be bold, web page browsers would have an impossible task of displaying that text in the way it was meant to be shown. That’s why we have the standard markup language of HTML to enable everyone to publish web pages.

Similarly, when we publish data on the web we should look to standards to ensure consistency and interoperability between distributed data publishers and any applications that need to pull that data into their systems. DataDock currently makes use of two main recommended approaches to publishing data on the web - “CSV on the Web” (CSVW) and Linked Data. This blog post will concentrate on CSVW and there will be a follow up for those interested in Linked Data.

The first stage in DataDock’s processing pipeline is to take a CSV file of tabular data, and open it to allow the DataDock user some basic control over how that data should be processed. Whilst the current amount of user control over the CSV processing is straightforward datatype selection of the different columns, we will be rapidly expanding DataDock’s abilities to allow more user control over defining the structure of the CSV they are publishing.

The W3C’s CSV on the Web Working Group developed specifications relating to describing tabular data. This makes it the obvious choice for us to adopt this standard when we pull the CSV into the DataDock processing pipeline. There is now a W3C CSV on the Web Community Group that is open to all, where there is a focus on discussion and support for implementors, publishers and spec developers to share experience with CSVW and related ideas.

Using the CSVW specification, DataDock takes the information entered by the user (e.g. title / description / selected license) and combines it with the list of columns to produce a metadata JSON file. An example of one of the metadata JSON files produced during the import of a CSV into DataDock is shown below (the example below only shows the first four of the columns for brevity):

In its current release, DataDock auto-creates the column definitions, creating the machine-friendly name, and property_url from each column’s header value, which is set as the initial value in titles. DataDock currently asks for user input only when it comes to the column’s datatype, although it does make a simple guess at the datatype based on the values of the first non-header row of the selected CSV. Future upgrades to the DataDock platform will make use of the more extended definitions of the CSVW standard.

After the CSVW metadata file has been created, DataDock’s conversion process uses the metadata file to generate RDF linked data. The DataDock then uses the linked data to generate the pages for the data portal, and publishes all this to the user’s target GitHub repository.

Each DataDock repository has a “csv” directory that contains a sub-directory for each dataset. This contains the original CSV upload along with its CSVW metadata JSON file. You can find the CSV and CSVW metadata relating to the examples from the previous blog post on my GitHub repo here.

For those who want to learn a bit more about CSVW, a more in-depth blog post is available by Gregg Kellogg, or if you’re a documentation geek then feel free to dive into the recommendations and notes published by the CSVW working group.

It’s possible that future versions of the DataDock will include an API layer, and that this may handle more complex CSV processing using supplied metadata files. If that’s something that you would be interested in, make it known as a feature request on our support site.

The next blog post will dive into the linked data part of the publishing pipeline. It’s that side of things that the most exciting for me personally, because as we add enhancements to the CSVW property_url definition user control, we can add features to publish and reuse standard vocabulary terms to define the data published from disparate sources - whilst keeping this standard of data publishing free and as easy as possible for non-technical people to use.

This article is part of the Data Dock Intro series

Connecting the dots in your data

Wed, 01 Mar 2017 10:00:00 +0000

Before I get stuck into the more technical aspects of DataDock, I’d like to first show a little example of one of the benefits of having a deep-dive data portal, over that of a catalog of datasets. If you’ve not yet read it, have a look at our Introduction to DataDock.

Many data publishing platforms provide a list of the datasets you’ve published. Good ones will include additional information about that dataset (this is known as the metadata). Simplistic catalog offerings, however, can;t display the information from multiple datasets without additional visualisation modules that need to be manually configured to display information from disparate datasets.

By choosing identifiers when you upload data to DataDock, you can upload additional information that pertains to those records later on, and your data portal will automatically group that information together for display in the data portal.

This is best explained in a walk-through of connecting up three datasets I added to my own data portal.

Selecting the data

First I went on the hunt for some open data that would be useful to show this functionality. I found an interesting dataset detailing archaeological / historic structures on the Bristol City Council’s beta open data platform. It’s published under a public domain (CC-0) license meaning I have the right to reproduce it elsewhere. The dataset was available in CSV (comma separated value) format and most importantly it also included a Monument Record Number that I quickly checked that there were no duplicates or missing values - perfect for use as the DataDock identifier for each record.

Uploading to DataDock

By default, DataDock produces identifiers for each of the records in your spreadsheet using the row number, but to be able to add extra information in the future, we want an identifier that will work across datasets. As mentioned above, I’d seen that the MONUMENT_RECORD_NO suited an identifier and so I selected this from the drop-down list.

Viewing the data

Once the import job was completed, I can use the buttons on my dashboard to view my data portal, and dive into the data using the exampleResource links. See how the fact I selected the Monument Record Number has affected the addresses of the records in the data:

http://datadock.io/jennet/odcamp-demo/id/resource/monument_record_no/1054M

Navigating to this record in a web browser shows us all the information pertaining to that record. This is known as the “resource page” for a particular record in your dataset.

Merging data from a different dataset

I had a second spreadsheet that contained the specific latitude and longitude of each monument, along with the monument record number of course. I wanted to add this data as the original data only listed the location as a combined field of (lat, long). During the upload of the second spreadsheet I again selected the MONUMENT_RECORD_NO as my DataDock identifier. Once the import job had completed I can refresh the resource page and see that my additional data from the separate dataset is shown on the same page.

Connecting the dots - linking in

We can also use those same identifiers to link into the resources that we’ve published through other datasets. To demonstrate this I wrote a dummy survey report noting “damage” to the monuments. In the survey data we use the addresses of the monument resources instead of their number or name.

This time I choose the damage report ID as my identifier, and upload the dataset for conversion and publishing.

Data catalog

Throughout this process this has also meant that each dataset has been added to the dataset catalog on my data portal landing page. The data catalog lists each of my datasets along with any other information I added during upload, such as the license, a title, description, and keyword tags. It also shows the data download links for the complete dataset.

But more interesting is how the data from these separate datasets can appear in a single web resource through the use of identifiers and we can see how even data that points to the resource can be shown on that resource page too.

I hope you’ve found this simple walkthrough helpful in demonstrating the benefits of being able to connect your data. We’re able to explore data in a way that goes beyond the boundaries of each separate dataset or spreadsheet is their source. Identifiers are the key concept in this way of thinking about connecting data. If you’re interested in having a play around, head on over to DataDock.io and check it out.

This article is part of the Data Dock Intro series

Introducing DataDock

Tue, 28 Feb 2017 10:00:00 +0000

So you want to publish some data, what do you do next? As we’ve mentioned before, publishing data shouldn’t cost the earth, but that there are some technical challenges to be faced when we want that data to be discoverable, accessible and usable.

Of course, technical challenges mean resource challenges; even when data publishing software is free or open-source, it can mean that you require someone with the technical know-how to set it all up (and keep it running), and the resources to run the server to hold the software. In so many cases, these technical and resource challenges basically block individuals and smaller organisations from being able to publish data effectively or at all.

We believe that taking your first steps in publishing your data shouldn’t be this hard. We have the technical skills and expertise in data publishing standards to be able to provide that publishing service in a way that eliminates those barriers. Over the last few months we’ve been building the answer to those challenges, and we’ve called it DataDock. We’ve now released it as a preview edition, which means that it’s ready to be used by the open data community, and that we’ll be collecting feedback while we work on some additional features over the coming months.

Have a deep-dive data portal in a matter of minutes

Choose your spreadsheet, select a license, then let DataDock do all the magic.

That magic provides you with a data portal home page, which lists a dataset for each of your spreadsheets. The data portal shows useful information about each dataset and clear licensing information, along with links to download the original spreadsheet and the data in other formats. You can also click into the dataset itself, as DataDock creates pages for every record in your data, allowing you to deep-dive into your published data.

Don’t worry about the techno-babble

One of our main aims is to try and eliminate as much as possible all the jargon and techno-babble surrounding data publishing. DataDock handles the magic, freeing you up to concentrate on the data itself

Keep hold of your data

All the standards-compliant data produced by DataDock is published to your GitHub account. You can turn off DataDock’s access any time you wish, and keep all the data it produced.

Cloud-based

No need to buy web-hosting, DataDock sits in the cloud and we will always provide free accounts.

Get involved

We’ve got hundreds of ideas for enhancements and features for DataDock, and we’d like to work on the things you want most. Get involved on by requesting features or up-voting existing requests on our DataDock support site.

It’s for the geeks too

But we don’t want to bore you with that right now. Standards geeks and linked data nerds will be interested in reading the follow ups to this blog post to learn more about the CSVW and 5-star linked data standards that are at the core of DataDock’s internal systems.

If you’re interested in having a play around, head on over to DataDock.io and check it out. We’d love to hear from you about what you’d like it to do in the future. Upgrades to DataDock won’t effect the data you’ve published, they’ll simply add features to your future uploads, so feel free to get stuck in even at this preview stage.

This article is part of the Data Dock Intro series

Co-operative Thinking

Wed, 22 Feb 2017 12:17:38 +0000

First, a confession: I went along to Open:2017 without a very clear idea about what a platform co-operative really was. I had been asked to get involved due to my work relating to Linked Data, and whilst I had read up a little bit on platform co-ops I only really had a vague idea that it was “sort of like doing something like AirBnB or Uber but without exploiting those using the platform”.

I came away not only with a clearer idea of what a platform co-op is (I’ll get into that in a minute), but also with a real hunger for finding a way of adopting this approach in future projects. So what is this approach? Most people are aware of co-operatives - where groups of people have come together to form an entity to manage something like a building or buildings to live in (housing co-ops), a business (worker co-ops) or a food shop or cafe (consumer co-ops), amongst other things. What they all have in common is the drive to create entities where the people who take part in that co-op can become members who actively participate (if they wish) in the running of the co-op itself. Any profits are then shared amongst the members and/or ploughed back into the co-op itself.

With platform co-operatives, instead of members coming together around a physical building or a business that’s usually fairly localised, the “hub” is a digital platform. For example, Stocksy is a stock photography platform that’s owned and run by all of their photographers. I must admit I still get a bit confused as to why they went with “platform co-operative” rather than “digital co-operative”, but then again I also complain that calling things “digital” isn’t specific enough, so I admit I’m difficult to please!

Rather than me continue to badly explain co-operatives and platform co-ops, here’s a few links to read up some more if you’re interested.

Back to the conference, the first session I took part in was a panel with Tim Davies (Open Data Services Co-op) and Karin Christiansen (Open Knowledge Foundation) called “From data slaves to data citizens”. The session was intended to be a discussion around open data, but ended up being primarily about user’s fear of the intentions and uses of data collected by platforms that had become so monolithic that it was difficult to have a digital presence without signing up to their services. The second session I was helping to present focused on content from Matt Wallis from the Institute of Solidarity Economics who have adopted a Linked Data focused approach to their data infrastructure. I was really pleased to see that a large proportion of the attendees were comfortable with Linked Data already. My gut feeling is that in this environment filled with people working with such commitment to collaboration and information sharing, Linked Data is obviously not new to them, as it provides the standard for collaborating effectively at a data management and sharing level.

The final session I was directly involved with was “Designing interoperable apps for the open app ecosystem”, a lengthy 2 hour workshop session led by Laura Hilliger, Enric Senebre Hidalgo and Ricard Espelt. They did a great job facilitating the structure, creating smaller discussion groups over particular topics brainstormed at the start of the session. The discussion continues over at discuss.open.coop.

A pitch idea bubbling for @ODcamp after #opencoop - "how can platform co-ops benefit the open data ecosystem?" #crosspollination
— Networked Planet (@nwplanet) February 18, 2017

So what next? Well, my mind is buzzing about all sort of things. From the interoperable apps session, I’d love to hear about people pushing forward with publishing open data vocabularies for use in linked data publishing. Oli from Open Co-op is hoping to rekindle the Collaborative Technology Alliance’s efforts (more info here), and I’m interested to see if linked data plays a part in that.

Specifically about platform co-ops, I’m wondering if our new cloud service that goes live in alpha/preview mode this weekend would be suitable for a platform co-operative, and what the logistics of that would be. The value systems certainly align, but would the administrative needs fit? I don’t know yet but I’m going to continue to delve deeper to answer my questions around that. In a very timely blog post from the ODI, Tom Sasse asks the question “How can open data portals become sustainable?” - perhaps platform co-operatives hold the answer. I’m hoping others may want to discuss this sort of thing with me at ODCamp this weekend, so expect a pitch from me around this subject.

As you can tell, I’ve come away from Open:2017 with a lot of questions buzzing around my head, but also a real sense of purpose and positivity. I’d really like to spread the word about the people who attended and their projects and platforms, however I don’t currently have a full list, as a starting point here’s the twitter list of contributors to the conference (those involved in panels and presenting sessions). If you were at the conference please feel free to add details and pointers to your work in the comments below.

I hope there’s an Open:2018, it was a fantastic event. Keep an eye on what Open Co-op do next!

Open 2017 Platform Co-operatives

Wed, 15 Feb 2017 10:17:38 +0000

By providing a viable alternative to the standard internet business model based on monopoly and extraction, platform cooperatives provide a template for a new type of organisation – forming the building blocks for a new economy.

I’m very much looking forward to Open:2017 which is being held tomorrow and Friday at Goldsmiths in South London. The subjects of the various sessions looks so interesting I think I’ll find it difficult to choose what to attend!

I’m on a few of the panels, so at least I know a few of the subjects that I’ll get to participate in discussions about. I was very happy to hear from the organisers that they are fighting hard to avoid “Death By Powerpoint”, so expect panels and discussions and audience discussion instead of a single person droning on at you for an hour.

My sessions are:

From data slaves to data citizens

Thursday 4:15pm

Linked open data for the solidarity economy

Friday 11:20am

Working session: Designing interoperable apps for the open app ecosystem

Friday 2pm

If you want to know more, this blogpost introducing the concept of platform cooperatives is a great starting point, and you can see the full programme here.

Open Data Camp 4

Mon, 30 Jan 2017 13:17:38 +0000

Only a few weeks to go! Open Data Camp numero 4 is being held at the Pierhead in Cardiff on the Saturday and Sunday, 25-26th of February. ODCamp instantly became my favourite data focused event after I attended the second ODCamp in Manchester and then helped bring it to Bristol for ODCamp3. You can read my other blog posts if you want to dive deep into my ODCamp journey.

Since volunteering with the ODCamp organising committee for the Bristol event, I was invited to remain on the organising team to help make future ODCamps happen. I was more than happy to accept and am really delighted to be part of a team made up of such friendly, proactive humans. NetworkedPlanet were proud to be one of the key sponsors of ODCamp3 in Bristol, and remain committed to sponsoring ODCamp4 and future events as we are so impressed with the team’s ability to foster an environment that nurtures forward-thinking ideas and debate surrounding production and consumption of open data in the UK.

Enough of my gushing about the people who run and attend ODCamps - if you’ve not been to one then here’s a quick run down…

ODCamp is a free un-conference. Unconferences are a particular format of event that doesn’t pre-plan a programme of sessions. Instead, session ideas are “pitched” by the attendees at the start of the day and then, using a show of hands to judge size of space required, pens, and sticky notes, the volunteer crew (called “camp-makers” at ODCamp) create the programme for the day. ODCamp covers costs by offering various sponsorship levels, the list of sponsors helping make ODCamp4 happen is available here.

At my first ODCamp I didn’t plan on pitching a session, but over the course of the first day and chats in the evening afterwards, I realised that a small session on converting CSV data formats to RDF linked data formats might be useful to a few people. I pitched it on the Sunday morning, and that afternoon ran a small workshop messing about with Open Refine to show people how you get from CSV to RDF as basically a “demystifying RDF” workshop.

The structure of ODCamp massively appeals to me because the content is so obviously influenced by the attendees. The organising team have a really good balance of hands-on when it comes to keeping the event flowing and dealing with all the logistics, whilst staying more hands-off to allow the content and discussions to grow organically. Sessions might be round-circle discussions, presentations about tools or projects, building and making of new projects, all kinds of things! You don’t have to pitch a session based on your own subject-knowledge, sessions can be pitched around a question or topic that you want to know more about, and the “pitch” becomes a shout out for other attendees with more knowledge in that area to share in a session.

The hardest thing is to choose which sessions to go to, you will undoubtedly have 2 or more sessions that you want to attend at the same time. Luckily ODCamp encourages people to move between sessions instead of feeling they must remain for the entirety of one, and this way you can dip in to more than one interesting session (a top tip is to follow the live-tweeting from attendees in other sessions). Some sessions also get covered by the amazing talents at Drawnalism, who live-draw infographics of key points from session content, which are then tacked up around the main room for all to benefit from.

ODCamp releases the free tickets in batches, and each batch “sells out” in a matter of minutes. Those who are unable to attend are strongly encouraged to update their registration so that others can make it in their place. ODCamp4 is already at full capacity but there may well be extra releases if there have been any cancellations, so set your twitter feed to give you notifications from @ODCamp if you’ve not already secured a ticket.

If you’ve already got a ticket then I’ll see you there, if you miss out this time, ODCamp5 will be along before you know it.

All photos used in this post are by Nigel Bishop, licensed CC BY-NC 2.0

NetworkedPlanet

Using DataDock to publish to shared data collections

Evaluation, Data Protection and Innovation Workshop

Stakeholder Engagement in Data Sharing

Footnotes

The Way Ahead - Data Sharing

The Data Sharing Theme

DataDock and CSVW

Connecting the dots in your data

Selecting the data

Uploading to DataDock

Viewing the data

Merging data from a different dataset

Connecting the dots - linking in

Data catalog

Introducing DataDock

Have a deep-dive data portal in a matter of minutes

Don’t worry about the techno-babble

Keep hold of your data

Cloud-based

Get involved

It’s for the geeks too

Co-operative Thinking

Open 2017 Platform Co-operatives

From data slaves to data citizens

Linked open data for the solidarity economy

Working session: Designing interoperable apps for the open app ecosystem

Open Data Camp 4