Re: [Wikidata-tech] Composer, Wikibase

Hey, (Included wikidata-tech) Also, while you're at it, if you have a sec, you might like to look at the The spirit is similar in many ways to what's in the EP extension, though Will just reply to this part here. anything, Semantic MediaWiki seems like a better fit (though perhaps still not a good one - I do not suggest you try using it here). * Wikibase does not support queries and visualizations at this point - you'd just have entity storage * Our entity storage code is not reusable at this point * Our two applications, Wikibase Repo and Wikibase Client are both in bad shape design wise, making it hard to have them suit your needs (which are different than the requirements for Wikidata.org). This is something that should change regardless as it is slowing the Wikidata team down a lot, though it might well take some time before we got rid of the big issues there. I'm also not sure what you'd really gain by having our current entity storage rather than following a more conventional approach. You do not have a user defined "schema" right? I'm getting the impression that what you really want to do is store the data in tripplestore format. In case of the Wikibase applications, we'll be using Wikibase QueryEngine for this, which will maintain a second copy of the data that can be queried. Since this component is not bound to the Wikibase applications, you could potentially use it at some point (initial development has not quite finished yet). https://www.mediawiki.org/wiki/Wikibase/Components Using Wikibase QueryEngine would gain you some amount of interoperability, esp as you'd essentially be using our DataModel. I'm rather skeptical our DataModel makes much sense for your use case. You don't need Statements (that have a rank and references) and perhaps not even claims (which have qualifiers). This means you'll not have use for Item entities, which means you'd need a new type of entity. This does not mean you have to give up on interoperability altogether - you can still use lower level components. The wiki page mentions geo and time. You can indeed use our implementations for those by using the appropriate DataValues libraries (also linked from the Wikibase/Components page). There definitely is opportunity for reuse and interop here. I suggest we identify the reusable components of our system that are useful to you, as well as functionality that is not reusable yet, though would be beneficial for you if it was. Quoting from the wiki page itself: straightforward. Still, it would be nice to have an architectural plan to aim for. Here's a rough proposal: I'm happy to see you are thinking about this. The diagram and text look reasonable enough, though neither explains the boundaries (arguably the most important part of an architecture) in detail. The dependencies presumably all go inwards towards the "campaigns business logic" part. In other words, this part does not depend on any of the others. The top layer contains parts that would each have their own application and domain logic, so these should definitely not be whole blobs that depend on the "reusable UI logic" in the layer below. I cannot stress enough how important it is to get that right - it makes a huge impact on the maintenance cost of the project and how flexible and powerful it ends up being. (Just look at the EducationProgram extension or at MW core to see how it can go wrong.) Quoting from the wiki page itself: Anything from Symfony? Composer is a dependency manager (tool), not a framework. If your code is binding to it, you are very likely doing something wrong. I'm assuming you will be building this on top of MediaWiki, in which case you already have a framework. Generally it is good design practice to bind as little to a framework as possible (frameworks ought to take the same place as the database and the UI - at the edge, as an implementation detail that could theoretically be replaced). It is nicer to depend on libraries, which your application will control, rather than on a framework, which will control your application. One of the worst kind of bindings you can have to a framework is to derive from its concrete classes and put in your domain and application logic. This is what practically all MediaWiki extensions are doing with special pages, api modules, jobs, actions, etc. Those APIs are lousily designed, making binding to them even more problematic. For the Wikibase applications we made this same mistake, which was identified as such though review by external experts. In case of Symfony, which mostly adheres to sane design principles, the framework is based on libraries. Making use of those can definitely be beneficial to you. There is however no reason to limit yourself to Symfony - there are many great libraries out there that are not part of the Symfony project. Good luck with your project - I hope it turns into a gem rather than a ball of mud :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --