On Thu, Nov 01, 2018 at 11:33:48PM +0100, swedebugia wrote: > Wikidata is linked data and dry and by using it we can share between > distros and software building projects (conda, easybuild etc.). It > scales because the software maintainers themselves will be encouraged > to update project information - such as a reference to a mailing list > - which is the only way to really keep up-to-date in a scalable way. > Wikipedia will use that information too. Wikidata is DRY. > > First I did not understand DRY. Found > [1]https://en.wikipedia.org/wiki/Don't_repeat_yourself > Agreed, it would be nice if changes to Wikidata would be driven by the > authors of the programs and shared with leaf nodes (package managers, > etc.)
Yeah, sorry for the jargon. > I agree. Though it would be good to find a way to keep queries to > wikidata to a minimum. Caching maybe. It lends itself naturally to caching. We can use fetching links for the website - that would be a good start - and later see if we can enrich package descriptions in Guix itself. In both cases the user should decide whether they want to use internet access/use a cache instead. > When you have a proof-of-concept we can even > consider writing a paper about it. > > Eh, unfortunately my guile and guix fu is not really anything to brag > about, yet ;-). I am reading up on guile and trying to understand the > code in guix. > Right now my skill level is at > * finding spelling errors and unclear text in the manual > * contribute new simple packages (about to package recoll > [2]https://en.wikipedia.org/wiki/Recoll and splint) > * adding better error messages to guix > * sharing new ideas > > This wikidata endeavor would likely take some time for me to accomplish > with a good mentor. No problem! I think it is actually a very good learning project. We can help. Start small is my advice. > First up is deciding whether the core procedures interacting with > wikidata should be in guix or as a separate module. I suggest separate > module. Agree. I think it can be a tool that is separate from Guix itself. Just start with a simple query and store that either as an S-expression or as JSON. I think (eventually) we ought to do both so other languages may use output too. Have a look at the tooling that generates the website. > Then writing client procedures to interface with the SPARQL API in > wikidata. This has already been done in python 3 (beta) see > [3]https://github.com/dahlia/wikidata gplv3+ > > We could piggyback on this client (essentially making guix dependent on > python :/) or better yet contribute to one of the existing guile sql > libraries: > * [4]https://sourceforge.net/projects/guile-simplesql/files/latest/do > wnload (unmaintained since 2014 it seems) > * [5]https://github.com/opencog/guile-dbi (active fork) > > The last one looks most promising but I did not look at the code yet. Personally I would use the Python stuff first and then slowly replace that with Guile. That way you get to results fast and we can improve over time. I personally take no issue with mixing stuff. And because it is a separate tool it is your choice anyway. I think also, initially, we should build a separate website that can display all this information. That way you have full freedom on implementation and experiments. > Will you join our Guix event at FOSDEM? This would be an interesting > working group. > > Thanks for the invitation. I will think about it. > I look forward to hone my guile and guix skills :) Please come. FOSDEM is awesome. Pj.