What bugs me about it is that Wikidata has gone down the same road as Freebase and Neo4J in the sense of developing something ad-hoc that is not well understood.
I understand the motivations that lead there, because there are requirements to meet that standards don't necessarily satisfy, plus Wikidata really is doing ambitious things in the sense of capturing provenance information. Perhaps it has come a little too late to help with Wikidata but it seems to me that RDF* and SPARQL* have a lot to offer for "data wikis" in that you can view data as plain ordinary RDF and query with SPARQL but you can also attach provenance and other metadata in a sane way with sweet syntax for writing it in Turtle or querying it in other ways. Another way of thinking about it is that RDF* is formalizing the property graph model which has always been ad hoc in products like Neo4J. I can say that knowing what the algebra is you are implementing helps a lot in getting the tools to work right. So you not only have SPARQL queries as a possibility but also languages like Gremlin and Cypher and this is all pretty exciting. It is also exciting that vendors are getting on board with this and we are going to seeing some stuff that is crazy scalable (way past 10^12 facts on commodity hardware) very soon. On Tue, Feb 17, 2015 at 12:20 PM, Jeroen De Dauw <jeroended...@gmail.com> wrote: > Hey, > > As Lydia mentioned, we obviously do not actively discourage outside > contributions, and will gladly listen to suggestions on how we can do > better. That being said, we are actively taking steps to make it easier for > developers not already part of the community to start contributing. > > For instance, we created a website about our software itself [0], which > lists the MediaWiki extensions and the different libraries [1] we created. > For most of our libraries, you can just clone the code and run composer > install. And then you're all set. You can make changes, run the tests and > submit them back. Different workflow than what you as MediaWiki developer > are used to perhaps, though quite a bit simpler. Furthermore, we've been > quite progressive in adopting practices and tools from the wider PHP > community. > > I definitely do not disagree with you that some things could, and should, > be improved. Like you I'd like to see the Wikibase git repository and > naming of the extensions be aligned more, since it indeed is confusing. > Increased API stability, especially the JavaScript one, is something else > on my wish-list, amongst a lot of other things. There are always reasons of > why things are the way they are now and why they did not improve yet. So I > suggest to look at specific pain points and see how things can be improved > there. This will get us much further than looking at the general state, > concluding people do not want third party contributions, and then > protesting against that. > > [0] http://wikiba.se/ > [1] http://wikiba.se/components/ > > Cheers > > -- > Jeroen De Dauw - http://www.bn2vs.com > Software craftsmanship advocate > Evil software architect at Wikimedia Germany > ~=[,,_,,]:3 > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l > > -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254 paul.houle on Skype ontolo...@gmail.com http://legalentityidentifier.info/lei/lookup
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
