Mostanában két probléma kapcsán is sokat morfondírozok címkékrő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, 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.
Tekintsük a következő diagramot:
EMBEREK
EGYÜTTESEK
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ímkekategó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.
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.
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.
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ányt 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.
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…
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ű1 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.iont 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 LAttilaD.org régebbi információs rendszere, a 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.
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 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 globalba; 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.
Rendezési módok.
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.