Hey,
(Included wikidata-tech)
Also, while you're at it, if you have a sec, you might like to look at the
> tentative idea for using a separate Wikibase store for the features we're
> working on:
> https://www.mediawiki.org/wiki/Editor_campaigns/Notes#Structured_data_store
>
The spirit is similar in many ways to what's in the EP extension, though
> we're targeting a much wider range of use cases, and the code should be
> much more modular. Also hoping to achieve a very slick UX (or UX's) with
> help from designers.
>
Will just reply to this part here.
>From what I read on this page, I'd not be thinking about using Wikibase. If
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:
> The code produced during the first few sprints will probably be pretty
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:
> Question: Do we want to use existing frameworks at all? Composer?
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 a
