Paul talking about Open and Closed – not licensing or access, but about ‘open world assumption’ vs ‘closed world assumption’
Paul describes characteristics of ‘open world':
- Incomplete information
- Schema-less data
- Web technologies – http; html5; rdf
- Platform independence; scales well; cross-context discovery potential
Closed world characteristics:
- Complete information
- Schema-based data; Records
- Web tech – http delivering to native apps
- Performance; contextualised discovery; quality; curation
Need to decide when to apply each of these approaches – strengths and weaknesses
Web still best available foundation of what we are doing, but still need to manage resources; quality etc.
Quote from Leslie Lamport “a distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable”
As a developer why should I trust your API – that it will work, that it will continue to work – if you don’t use it yourself as the service owner? See Paul’s blog post on this.
APIs are not best thought of a machine-to-machine interfaces. APIs are interfaces for developers! Talk to developers who are likely to use your API. Developer is to API as ‘user’ is to UI.
Yesterday Paul hosted a meeting for developers to get their point of view [which I was fortunate enough to attend]. Some things that came out of this:
- please don’t build elaborate APIs which do not allow us to see all of the data or its extent
- Offering an API which delivers incomplete data is usually self-defeating – that is, don’t hold data back because you are worried about its quality
Introducing this afternoon’s sessions:
Emerging technologies – Graph based data (see work by Facebook, Google, BBC etc.)
Reasons for aggregation – to avoid systems/network latency; showcase; ‘web scale’ concentration; …
Data quality issues – concern about data quality can prevent release of data (which consumers don’t like); but poor data quality erodes trust and can affect reputation; reconciling these things is a major challenge