Excel-től Turtle-ig NodeJS-sel

Amikor a legtöbb ember belegondol egy szervezet birtokában lévő adatokba, valószínűleg elképzelne valahol egy nagy szerverfarmot, amelynek terabájtos adatai vannak hatalmas relációs adatbázisokban. Valószínűleg a szervezeten belül meglepő (sőt zavaró) mennyiségű metaadatot nem tárolnak ott, hanem inkább létrehoztak (és fenntartottak) a Microsoft Excel vagy annak sok-sok származéka az évek során. Ez tipikusan olyan információ is, amelyre a szemantikus hármas tárolók és a metaadatközpontok ideálisak – vezérelt szókincsek, adatszótárak, összefoglaló elemzések és így tovább.

Van azonban egy p r probléma az Excel adatforrásként. Az Excel munkafüzet lényegében egy munkalapok könyve, amelyek maguk is rácsok. Nincsenek öröklési struktúrák, nincs valódi séma, azon túl, hogy néha homályos tervek vannak, amelyeket a táblázatkészítő ad hoc módon rendelt magának. Ez azt jelenti, hogy ha egy Excel-táblázatot ad egy ontológusnak vagy lenyelési mérnöknek, akkor nincs olyan varázsgomb, amelyet megnyomhatnának a szerkezet helyére történő becsúsztatásához; a struktúrát törvényszéki értelemben kell kidolgozni. Ez azt jelenti, hogy ha ilyen módon szeretné használni az Excel programot, akkor idő előtt be kell írnia egy ilyen sorrendet.

Hármas cellaként

Szemantikai szempontból kétféle megközelítést alkalmazhat az ilyen táblázatok RDF-adatokká történő átalakítására. Az elsőben minden cellát megkeres, amelyben van tartalom, majd létrehoz egy URL-t, amely a táblázat, a sor és az oszlop alapján tükrözi a cella helyét.

Ha például volt egy myData.xls nevű táblázata (vagy hasonló kiterjesztés), akkor a [B5] cellát a „Saját táblázatban” („Jane Doe” értékkel) a következő hármasokként adhatjuk meg ( Teknős):

Ez valójában nem rossz megközelítés, ha a táblázat szerkezete ritka és nagyon jól meg van határozva, de hacsak ez a struktúra nincs meg, és kibővíthető, sok munka sok esetben kevés kifizetés mellett. Legjobb felhasználási esetek vannak, amikor az Excel-t használják adatbeviteli űrlapként, vagy amikor algoritmikusan (esetleg jelentésként) generálják, és a konkrét szerkezet többnyire ismert. Azonban gyakran jobb kihasználni a táblázatok egyik legnagyobb előnyét – a munkalapok és a táblázatok közötti kapcsolatot.

Munkalap táblázatként

Aki jelentős ideig dolgozik adatokkal, rájön, hogy a táblázat egy táblázat, az egy táblázat. Táblázatot ábrázolhat vesszővel elválasztott értékként (CSV, amelyet valójában nem kell csak vesszővel elválasztani) dokumentumként, ahol az első sor a körülhatárolt mezőneveket, a második és az azt követő sorok pedig a körülhatárolt sorértékeket tartalmazzák.

A relációs adatbázis majdnem pontosan ugyanazt csinálja, amikor a mező nevét a mező pozíciójának proxyjaként használja (ami viszont egy adott sorhoz egyben az adott sor értékének mező pozíciója is). A legtöbb adatbázis emellett tartalmaz sematikus metaadatokat (sémadefiníciót vagy DDL-t) az olyan területek kezeléséhez, mint az adattípus reprezentációja és az adott mező tárolási kapacitása. A táblázatnak neve is van.

Az Excel munkalap CSV formátumban ugyanúgy működik – az első sor mezőneveket tartalmaz, a következő sorok pedig a mező pozíciójához tartozó értékeket tartalmazzák. Az elsődleges különbség az, hogy a tábla neve mostantól a munkalap nevére cserélődik, és az adatbázis viszont megfelel a munkafüzetnek.

