From mboxrd@z Thu Jan 1 00:00:00 1970 From: swedebugia Subject: Re: Re-approaching package tagging Date: Wed, 19 Dec 2018 07:51:08 +0100 Message-ID: <261b0ff4-53f8-6c54-1d3e-4e0ed8128d91@riseup.net> References: <875zvsq8ov.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZVb7-0002Uu-Q0 for guix-devel@gnu.org; Wed, 19 Dec 2018 01:44:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZVb4-0005U1-If for guix-devel@gnu.org; Wed, 19 Dec 2018 01:44:49 -0500 Received: from mx1.riseup.net ([198.252.153.129]:58747) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gZVb4-0005TY-8P for guix-devel@gnu.org; Wed, 19 Dec 2018 01:44:46 -0500 In-Reply-To: Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Catonano Cc: guix-devel On 2018-12-18 08:48, Catonano wrote: >=20 >=20 > Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia=20 > > ha scritto: >=20 > Hi :) >=20 > 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 bikesheddin= g.=C2=A0 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.=C2=A0 If I want to find all the available > roguelikes: > > > > cwebber@jasmine:~$ guix package -A rogue > > hyperrogue=C2=A0 =C2=A0 10.5=C2=A0 =C2=A0 out=C2=A0 =C2=A0 =C2=A0= gnu/packages/games.scm:3652:2 > > roguebox-adventures=C2=A0 =C2=A02.2.1=C2=A0 =C2=A0out=C2=A0 =C2=A0= =C2=A0gnu/packages/games.scm:1047:2 > > > > Hm, that's strange, there's definitely more roguelikes that > should show > > up than that!=C2=A0 A more specific search is even worse: > > > > cwebber@jasmine:~$ guix package -A roguelike > > cwebber@jasmine:~$ > > > > What I should have gotten back: > >=C2=A0 =C2=A0- angband > >=C2=A0 =C2=A0- cataclysm-dda > >=C2=A0 =C2=A0- crawl > >=C2=A0 =C2=A0- crawl-tiles > >=C2=A0 =C2=A0- hyperrogue > >=C2=A0 =C2=A0- nethack > >=C2=A0 =C2=A0- roguebox-adventures > >=C2=A0 =C2=A0- 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 t= rue*. > > But it seems like not doing so makes things hard on users. > > > > What do you think?=C2=A0 Is there a way to open the (pandora's?)= box > of tags > > safely? >=20 > Yes and no. >=20 > Pjotr and I have discussed this relating to biotech software. He sa= id > that many scientists have a hard time finding the right tools for > the job. >=20 > I proposed tight integration with wikidata[1] (every software in th= e > 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 >=20 > The advantage of this is that everyone using wikidata (every packag= e > manager) could pull the same categorization so we only do it once i= n a > central >=20 > What do you think? >=20 > --=20 >=20 >=20 >=20 > There is also the Free Software Directory > https://directory.fsf.org/wiki/Main_Page >=20 > I don't know what the relationship between Wikidata and the FSD is >=20 > Does Wikidata import data from the FSD ? Or viceversa ? >=20 I don't know. For now at least they keep reference to the FSD on=20 software-entries that exists in the FSD. We could integrate the FSD also but I have yet to investigate if they=20 provide an API for their entries. Anyways I view FSD as a subset of Wikidata/Wikipedia. Wikidata is the=20 node and FSD the leaf. Wikidata/Wikipedia will probably within a few=20 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 &=20 Wikipedia is that they do not include references to proprietary software=20 at all. In my view it is more feasible to compile the information on in a=20 structured way in central node and then pull the relevant bits to the lea= f. E.g. FSD of the future could be generated from all wikidata-entries and=20 extracts of wikipedia that are an instance of=20 https://www.wikidata.org/wiki/Q341. This would avoid fragmentation and=20 help concentrate on building a large shared collective source of all=20 knowledge within the wiki-community. FSD could exist anyhow and surely=20 help enrich the upstream data. Similarly we could generate a wikipedia subset without any entries=20 pointing to (evil) private corporations (any entries that is part of=20 https://www.wikidata.org/wiki/Q5621421 or whatever). I can't imagine=20 what this would be good for but it its possible. I cannot imagine that the information in FSD would not be accepted in=20 any of the wikimedia projects. I could be wrong though as I honestly did=20 not visit or study the FSD very much. --=20 Cheers Swedebugia