DataValues library

A bit over a year ago, I wrote down a basic strategic outline for reuse and interoperability between the SMW and Wikidata projects. Though not all of this has happened yet, and though we decided to go down slightly different routes in some cases, good progress has been made towards the goals described there. A big part of this is the DataValues library, and the parsing and formatting infrastructure build on top.

Weighing the different package principles in the context of the current and expected consumers of these libraries, I ended up deciding to split the functionality somewhat differently than as described in the original document. After all, at the time of writing I had not done any research into package design, and thought bundling inheritance hierarchies into their own components was a smart thing to do. (Hah!) I read many articles on the topic, discussed some trade-offs with various knowledgeable people and even managed to get some input from his holiness Robert C. Martin. The preliminary result can be seen here.

The two most foundational packages there are DataValues, and Interfaces. They both mainly serve to define the interfaces, and are thus both abstract and stable, as packages at the bottom of the dependency graph ought to be. DataValues also comes with some trivial implementations, such as StringValue, and NumberValue, which do not undermine these characteristics.

The next two in line are Common and Validators. I’m listing them together here as I see them both as misfits and collections of technical debt that need addressing. Common essentially contains stuff that did not fit anywhere else. It also defines some base test classes for ValueParser implementations. Those test classes are abusing inheritance in a harmful way, so hopefully this will soon be gone. Validators holds the existing implementations of the ValueValidators interface. Both the interface and its implementations have serious issues, and are perhaps the most crappy code in any of the DataValue repositories. Luckily this sits into its own repo, and can easily be ignored by anyone who is not already bound to this code.

Finally we have the repos proving concrete functionality for specific use cases: Geo, Number, Iri and Time. These contain objects representing values in their respective domains, and typically some parsers and formatters as well. You can view the documentation of each for more details. I might well do a blog post on the Geo one in the near future.

All of these components have seen their initial release about one week ago. They can be installed via Composer, and are listed on Packagist.

A lot of them are currently used by the ParamProcessor library, which in turn is used by Maps and Semantic MediaWiki. This means you will be making use of these new libraries when installing Maps 3.0 or SMW 1.9, once these are released that is. Another user of the library is the new implementation of the Ask query language.

The individual components will see new releases as it makes sense for them and their users. For instance I am personally planning to make some additions to the Geo library to facilitate functionality I want to have in Maps 3.0. Another example I am working on is a new component titled Serialization, which aims to provide better serialization infrastructure than what is currently in the DataValue interface itself. The hope is that as this set of foundational libraries matures, more higher level functionality will be build on top, as part of the SMW project, and part of the Wikidata project, or by other users altogether.

To end this post, I would like to thank all the awesome people that contributed to those various components. In particular the Number and Time components have been written nearly entirely by my great Wikidata colleagues, so credit goes to them.