A dolgok érdekessé válnak, hogy ugyanez a levelezés történik az RDF-ben is. Az RDF egy normalizált adatnyelv – ez azt jelenti, hogy minden hierarchia lapos táblákra bomlott. A legegyszerűbb esetekben ez azt is jelenti, hogy egy-egy megfeleltetést hajthat végre egy relációs adatbázis, egy táblázat és egy háromszoros között, ez utóbbi egyetlen figyelmeztetése az, hogy vigyáznia kell a globális azonosító kulcsok előállítására. (URI vagy IRI), amelyek a táblázatos információkból levezethetők.

Ezt a megközelítést alkalmazzuk a jelenlegi cikkben.

NPC leírása

Kiskoromban lelkes szerepjáték-játékos voltam (és természetesen a börtönmester), akit olyan játékok vonzottak, mint a Dungeons and Dragons, a Champions, a GURPs és így tovább, nemcsak a képzeletem gyakorlásának lehetősége miatt, hanem azért is, mert annyi menő asztal volt a könyvekben, és mint adatgyerek gyerek, ez volt a nerd-dom magassága. Ennek következtében valószínűleg nem meglepő, hogy az RPG-k lettek az én „go-to” példáim az adatmodellezés és a struktúrák bemutatására, elsősorban azért, mert elég összetettek ahhoz, hogy érdekesek legyenek, de nem annyira összetettek, hogy zavaróak legyenek, és mert nem találkoztam egy programozó, akinek nincs legalább egy kedvenc RPG karakterlapja lebegve valahol a hátsó szekrényében.

Tehát az ötlet szemléltetése céljából (és néhány adattal kezdve) létrehoztam egy Excel munkafüzetet Game.xlsx néven, és tetszőleges mintakészletet állítottam össze. A formázás megkönnyítése érdekében ezt több táblázatra bontottam:

Érdemes megjegyezni, hogy ez nem teljes körű. Inkább csak annyi, hogy különféle mintákat mutatunk be a hármasok elkészítésében.

A fenti táblázatok bontása nem egészen véletlen. A Név minden esetben feltételezhető, hogy a kapun kívül egyedi – más szóval, egy kulcs alapjául szolgálhat. Ne feledje, hogy a külsőleg összegyűjtött adathalmazok esetében ez nem mindig biztonságos feltételezés – lehet, hogy több embernek ugyanaz a neve, ezért szükség lehet más kulcsok (akár egyedi, akár kombinált) feldolgozására egyedi azonosító létrehozásához.

A kulcsok (és végső soron az URI) létrehozásának technikái eltérnek, de az itt megadott példákban az npc azonosítók állnak a legjobban a név attribútumra, általában a szóköz és más írásjelek tömörítésével a névből. Így a „Mara GlynisDottir” létrehozza az uri kulcsot npc: _MaraGlynisDottir . Itt érdemes megjegyezni, hogy mivel a generált nem közvetlen egy-egy adatbázis, hanem inkább fogalmi ábrázolás, akkor megadhatja a fogalmi névteret ahelyett, hogy megpróbálna azonosítani egy adott rendszer adatbázis. Ha azonban egy URI-t akartál létrehozni az npc-re a rendszerazonosító (itt a 125-ös rendszer, ami lehet táblázat) alapján, akkor a következőképpen nézhet ki:

Itt fontos megjegyezni, hogy biztosítani kell, hogy a kulcs globálisan univerzálisan elkészíthető. Ha a 125-ös és a 130-as rendszernek egyaránt van Mara Glynisdottir-je, akkor őket különálló entitásként kell kezelni, amíg bebizonyosodik, hogy valószínűleg ugyanaz (a cikk hatályán kívül esik).

A társítások gyakran előfordulnak a táblázatokban, ahol általában névként, nem pedig kulcsként adják meg őket. Ezek általában olyanok közé tartoznak, amelyeket gyakran ellenőrzött szókincseknek vagy kategóriáknak neveznek. Például a nemnek négy lehetséges kategóriakifejezése van (itt „Férfi”, „Nő”, „Androgün” és „Nem alkalmazható”), amelyek mindegyike nemi szókincshez kapcsolódik. Ez viszont azt sugallja, hogy bár létrehozhat egy táblázatot csak a nemek számára, egy másik a fajokra és így tovább, az a tény, hogy ezek mind olyan kifejezések, amelyek többnyire azonos releváns jellemzőkkel rendelkeznek, arra utal, hogy jobb lenne két táblázatot létrehozni – az egyik a szókincsekre, a másik a kifejezésekre.

A táblázatkezelő példában ezt úgy tették meg, hogy létrehoztak még két munkalapot, a fülek neveként a Feltételek és a Vocabszal.

A Term munkalap második oszlopa a Vocab munkalap szókincsének neve. Mindaddig, amíg biztosítani tudja, hogy az egyes táblákból készített kulcsok összhangban vannak egymással és az NPC táblával, képesnek kell lennie ezek átalakítására elsődleges kulcs / idegen kulcs linkekké. A teljes példa nyolc szókincset határoz meg hét szókincsben, bár egy valós alkalmazásban ezeknek a tábláknak a tucatjai vagy százai lehetnek, potenciálisan több tízezer osztályozási kategóriával. Az ilyen kategóriákat vagy asszociációkat tekinthetjük aspektusoknak is, mivel az entitásokat (például az NPC-ket) a nézetek és a hozzájuk tartozó attribútumok (például nevek vagy pontszámok) kombinációjának tekinthetjük.

Az attribútumok viszont általában atomi értékek – húrok, számok, dátumok, amelyeket a tudós skalároknak nevezne. Legalább kétféleképpen lehetett meghatározni az attribútumokat. Az első olyan specifikus tulajdonságok lett volna (például erő vagy intelligencia). Ezek a következők lehetnek:

ahol mindegyik attribútumhoz tartozik egy adott tulajdonság (vagy állítmány), vagy ezt úgy modellezhették:

ahol csak egy állítmány van (npc: hasAttribute), majd egy érték és társított típus.

Inkább az alkalmazás hasznossága miatt, az első űrlapot részesítették előnyben az attribútumok esetében (Ön általában konkrét attribútumértékeket hasonlít össze). Ennek azonban a hátránya, hogy ha az attribútumok nem specifikus skalárok, hanem összetettebb struktúrák, akkor az alternatív megközelítést kell választania. Modellezési szempontból asszociációt hozhat létre egy adott attribútum predikátum és a társított típus között:

Az npc: hasStrength predikátum nem egészen a npc: hasAttribute alosztálya, mivel az előbbi adat tulajdonság, míg az utóbbi objektum tulajdonság, de van köztük kapcsolat.

A tágabb formát az érméknél használják. A játéknak ötféle pénzneme van, a penny alapján (lényegében az a bér, amelyet a fizikai munkás keresne egy munkanapért). Az érme általánosított értékkel rendelkezik (amelyet az alapértelmezett tulajdonságérték jelöl), a legkisebb pénznem (egy fing) egy fillér tizenketted része (körülbelül egy óra munkaerő), és minden ezen felüli egység tizenkétszer nagyobb. Így az egyén teljes vagyona meghatározható úgy, hogy az egyes típusú érmék számát megszorozzuk az adott típus alapértelmezett értékével. Ez egy olyan számítás, amelyet a SPARQL segítségével lehet végrehajtani, és mivel ez egy mérőszám a játék sikerének meghatározásához, a helyszíni számításnak értelme volt. 25 Solad 14 Lunad 3 Félholdat ekkor 5 * 123 + 14 * 122+ 3 * 12-re, azaz 10 693 krajcárra számolnak. A játék világában a legtöbb paraszt általában nem nagyon látta a Soladokat, amint az várható volt.

Az egyes érmegyűjteményeket ezután egy erszény képviseli (tehát egy pénztárca szolátákhoz, egy lunádokhoz stb.). Az erszény a következőképpen jelenik meg:

és az egyes npc-k összes pénztárcájának összege a következőképpen számítható ki (SPARQL):

Az utolsó dokumentum, amelyet az Excel dokumentumban össze kell állítani, a „ Névterek ” tábla lesz. Ez a táblázat megegyezik az előtaggal a névtérrel és a leírással:

azzal a szándékkal, hogy mindkettő a Turtle / Sparql-re koncentráljon. Az első esetben lehetővé teszi a névterek helyi azonosításának biztosítását, ezért nincs szükség további konfigurációs fájlra. Ezeket mind a teknősgeneráló fájlok, mind pedig a névterekről szóló SHACL-információk hozzáadásához használják az adatkészlethez.

Az Ingestor megírása

Ennek nagy része arra összpontosít, hogy időt fordítson az Excel dokumentum elkészítésére. A munka elvégzése után azonban a tényleges átalakításokat két kedvenc eszközemmel kezelhetem – a sablon literálokkal és a node.js alapú XLSX.js modullal. Ez utóbbi praktikus eszköz három változatban kapható – egy meglehetősen hatékony közösségi verzió (amely ingyenes és nyílt forráskódú), majd két erősebb vállalati verzió, amelyek lehetővé teszik az Excel dokumentumok jobb formázását. Az itt generált mintakód a közösségi verziót használja.

Nekem van egy egyszerű befogadóm verziója a git-en, amely tartalmazza az XSLX fájlt.

Ez a befogadó NEM általános célú – csak a folyamat működésének bemutatására szolgál. dolgozok egy általánosabb befogadón, amelyet szolgáltatásként fognak futtatni, és erről továbblépve a GitHub-jegyzetekbe fogok foglalni.

Az index.js fájl tartalmazza a vonatkozó Javascript kódot:

A compactToken () függvény felvesz egy karakterláncot, eltávolítja az írásjeleket, és létrehozza a string kompakt (nincs szóköz) camelCase változatát. Ez elsősorban az URI-k előállításának elősegítésére szolgál.

Az xlsx objektum támogatja az Excel-dokumentumok betöltését és belső átalakítását Javascript-objektumok sorozatává. Az alapobjektum a teljes munkafüzet ábrázolása, míg a workbook.Sheets [] tömb használható a megnevezett lapok lekérésére.

Ez a szakasz utána következetesen ugyanazon kód változatait ismételjük meg. Az első szakasz lekérdezi a tömbből a „ Névterek ” munkalapot, és egy segédfunkcióval átalakítja ezt objektum tömbvé, az első sorban szereplő neveket használva minden objektum tulajdonságneveként (pl. ,

Ezután egy sablon literál jön létre az egyes sorok kezeléséhez:

A létrehozás után az alkalmazás a tömbön átfordul, és minden csomópontot (sort) egy Turtle előtag deklarációba térképez:

A második szakasz valami hasonlót csinál, azzal a különbséggel, hogy a teknős előtag deklarációk előállítása helyett SHACL deklarációkat hoz létre ugyanazokhoz az erőforrásokhoz:

Az ezt követő szakasz létrehozza a szókincs deklarációit, majd a kifejezés definíciókat követi:

Az utolsó szakasz létrehozza az NPC-t, amely könnyen a legösszetettebb objektum. A Javascript foglalkozik mind az asszociációk leképezésével (csatlakozás az előző szakaszokban először meghatározott URI-khoz), majd létrehozza az asszociációkat, majd végül kezeli a pénznemeket:

Ne feledje, hogy a töredékazonosítókkal előre meghatározott listákon (például az attribútumlistán) is iterálhat, hogy ne csak alanyokat és objektumokat hozzon létre, hanem még predikátumokat is, például npc: hasStrength . Ez létrehozza a kimenetet:

Ebben a példában ez adja ki a konzolnaplót. A konzolon való futtatáshoz írja be:

vagy ha meg akarja őrizni a kimenetet, hogy a szövegszerkesztőben nézhesse meg, futtassa:

Összegzés

Ennek célja az olyan alapvető fogalmak szemléltetése, mint például a sablon literálok használata és az Excel tervezésének fontossága egy adott formátumra / célra való tekintettel. Ennek egy általánosabb változatán dolgozom, amely paraméterezett formában vagy szolgáltatásként futtatható, és amely eléggé magától értetődő heurisztikát fog használni az alapvető használati esetek kezelésére (egyenes térkép készítése módosítások nélkül) és felülírásra. bizonyos funkcionalitás segítő modulokkal. Ezenkívül idővel a legtöbb RDF formátumra is kiterjesztem a tartományt, bár a Turtle lesz a legfontosabb.

Kurt Cagle író, információs építész és általános ismeretekkel rendelkezik. A washingtoni Issaquah-ban él, és figyeli, ahogy macskája kíséretében leesik az eső.