Daniel, I agree about the data/api versioning. I was mostly talking about features and capabilities. For example, we could spend the next year developing a visual table editor, implement support for unlimited table sizes, provide import/export from other table formats, introduce elaborate schema validation, and many other cool features. And after that year realize that users don't need this whole thing at all, or need something similar but very different. Or we could release one small, well defined, stable subset of that functionality, get feedback, and move forward. Do you have any thoughts about the proposed data structure? On Mon, Jun 6, 2016 at 4:09 PM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de> wrote:

Am 06.06.2016 um 15:40 schrieb Yuri Astrakhan: The structure looks sane and future-proof to me, but since it's all-in-one-blob, it'll be hard to scale it to more than a few ten thousand lines or so. I like this model, but if you want to go beyond that (DO we want to go beyond that?!) you will need a different approach, which may be incompatible. One thing that should be specified very rigorously from the start are the supported data types, along with their exact syntax and semantics. Your example has string, number, boolean, and localized. So: * what's the length limit for string? * what's the range and precision of number? Is it the same as for JSON? * does boolean only accept JSON primitives, or also strings? * what language codes are valid for localized? Is language fallback applied for display? Not answering these questions now may lead to having data that can later no longer be properly interpreted. If you get into quantities with precision or date, this becomes a lot more fun. In that case, you would want to re-use the DataValues module(s) that Wikidata uses. You write in your proposal "Hard to define types like Wikidata ID, datetime, and URL could be stored as a string until we can reuse Wikidata's type system". Well, what's keeping you from using it now? DataValue and friends are standalone composer modules, you can find them on github. -- daniel

Rob, thanks for your offer to help! Always welcome :) By discussion and positive feedback I meant Facebook and Commons comments, and a very old and elaborate phab ticket discussion: * https://phabricator.wikimedia.org/T120452 * https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Tabular_d… * https://www.facebook.com/groups/wikipediaweekly/permalink/997545366959961/ I do not think this feature will immediately have a huge uptake. It will simplify graph design, as it will be possible to store data outside of the graph. It will also allow data from tables and lists to be moved into separate wiki pages. The work of moving existing data into these pages might not be very fast. In short, it will only be accessible from Lua and graphs, will be less than 2MB each, and will require some technical skills to edit JSON until better tools are created. On Mon, Jun 6, 2016 at 9:14 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: