@t[Címkészet]~~META:date created = 2020.02.25., 02:34~~

@s5[Két megközelítés]

Mostanában két probléma kapcsán is sokat morfondírozok [[https://en.wikipedia.org/wiki/Tag_%28metadata%29|címkék]]ről, és arra jutottam, hogy ez egy nagyon érdekes területe az informatikának. Az egyik probléma a Ninda-program adatbázis-feldolgozási technikája (ez tekinthető megoldottnak, bár nem feltétlenül mondtuk ki az utolsó szót), a másik az, hogy szeretném a zenevideó-gyűjteményemet végre katalogizélni valahogyan – ez még nincsen megoldva. Kipróbáltam egy érdekes videókatalogizálót, [[https://www.vee-hive.net|ezt,]] végül részben azért mondtam neki búcsút pár óra után, mert nem Unicode-kompatibilis, pedig a 2010-es évek végén írták – a másik okot itt fogom elmesélni. Érdekes a címkestruktúrája, hasznosnak tartom összehasonlítani a Ninda-programéval.
Nálam a szöveghelyek kapnak címkéket, amit nézhetünk úgy is, hogy a pontos helyek (hiszen beleírom a szövegbe magát a címkét afunkcionális makróval, tehát számon tudjuk tartani, hogy a szövegnek melyik két szava között van a címke), de úgy is, hogy csak a sómirok, mert a program valójában csak a sómir ID-jét írja ki. (Ha valaki nincsen beavatva: a könyv szövegét átlagosan kb. ezerszavas részekre osztottam, amiket ősi szúni nyelven sómiroknak neveztem el, amúgy a szó nem jelent semmit, egyszerűen egymás mögé raktam öt betűt; minden sómirnak van egy egyedi azonosítója, mint mondjuk **ne-39,** ez jelenik meg az adatbázisban.) Egy sómir természetesen tetszőleges számú címkét tartalmazhat, ugyanazt többször is, hiszen semmi nem gátol abban, hogy ugyanazt a címkét többször beleírjam a szövegbe, és gyakran meg is teszem, amikor egy-egy fogalmat hosszabban magyarázok, ilyenkor a szöveg egy-egy kisebb részét átmásolom egy-egy címkébe, amit ugyanazzal a fogalommal jelölök meg. (A listákban az adott címke összes előfordulása megjelenik, és ha ugyanabban a sómirban többször fordul elő, akkor az elsőnél az ID-t írja ki, a többinél csak annyit, hogy „uo.”) Ezzel az lenne analóg, ha a videókat úgy lehetne megjelölni, hogy mondjuk egy kétórás koncertfelvételhez, ahol sokan lépnek fel, köztük a NANDO is, nem egyszerűen odatesszük a NANDO címkéjét, hanem ahhoz a ponthoz társítjuk, ahol ők színre lépnek. De mivel nekem nagyon kevés ilyen koncertfelvételem van, ezt nem tartom fontosnak, és a program nem is tudja.
Nézzük a kategóriákat. Mivel nekem jelenleg 1766 különböző címkém van (emberek neve, helynevek, több különböző tudományterülethez tartozó fogalmak), ezeket kategóriákba soroltam. E pillanatban 52 kategória van, közülük egy a „nincs”, az olyan címkék számára, amiknek nincsen kategóriamegjelölése. És itt van egy lényeges különbség a Vee-Hive kategóriarendszerével. Ők is kategóriákba sorolják a címkéket, a kategóriák pedig fastruktúrát alkotnak, fő-, al-, alal- stb. kategóriák lehetnek. Minden címke csak egy kategóriába tartozhat. Nálam nincsen fastruktúra – lehetne éppen, például az állatok, a növények, a konyhaművészet és az egészségügy kategóriáját összevonhatnám egy Biológia kategóriába, de ezen a szinten nem érnék vele semmit. Viszont nálam egy címke akárhány kategóriába tartozhat.
Nézzünk egy példát. Ámmaít Ídara egy ember a könyvben – Keita Krūmiņa egy ember a videóimon. Mindketten kapnak egy-egy címkét az illető adatbázisban, ami a nevük. Azt, hogy ők emberek (nem pedig például földrajzi helyek), azzal rögzítem, hogy fölveszem őket egy „ember” kategóriába. Mindkettejüknek van nemzetisége. Nálam ez azzal jelölhető, hogy Ámmaítot fölveszem a „szindor” kategóriába //is,// ami az „ember” kategóriától teljesen független csoport. Keitát fölvehetem egy „lett” kategóriába, de ez csak mint az „ember” alkategóriája jelenhet meg. Ez még nem lenne gond. Viszont tegyük föl, hogy életkor szerint is szeretném őket csoportosítani, mondjuk gyerekek kontra felnőttek első lépésben elég lenne. Nálam ez úgy megy, hogy csinálok egy „felnőtt” kategóriát (még eddig nem tettem ilyet, de nincs akadálya), abba beleteszem Ámmaítot, és kész. Ember, szindor, felnőtt. Három egymástól teljesen független adat, de tudok metszethalmazokat megjeleníteni, van rá külön keresőfunkcióm, amivel csak beírom, hogy //szindor:felnőtt,// és megjelennek azok, akik szindorok és felnőttek is. Keitával ezt nem tudom megcsinálni a Vee-Hive fastruktúrájú címkerendszerében, mert ha kategória az, hogy „lett”, „észt”, „litván”, valamint kategória az is, hogy „gyerek”, „felnőtt”, akkor milyen relációba helyezzem ezeket egymással? Az életkor és a nemzetiség nem áll egymással semmiféle alá-fölérendeltségi viszonyban. De ha egy videót megcímkézek Keita nevével, akkor szeretném, ha az a videó benne lenne a keresési találatokban akkor is, ha magát a nevét adtam meg, akkor is, ha a „lett” kategóriát kértem, vagyis minden videót kérek, amin lettek szerepelnek, és akkor is, ha a „gyerek” kategóriára keresek rá. Sőt metszethalmazt is szeretnék képezni, a lett gyerekeket tartalmazó videókat is szeretném kilistázni.
A fastruktúrában erre nincsen mód, mert ha a „lett” kategórián belül alkotok életkori alkategóriákat, akkor a lettekre még rákereshetek, de a gyerekekre már nem, csak a „lett>gyerek” adható meg, a „litván>gyerek”-ek nem fognak megjelenni, mert ők a „litván” kategórián belül levő alkategória. Totál máshol vannak a fán.
Tehát a fastruktúra merevségéhez képest az én megoldásom szerintem rugalmasabb. Nem zárja ki, hogy a kategóriákat később fastruktúrába rendezzem, de ezzel a szemlélettel nyilvánvalóan ez úgy menne, hogy ugyanaz a címke, például Keita neve a fa akárhány kategóriáján belül megjelenhet. Nevezzük ezt //felhősített fastruktúrá//nak.

@s5[A felhőfa]

Tekintsük a következő diagramot:

EMBEREK
  * Nemzetiségek
    * lett
      * → Keita Krūmiņa
    * litván
    * észt
  * Korosztályok
    * gyerek
      * → Keita Krūmiņa
    * felnőtt
  * Művészeti ágak
    * énekes
      * → Keita Krūmiņa
    * zeneszerző
EGYÜTTESEK
  * lett
    * NANDO
      * → Keita Krūmiņa

A hagyományos fában a négy //Keita Krūmiņa// csak négy különböző címkeként szerepelhet. A keresés ettől még ugyanolyan egyszerű, de az adatok rögzítése így agyrém, minden egyes videóhoz föl kellene venni a //Keita Krūmiņa// címke összes előfordulását, és ha utólag rájövünk, hogy nemek szerint is csoportosítani akarunk, akkor utólag kell végigmenni az összes Keita-videón és ellátni az „EMBEREK>Nemek>nő” címkével //is.//
A felhőfa strukturálisan teljesen ugyanígy néz ki, de a sok-sok //Keita Krūmiņa// egy és ugyanazon entitás. Pontosan úgy, ahogy a sok-sok címke végül egy és ugyanazon videóra mutat – ha nem így lenne, ha egy videót csak úgy jelölhetnénk meg négyféle címkével, hogy az adott videót fizikailag odamásolnánk mind a négy címkéhez, akkor a címkék semmiben sem különböznének az alkönyvtáraktól. A hagyományos fában a címke//kategóriák// nem különböznek az alkönyvtáraktól, magát a könyvtár tartalmát (alkategóriákat, címkéket) fizikailag oda kell másolni minden egyes főkategóriába, amivel persze elvész a logikai kapcsolat az egyes példányok között, valamint időt és tárhelyet pocsékolunk.

@s5[Kötetlenül]

A következő logikus lépés a felhőfa kötöttségeinek megszüntetése. Egy wincsi könyvtárstruktúráján egyértelmű alá-fölérendeltségi viszonyok vannak, és annak következtében, hogy egy könyvtár csak egy szülőkönyvtárnak lehet a gyereke, bármely sokadik szintű alkönyvtárhoz csak egyféle úton juthatunk le a gyökértől, illetve onnan föl, a visszalépéseket kizárva. És egy családfán? Az egyértelmű alá-fölérendeltségek ott is megvannak, Károly herceg Erzsébet királynő gyereke és kész, ez nem szimmetrikus. De egy gyereknek két szülője van, sőt az örökbefogadó és nevelőszülőkkel még több is lehet, ráadásul még ha ki is zárjuk (de egy valódi adatfeldolgozásnál nem zárhatjuk ki) a vérfertőző kapcsolatokból született gyerekeket, már egy többed-unokatestvérek közötti, minden emberi norma szerint tökéletesen természetes házasságból születő gyerek is teljesen felborít mindenféle hagyományos fastruktúrát, különösen ha a közös ősnek az egyik szülő mondjuk a dédunokája, a másik viszont az ükunokája (ezt az emberek többnyire nem is tudják), sőt netán több közös ős van a családfa távoli pontjain. No meg nemcsak azt a tényt kell jelölni, hogy A gyereke B-nek is meg C-nek is, hanem B-t és C-t is kapcsolatba kell hozni – akkor is, ha A meg sem született, ha nincs is közös gyerek. Daniel Morin ugyancsak megszenvedhetett ezzel a GenoPro tervezésekor, de megérte a fáradságot, mert meg tudja különböztetni a legkülönbözőbb féle-fajta házassági, szerelmi kapcsolatokat, vér szerinti és nem vér szerinti leszármazást, mindenfélét. Neki annyiban is nehezebb volt a dolga, hogy nemcsak számon akarja őket tartani, hanem ábrázolni is, ami egy komplex, hurkokkal és következetlenségekkel teli családfán valójában soha nem oldható meg trükkös kiegészítő megoldások nélkül. De mivel én strukturális ábrázolásra nem törekszem, az én dolgom ennyivel könnyebb.
Csakhogy még a GenoPro is csődöt mondana egy háromnemű társadalomban, ahol nem egyszerűen háromféle neme lehet valakinek – ezt még a GenoPro is tudja jelölni, ha máshogy nem, a „háziállat” jelentésű sarkára állított négyzetet előléptethetjük az egyik nem jelévé –, hanem mindenkinek egyenrangúan **három** szülője van. Ilyen társadalmat ír le Asimov //Az istenek is…// második részében. Tessék elképzelni egy családregényt ebben a parauniverzumban, ahol nyilván kell tartani a szülőhármasokat, mindhárom tag szüleit (mindhármat), azok szüleit (mindhármat) és így tovább.

@s5[Kapcsolatszemantika]

A családi kapcsolatokkal elértünk egy újabb kritikus pontig. Két embernek van egy gyereke, oké. Milyen gyereke? Vér szerinti? Az egyiknek vér szerinti, a másik csak neveli, esetleg örökbe is fogadta? Mindketten örökbe fogadták? Az egyik örökbe fogadta, a másik pedig neveli? Ez egy olyan információ, ami nem a szülőkhöz tartozik (azoknak lehet több gyereke is, más-más relációval), de nem is a gyerekhez (más a relációja a vér szerinti szülőjével, más az örökbefogadóval és más azzal, aki az örökbefogadó szülőnek lett később az élettársa). Ez az információ magához a közöttük levő kapcsolathoz tartozik. A GenoPro ezt úgy oldja meg, hogy ha felveszünk egy párt a gyerekükkel, akkor öt objektum jön létre: a három embernek egy-egy, plusz egy kapcsolatobjektum, ami a két szülőt köti össze, és egy leszármazásobjektum, ami a gyereket köti össze – a kapcsolattal, nem pedig bármelyik szülővel. Mind az ötnek lehetnek metaadatai, az embereknek például a nem meg a születési idő, a kapcsolatnak a fennállási dátumai meg a jellege, a leszármazásnak a fent említett variációk lehetnek a metaadatai.
Én egy kicsit másképp látom. Szerintem az emberek adatbázisbeli reprezentációi az //adatok,// a nemük, születési idejük stb. //metaadatok,// a három ember között levő kapcsolatok célszerű neve pedig //link,// hiszen köztes relációt ír le. A reláció jellege, időtartama stb. a linkhez tartozó metaadat, azaz //linkmetaadat.// Az az információ pedig, hogy valaki hány éves volt a gyereke születésekor, a kettejük születési éve, azaz metaadatai közötti köztes reláció, tehát //metaadatlink.// Nemkülönben az, hogy a gyerek a házasságnak hányadik évében született, az két link metaadatának relációja, //linkmetaadatlink,// de nem hiszem, hogy ezeknek a finom megkülönböztetéseknek ezen a szinten gyakorlati hasznát vennénk.

@s5[Kategorikusan]

Térjünk vissza a Ninda-programomhoz meg a videó-adatbázishoz és a címkékhez. A kategóriák nem azonos minőségűek. Először is vannak önkategorizáló címkék, mármint nálam az adatbázisban: ha a címke leírásában (metaadat) bizonyos szavak szerepelnek, akkor a feldolgozóprogram azt a címkét automatikusan beteszi az illető kategóriába. Azonfelül vannak speciálisan kezelendő kategóriák. Ilyen az „útvonal” kategória. Az összes többit ábécérendben listázzuk, de ezt úgy, hogy a leírásban megkeressük az //útvonal 1., útvonal 2.// stb. jelzéseket, és eszerint állítjuk sorba. Ezzel követhetem Ninda útvonalát, időrendben, nem pedig ábécérendben.
(Most, ennek a cikknek tanulsága nyomán felvettem még két automata kategóriát, a férfit és a nőt, amik e két szó, illetve a fiú vagy lány említésére rendelődnek hozzá automatikusan a címkékhez. Nem tökéletes, mert például valaki bekerült a nők közé azáltal, hogy a címke szövegében említem, hogy be akart rángatni egy **lány**t a kapu alá – ha beleírnám, hogy az illető férfi, akkor mindkét kategóriába bekerülne –, sőt bekerültek nem emberekről szóló szócikkek is, mert például a **nő**tt szót tartalmazzák. De ezen a szinten ez még elmegy. Most mindkét kategóriában éppen 35 címke van, abból 5-6 az ilyen téves azonosítás. Ha pár ezer lenne, amiből szemlátomást több száz a tévedés, akkor erőfeszítéseket kellene tenni, hogy csökkentsük a hibák számát, akár azzal, hogy kizárjuk a ragozott alakokat vagy megtiltjuk a metaadatokban a „nő” ige használatát stb.)
Speciálisan kezelendő kategóriát már említettem korábban is, csak nem mutattam ki róla, hogy az: embereknél „gyerek” és „felnőtt” kategóriákat fölvenni valójában értelmetlenség. Mikor gyerek vagy felnőtt? Amikor a videót készítették? De hiszen az életkor az egyénhez tartozik, nem a videóhoz. Dzintars Čīča gyerekként és felnőttként is fellépett, készültek felvételei, hová soroljuk őt magát? Valójában ha tudjuk, hogy valaki mikor született és mikor készült egy adott felvétele, akkor az, hogy akkor hány éves volt, a felvétellel való kapcsolatához tartozó linkmetaadat.
Aztán itt van a //rugalmas link// kérdése. Ez akkor lesz probléma, ha az adatbázisbeli adatokat linkeljük olyan dolgokkal, amik az adatbázison kívül vannak, és adott esetben olyan változáson is átmehetnek, amitől a linkünkből döglött link lesz. Ezt a fogalmat jól ismerjük a netről. Elég egy file-t fölvenni egy adatbázisba, aztán másik könyvtárba tenni vagy kijavítani a nevében egy gépeléshibát, és máris az egész rekord hasznavehetetlen. Ha olyan adatbázist készítünk, ami file-okra linkel, mint például ez a videókatalógus, akkor okvetlenül szükség van arra, hogy a katalógus keresse meg a megváltozott nevű vagy helyű file-okat és frissítse magát. Arra ugyanis nem számíthatunk, hogy a felhasználó minden egyes alkalommal, amikor máshová rak egy file-t, szólni fog az adatbázis-kezelőnek.
Pár éve csináltam egy másik katalógust, annak én írtam a programját, és a következő módszert alkalmaztam. A metaadatokat a file puszta nevéhez kötöttem, az elérési útját nem véve figyelembe – természetesen ezáltal azonos néven két file nem engedhető meg, hiába vannak máshol, de ez megfelelt a céljaimnak. A program kapott egy jegyzéket azokról a gyökérkönyvtárakról, ahol dolgozni kell, ott végignézett minden alkönyvtárban minden file-t, és az adott file-névhez tartozó metaadatokat társította hozzájuk, akárhol találta meg őket. Erre a specifikus alkalmazásra ez jó volt, és amúgy ez jelen idő, mert a programot ma is használom, a file-ok a filmgyűjteményem részei, a program pedig a házimozirendszeremet működteti.

@s5[Az idő]

Az idő egy rendkívül érdekes aspektusa a címkézésnek. Van egy esemény, amit adott időpontban történt, és ezt rögzíteni szeretnénk mint metaadatot. Attól kezdve, hogy legalább két ilyen időjelünk van, ezek már idővonalat alkotnak, és a közöttük levő időbeli relációt ki szeretnénk fejezni.
A Ninda cselekménye két időszámításban játszódik, ahol nemcsak az évszám tér el, hanem az évek hosszában is jelentős különbség van, sőt a napok hossza között is több mint húsz százalék eltérés van. Nekem ezért külön konvertálóalgoritmust kellett írnom, ami ide-oda számítja az időtartamokat és időpontokat a három között, márminthogy harmadiknak kell persze ez a földi is, amit az olvasó meg én is használok, mert enélkül nem tudnám, hogy adott pillanatban Ninda vagy bárki más hány éves.
Ilyesmikre persze a legtöbb alkalmazásban nincsen szükség, de azért az idővel dolgozni kell. Kellene. De a legtöbb címkerendszerben az időt legfeljebb úgy jelölhetem, hogy felveszek évszámos címkéket, például egy //Titanic//-filmhez a készítés évét és 1912-t, amikor játszódik. Ez lehet éppen elég, de ha látni szeretném mondjuk egy filmadatbázisban a kilencvenes évek filmjeit, és ehhez tíz keresést kell indítanom, az azért nem élmény. Vagy egy könyvadatbázisban az összes 17. századi könyvet, amiről sejtem, hogy nem lesznek sokan, de ha végig kell néznem 1600-tól 1699-ig az összes évet…

@s5[Adatstruktúrák összefoglaló katalógusa]

Tekintsük most át az ismert címkerelációs rendszereket.
**Címkementes.** Címkék nincsenek. Ez a szervezetlen információhalmaz, például a házban levő könyvek katalogizálatlan halmaza vagy egy wincsin hemzsegő file-ok halma. Utóbbi **címkementes fastrukturált,** így azért megtaláljuk a dolgainkat, de akadnak programok, amik (legalábbis bizonyos funkcióikban) egy adott könyvtár és összes alkönyvtárának tartalmát ömlesztve mutatják – ettől még nem feltétlenül probléma, hogy megtaláljuk a file-t, mert ha könyvtáranként van sorbarakva, akkor aszerint, ha az egész együtt ábécérendben van, akkor aszerint találjuk meg, csak így mondjuk kétezer file között kell végigpörgetni, míg az adott alkönyvtárat esetleg húsz között kereshettük volna meg, és abban van mondjuk száz file. Tehát időpocséklás, és hát ugye azért raktuk a file-jainkat alkönyvtárakba, hogy rendszerezzük őket, tehát ezzel az ábrázolással információt veszítünk. Nem beszélve arról, hogy ha azonos vagy hasonló nevű, tömbnyelű((saját magyarításom a //thumbnail// szóra)) file-ok is vannak a struktúra különböző helyein, akkor az ömlesztett jegyzékben nehéz vagy éppen lehetetlen megkülönböztetni őket.
**Egyszerű leírásos.** Ez a DOS-os korszakban használt ''descript.ion'' és hasonló file-ok módszere. A ''descript.ion'' egy közönséges ASCII szövegfile, amiben az adott könyvtár minden file-ja kap egy sort, abban először a file-név van, aztán egy szóköz és a hozzá tartozó leírás. Minden könyvtárban külön ''descript.ion''t helyezünk el. A módszer főként abban különbözik a címkéktől, hogy a leírások egyediek szoktak lenni, és általában nincsen támogatás arra, hogy (főleg egy komplex fastruktúrában) megkeressünk olyan file-okat, amiknek a leírásában adott kifejezések szerepelnek.
**Címkefelhő.** Minden rekord kaphat címkéket, és kész. A címkék nem állnak egymással semmilyen relációban. Sok rendszerben csak arra lehet keresni, hogy egy-egy címke szerepel-e; máshol több címke is megadható ÉS, illetve VAGY kapcsolattal, de néhol a NEM reláció is megengedett (A vagy B címke legyen, de C címke ne legyen). A Ninda-program jelenleg a VAGY relációt nem tudja, nem volt fontos, csak az ÉS meg a NEM relációt (kategóriákra, nem címkékre, hiszen itt magukat a címkéket keressük, nem a velük megjelölt szöveghelyeket). Azt hiszem, a címkéket kezelő információs rendszerekben mindenütt alap, hogy egy rekord akárhány címkét kaphat. Ha azonban a címkéket kategóriáknak nevezzük, akkor ez már nem így van, mint a @la régebbi információs rendszere, a [[http://flatpress.org|FlatPress]] alatt, ahol minden blogbejegyzést betehettünk //egy// kategóriába (múlt idő, mert a szoftver létezik, de nem tudom, hogy ma is így van-e).
**Címkefa.** A fent tárgyalt strukturált rendszer, amit a Vee-Hive tud. A címkék kategóriákba tartoznak, amik többszintű kategóriafát képeznek. Egy címke csak egy kategóriába, egy kategória csak egy felsőbb kategóriába tartozhat.
**Kategóriás címkefelhő.** A Ninda-program rendszere. A címkék tetszőleges számú kategóriába tartozhatnak, amik között további struktúra nincsen, a kategóriák egyenrangúak.
**Kategóriafelhő.** A címkék és a kategóriák egyaránt tetszőleges számú kategóriába tartozhatnak. (A rekurziót feltehetően kizárjuk: egy kategória nem lehet eleme önmagának vagy egy leszármazottjának. Keresni ettől még tudnánk anélkül, hogy végtelen ciklusba kerülnénk, egyszerűen átugorjuk a már listázott kategóriákat. A kérdés az, hogy van-e gyakorlati értelme, hogy egy kategória leszármazottja legyen önmagának vagy egy leszármazottjának.)
**Családfa.** Az emberek (vagy tenyésztett háziállatok) rokoni kapcsolatainak leírására szolgáló információs rendszerek, például a GenoPro struktúrája. Minden egyénnek két szülője lehet (ellentétben a könyvtárfával, ahol csak egy szülő lehet), de másokhoz is fűzheti valami hasonló reláció (nevelőszülők stb.). A könyvtárfával ellentétben nincsenek szabott generációk, vagyis bármely két egyént bármilyen (házassági, leszármazási) relációba állíthatunk egymással, A-tól B-ig a családfán több útvonal is vezethet, amik különböző számú generáción haladhatnak át.

@s5[Rendszer-attribútumok]

Nem külön rendszerek, hanem más rendszerek lehetséges tulajdonságai:
**Nem kapcsolódó.** Említettem a házban levő könyvek katalogizálatlan halmazát. Ha készítünk róluk egy listát, de nem jegyezzük fel, hogy a könyvek //hol// vannak, csak azt, hogy mely könyvek vannak birtokunkban (vagy ami ezzel egyenértékű: nem követeljük meg, hogy a polcról levett könyvet mindig ugyanoda tegyék vissza), akkor a listának nincs effektív kapcsolata a valóságos könyvekkel, vagyis a lista birtokában nem sokkal könnyebb megtalálni egy adott könyvet, mint a lista nélkül. Mivel a könyvek szabadon mozgatható fizikai tárgyak, a hozzájuk kötött metaadatokat csak akkor tudjuk valóban társítani hozzájuk, ha a könyveket fix helyre tesszük, ahogy a közkönyvtárban vannak.
**Címkék metaadatai.** Maguk a címkék nem feltétlenül csak szimpla jelsorozatok. A Ninda-programban, amikor egy szöveghelyhez hozzákötök egy címkét, azt elláthatom egy leírással is, és valahányszor egy címke megjelenik egy keresés hatására, a hozzá tartozó összes címke szintén megjelenik. Ezekben a leírásokban kódolhatok különféle módosításokat a címkén, például a szövegben az áll, hogy //kutyák,// ebből én megjelölöm címkeként azt, hogy //kutyá// és a leírásban elhelyezett vezérlőkarakterrel jelölöm, hogy a szó végi ékezetet le kell venni. A leírásban elhelyezett egyes szavak automatikusan kategóriába is teszik a címkét, ahogy fent említettem. De tudok a leírásban [[tablazatok|táblázatokat]] is kódolni, ami a címkéket egyfajta információkomplexekké teszi. Ha a technológiát a Kissynél is alkalmaztam volna (ráfért volna igencsak), akkor számtalan Google Maps-hivatkozást is elhelyeztem volna, hiszen valóságos helyszíneken játszódik, és a Wikipédiára meg más webhelyekre is lett volna hivatkozás jócskán, hiszen a való életben is létező intézményekkel, fogalmakkal, nemegyszer valóban élő személyekkel is találkozunk. Lehetnének az adatbázisban képek (használok képeket referenciaként, csak nincsenek ugye adatbázisba kapcsolva).
A címkék és metaadataik egészen más kontextusba emelhetnék a programozástechnikát, nem is értem, hogy ezt miért nem valósították még meg. Vegyük a Ninda-programomat most nem mint futó alkalmazást, hanem mint a szövegszerkesztőben megnyitott PHP nyelvű programkódot. Most meg is nyitottam találomra egy helyen, és egy ''$previd'' nevű változóval találtam szemben magamat, valahol a kód közepén. Mi ez a változó? Tudom én ezt fejből? Az ''$inst['fullid']'' értékét kapja, ez eddig oké, eltesszük ezt az ID-t, hogy később visszanézhessük, mi volt az előző, de miért kell visszanézni? Aha, azt mondtuk, hogy ha ''$previd'' nem üres, akkor írjunk ki egy pontosvesszőt, és ha a jelenlegi ID-vel azonos, akkor ne az ID-t írjuk ki, csak azt, hogy „uo.”, ezt a mozzanatot említettem is már ebben a cikkben. De miért kell nekem mindig a programkódból kiolvasni, hogy egy-egy változó, függvény mit csinál? Miért nem lehetnek az azonosítóik egyúttal egy metaadatbázis címkéi? Ahol nem csupán arra szolgálnak, hogy a többi előfordulásukat megtaláljuk, hanem megjegyzéseket lehet fűzni hozzájuk. Persze tekintettel a scope-ra, a lokális változóhoz másik metarekord tartozik, mint a globálishoz meg a másik függvénybeli lokálishoz. Sőt ugye nemcsak mezei szövegszerkesztőkben írunk programokat (én Androidon Jotát, Windowson Notepad+`+-t használok), hanem komplex fejlesztőrendszerek is léteznek, de nem emlékszem rá, hogy láttam volna olyat, ami egy adott függvényhez automatikusan elkészíti annak outputját és kis képernyőfotó gyanánt melléteszi. Olyat se láttam, ahol én rakhatom oda mellé a képernyőfotót kézzel. Pedig milyen egyszerű lenne. A szöveget nem plaintextben írnánk, hanem HTML-ben, persze aztán a tageket kiszedve küldenénk tovább az interpreternek vagy compilernek, és egyfelől a fontos részeket kiemelhetnénk színekkel, betűtípussal és -mérettel, másfelől képeket illeszthetnénk mellé, amik mondjuk egy rajz elkészítésének lépéseit ábrázolják. Lehetne kézzel, akár odatehetek egy függvényhez egy fotót, mert azzal akarok csinálni valamit, avagy szólhatok a rendszernek, hogy ezt a függvényt most adott inputtal hívja meg, és tegye oda mellé a képernyőfotót. Ha pedig ráviszem a kurzort egy azonosítóra, akkor kérdezhessem le a metaadatait. Vagy akár a syntax highlightot lehetne továbbfejleszteni odáig, hogy ne egyforma színnel írjon minden változót, hanem más színnel azt, amit még nem használtam az adott scope-ban, így felfigyelhetek az elgépelésekre és arra, hogy elfelejtettem beírni ''global''ba; más színnel a nem definiált függvényeket, szintén az elgépelések ellen; és hasonlókat.
**Metaadat-hierarchia.** Egy adott metaadathalmaz lehet hierarchikusan rendezett is. Így például egy dal mellé felvehetünk egy sor olyan mezőt, mint a dalszöveg és annak fordítása. Ehhez érdemes rögzíteni, hogy a dalszöveg egyes példányai milyen nyelven vannak: Lauris Reiniks például több dalát előadta lett, litván, észt, orosz és angol nyelven. Ezek rögzítésekor a dal metarekordjában keletkezik öt szubrekord, amiknek elemei a nyelv megnevezése, a cím és a dalszöveg az illető nyelven, valamint a fordító neve. De megtehetjük azt is, hogy ezt az ötöt mind lefordítjuk magyarra (nyilván nem fognak egyezni), és ez esetben az öt szubrekord mindegyike alatt lesz egy-egy további szubrekord.
Nyelvoktatási célra rögzíthetünk szövegeket úgy, hogy az egyes mondatokhoz metaadatként megadjuk a fordítást, majd azon belül az egyes szavak jelentését külön-külön, hiszen a szavak sorrendje nem azonos az egyes nyelvekben. Egy szó szótári leírása maga is egy hierarchikus struktúra, továbbá felvehetjük a ragozási paradigmáját, ami szintén egy hierarchikus struktúra. Rendkívül érdekes lenne egy olyan szövegolvasó program, amely minden egyes szónak érintésre bemutatja a szótári leírását (egy vagy több idegen nyelvű szótárból, értelmező szótárból stb.) és a ragozását.

@s5[Kategóriák típusai]

**Rendezési módok.**
  * A kategória elemei között nincs rögzített sorrend, a találati listákat olyan sorrendben adjuk, ahogy a felhasználó kéri.
  * Az elemek között numerikus sorrend van, mert azok például egy műveletsor lépésein.
  * Időrendi sorrend van.
  * Térbeli rendezettség van, mert a kategória elemei helyek vagy helyekhez kapcsolódnak.
  * Logikai kapcsolati rendszer van, mert a kategória definiálja az elemek kapcsolatait. Így például ha az elemek egy családi cég tagjai, akkor az egyik szempontrendszer a családfa, a másik a cégben betöltött hierarchia.
**Vonzás.** Egyes rendszerekben (mint a Ninda-programban is) érdemes létrehozni olyan kategóriákat, amik bizonyos típusú adatokat automatikusan magukhoz vonzanak, vagyis azok bekerülnek explicit kategóriába sorolás nélkül is. Ilyen a programban a jelen cikk megírása alatt elhelyezett „férfi” és „nő” kategória. Sok rendszerben az egyetlen ilyen kategória a „nincs”, azoknak az elemeknek, amik még nem kaptak besorolást.

@blogf[számtech adatbázisok Ninda irodalom Vee-Hive GenoPro FlatPress PHP programozás]