unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: swedebugia <swedebugia@riseup.net>
To: Catonano <catonano@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Re-approaching package tagging
Date: Wed, 19 Dec 2018 07:51:08 +0100	[thread overview]
Message-ID: <261b0ff4-53f8-6c54-1d3e-4e0ed8128d91@riseup.net> (raw)
In-Reply-To: <CAJ98PDyLzK4g+V+o0dxWJsH66MyuCxf=aqEOYdfnGf8YUSLRcw@mail.gmail.com>

On 2018-12-18 08:48, Catonano wrote:
> 
> 
> Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia 
> <swedebugia@riseup.net <mailto:swedebugia@riseup.net>> ha scritto:
> 
>     Hi :)
> 
>     On 2018-12-17 20:01, Christopher Lemmer Webber wrote:
>      > Hello,
>      >
>      > In the past when we've discussed package tagging, I think Ludo'
>     has been
>      > against it, primarily because it's a giant source of bikeshedding.  I
>      > agree that it's a huge space for bikeshedding... no space
>     provides more
>      > bikeshedding than naming things, and tagging things is a many to many
>      > naming system.
>      >
>      > However, I will say that finding packages based on topical
>     interest is
>      > pretty hard right now.  If I want to find all the available
>     roguelikes:
>      >
>      > cwebber@jasmine:~$ guix package -A rogue
>      > hyperrogue    10.5    out     gnu/packages/games.scm:3652:2
>      > roguebox-adventures   2.2.1   out     gnu/packages/games.scm:1047:2
>      >
>      > Hm, that's strange, there's definitely more roguelikes that
>     should show
>      > up than that!  A more specific search is even worse:
>      >
>      > cwebber@jasmine:~$ guix package -A roguelike
>      > cwebber@jasmine:~$
>      >
>      > What I should have gotten back:
>      >   - angband
>      >   - cataclysm-dda
>      >   - crawl
>      >   - crawl-tiles
>      >   - hyperrogue
>      >   - nethack
>      >   - roguebox-adventures
>      >   - tome4
>      >
>      > So I only got 1/4 of the entries I was interested in in my first
>     query.
>      > Too bad!
>      >
>      > I get that we're opening up space for bikeshedding and *that's true*.
>      > But it seems like not doing so makes things hard on users.
>      >
>      > What do you think?  Is there a way to open the (pandora's?) box
>     of tags
>      > safely?
> 
>     Yes and no.
> 
>     Pjotr and I have discussed this relating to biotech software. He said
>     that many scientists have a hard time finding the right tools for
>     the job.
> 
>     I proposed tight integration with wikidata[1] (every software in the
>     world will eventually have an item there) and Guix (QID on every
>     package
>     and lookup/catogory integration) and leave all the categorizing to
>     them.
>     Ha problem sidestepped, they are bikeshedding experts over there in
>     wikiland! :D
> 
>     The advantage of this is that everyone using wikidata (every package
>     manager) could pull the same categorization so we only do it once in a
>     central
> 
>     What do you think?
> 
>     -- 
> 
> 
> 
> There is also the Free Software Directory
> https://directory.fsf.org/wiki/Main_Page
> 
> I don't know what the relationship between Wikidata and the FSD is
> 
> Does Wikidata import data from the FSD ? Or viceversa ?
> 

I don't know. For now at least they keep reference to the FSD on 
software-entries that exists in the FSD.

We could integrate the FSD also but I have yet to investigate if they 
provide an API for their entries.

Anyways I view FSD as a subset of Wikidata/Wikipedia. Wikidata is the 
node and FSD the leaf. Wikidata/Wikipedia will probably within a few 
years contain the data or links to the data that now exists in the FSD.

Correct me if I'm wrong but the only advantage of FSD over Wikidata & 
Wikipedia is that they do not include references to proprietary software 
at all.

In my view it is more feasible to compile the information on in a 
structured way in central node and then pull the relevant bits to the leaf.

E.g. FSD of the future could be generated from all wikidata-entries and 
extracts of wikipedia that are an instance of 
https://www.wikidata.org/wiki/Q341. This would avoid fragmentation and 
help concentrate on building a large shared collective source of all 
knowledge within the wiki-community. FSD could exist anyhow and surely 
help enrich the upstream data.

Similarly we could generate a wikipedia subset without any entries 
pointing to (evil) private corporations (any entries that is part of 
https://www.wikidata.org/wiki/Q5621421 or whatever). I can't imagine 
what this would be good for but it its possible.

I cannot imagine that the information in FSD would not be accepted in 
any of the wikimedia projects. I could be wrong though as I honestly did 
not visit or study the FSD very much.

-- 
Cheers Swedebugia

  parent reply	other threads:[~2018-12-19  6:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 19:01 Re-approaching package tagging Christopher Lemmer Webber
2018-12-17 20:57 ` swedebugia
2018-12-17 23:08   ` zimoun
2018-12-18  7:48   ` Catonano
2018-12-18 11:34     ` Catonano
2018-12-19  6:51     ` swedebugia [this message]
2018-12-19  7:42       ` swedebugia
2018-12-18 11:29 ` Ludovic Courtès
2018-12-18 14:54   ` Christopher Lemmer Webber
2018-12-18 10:36     ` zimoun
2018-12-19 15:04       ` Ludovic Courtès
2018-12-18 20:46         ` zimoun
2018-12-19 23:12           ` zimoun
2018-12-20  7:53             ` Ludovic Courtès
2018-12-20  9:44               ` Chris Marusich
2018-12-21 21:00                 ` Ludovic Courtès
2018-12-20 10:57               ` Christopher Lemmer Webber
2018-12-20 11:55                 ` swedebugia
2018-12-21 21:06                 ` Ludovic Courtès
2018-12-19 15:05     ` Ludovic Courtès
2018-12-18 20:48       ` zimoun
2018-12-20  7:55         ` Ludovic Courtès
2018-12-20 14:42           ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=261b0ff4-53f8-6c54-1d3e-4e0ed8128d91@riseup.net \
    --to=swedebugia@riseup.net \
    --cc=catonano@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).