Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to package-recipes

[Pjotr Prins]

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.