Hi Daniel, I feel that this tries to evade the real issue by making formal rules about what kind of "breaking" you have to care about. It would be better to define "breaking change" based on its consequences: if important services will stop working, then you should make sure you announce it in time so this will not happen. This requires you to talk to people on this list. I think the whole proposal below is mainly trying to give you some justification to avoid communication with your stakeholders. This is not the way to go. This said, it is always nice to have some guidelines as to what is likely to change and what isn't. It is probably enough to give some warnings about this ("there might be additional keys in this map in the future" or "there might be additional datatype URIs in the future"). However, this is no recipe to avoid breaking changes. In particular, the guideline to ignore snaks of properties that have no understandable declaration is just codifying a controlled way of failing, not avoiding failure: * Browsing interfaces (e.g., Reasonator, Miga Class & Property Browser) are expected to show all data to users. If they don't, this is breaking them. * Query services are expected to use all data. If you do an aggregate query to count all properties on Wikidata, then the number returned will not be incomplete but simply wrong if the service ignores half of the data. * Editing tools (including bot frameworks) are most heavily affected, since they might create duplicates of statements if they fail to see some of the data following your guideline. This does not mean that your guideline is unreasonable -- in fact, I think this is what most tools are doing anyway. But as the examples show, it's not enough to prevent major service disruptions that would affect many people. The guideline that tools should sometimes raise an alert or issue a warning does work in many cases, since we have a complex ecosystem with many inter-dependent services (for example, how should a SPARQL Web service communicate problems that occurred when importing the data? All of them or somehow only the ones that might have affected they query result?). Our tools rely on being able to use all data, and the easiest way to ensure that they will work is to announce technical changes to the JSON format well in advance using this list. For changes that affect a particular subset of widely used tools, it would also be possible to seek the feedback from the main contributors of these tools at design/development time. I am sure everybody here is trying their best to keep up with whatever changes you implement, but it is not always possible for all of us to sacrifice part of our weekend on short notice for making a new release before next Wednesday. Cheers, Markus On 05.02.2016 13:10, Daniel Kinzler wrote:

Sounds a lot like a restatement of Postel's Law https://en.wikipedia.org/wiki/Robustness_principle Tom On Fri, Feb 5, 2016 at 7:10 AM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de> wrote: