Dit verhaal is geïnspireerd door de reeks artikelen van Holger Knublauch over Shacl. Doel was het dichten van de mentale kloof tussen menselijk begrip welk vaak op beelden steunt, en triples, die minder sympathiek zijn voor de mens. Om te tonen hoe dit werkt, heb ik in een Visio diagram een schaakpartij getekend die alle informatie bevat over de afloop van een partij. Deze informatie is vervolgens als RDF/Turtle naar een triplestore overgebracht.
Een diagram is zodoende een drager van informatie voor de menselijke expert én eenvoudig te delen als Linked Data.
Het opsporen van de informatie welke een schaakpartij, of enig ander spel, definieert, blijkt eenvoudig te zijn indien we naar een tekening kijken en tegelijk de eigenschappen vastleggen van de dingen die we zien.
Al tekenend ontstaat het model.
Het grote voordeel van modelleren met een tekening is dat we het model parallel met de sjablonen vastleggen. De domeindeskundige, in dit geval een schaakspeler, en de modelleur schetsen samen hoe hun wereld eruit ziet.
De figuren in de tekening verhouden zich tot sjablonen als objecten tot klassen. Zo hebben de figuren eigenschappen die de sjabloon heeft. Het venster Shapegegevens toont de eigenschappen die de figuur van een witte pion heeft. Zo wijst `type (IRI)` naar de definitie van een schaakstuk op wikidata. De basis IRI plus lokale naam vormen samen een eenduidige naam waaruit een IRI van het schaakstuk gemaakt kan worden. De definities van de eigenschappen staan onder in het venster (“Tekst van scherminfo”). Informatie kan handmatig worden ingevoerd of automatisch worden bepaald. Zo kent Visio de positie van het stuk op het schaakbord en vult het de eigenschap “op veld F2” automatisch in.
Een soortgelijke modellering maken we van een speler. De eigenschappen zijn vrij gekozen en wellicht zijn er andere gegevens die al als LoD beschikbaar zijn zoals de ELO rating. Een ander, fictief, gegeven is de lichaamslengte van de speler die met een eenheid gepaard is. In dit geval is de eenheid millimeter maar meter of voet kan ook voorkomen. Een eigenschap met een meetbare waarde komt vaak voor in combinatie met eenheid of andere meta-gegevens zoals meetapparaat, standaardafwijking, omstandigheden van de meting, verwijzing naar een oorsprong, en zo voort. Deze meta-data geven inzicht in de kwaliteit van de meetwaarde. In Linked Data zien we typisch een meetwaarde terug als blanco node die als façade dient voor de achterliggende informatie – waarvan het getal `1804,00` slechts een klein deel vormt.
De eigenschappen in bovenstaand venster zijn meest literals, zo wordt de eigenschap titel gepaard met een letterlijke stringwaarde “grootmeester”. In de RDF data vindt men een subject-predicaat-object triple zoals <http//ijzerweg.nl/data/schaak/spelers/4712>, fe:titel, "grootmeester"@nl . .
Een potje schaak is een opeenvolgende serie zetten door twee spelers. De volgorde van de zetten is natuurlijk van eerste belang. Onderstaand sjabloon toont dan ook een partij als een lijst genummerde zetten met afwisselend wit en zwart. De velden E2 –> E4 zijn handmatig ingetikt maar Visio kan met enige inspanning ertoe gebracht worden om de beweging van de stukken automatisch te registreren. De zetten in de partij geven weer van, en naar welk veld een stuk wordt verzet. In de tekening is een lijst een soort container waarvan de leden gerangschikt zijn.
De sjabloon “partij” verwijst naar twee spelers. In de tekening is deze verbinding gelegd door het gele schijfje, een “control”, van de partij-figuur naar de speler-figuur te trekken. Visio kleeft vervolgens de lijn aan het doelfiguur zodat de verbinding blijft bestaan ook indien we de spelers verplaatsen op het tekenblad.
In de graaf zullen we een triple vinden welk dit concept voorstelt:
<http://ijzerweg.nl/data/schaak/partij/partij%201> fe:spelerWit http://ijzerweg.nl/data/schaak/spelers/4712 ; fe:spelerZwart http://ijzerweg.nl/data/schaak/spelers/4711 .
Iedere “control” in Visio heeft een naam. De controlverbinding tussen partij en spelers heet spelerWit c.q. spelerZwart en dit vinden we terug in het predicaat fe:spelerWit en fe:spelerZwart.
Fouten zijn leerzaam en vast onderdeel van iteratieve modellering.
In bovenstaand model is de kleur waarmee de speler speelt een eigenschap van de speler. Visio kleurt de speler automatisch in aan de hand van de opgegeven kleureigenschap. Dit was een eerste intuïtieve maar onFAIRe keuze want het suggereert ten onrechte dat Boris Spasski slechts met wit kan uitkomen. De kleur waarmee een deelnemer speelt, moet dus een eigenschap van de partij zijn – niet van de speler.
Een tweede modelleerfout is het toekennen van een ELO-rating aan de speler. Op de eerste plaats is het goed mogelijk dat ergens op het web de ratings zijn opgeslagen maar ernstiger is het feit dat een rating geen constante eigenschap is. Een verbetering, hier niet uitgevoerd, is het koppelen van een rating aan een tijdvak.
Een object, in de zin van het laatste lid van een triple, kan ook een URI zijn dat verwijst naar een ander object. Zo verwijst een zet naar een stuk. In een tekening bovenaan in dit verhaal is zo’n verband inzichtelijk gemaakt door een verbindingslijn tussen de witte pion en de derde zet “F2-F3”.
Een goede beslissing was om de zet niet te koppelen aan een kleur van het gezette stuk. De kleur volgt namelijk uit het feit dat alle even zetten met zwart zijn én uit de kleur van het gezette stuk. Een mogelijke kwaliteitscontrole is hieruit te formuleren dat iedere even zet verbonden moet zijn met een zwart stuk.
Een zet hoeft strikt genomen niet verbonden te zijn met een stuk omdat de toestand van het schaakbord bij aanvang bekend is. Zo is af te leiden dat bij de eerste zet, E2->E4, een pion betrokken was. En bij de vijfde zet ging een stuk van B1 naar C3 – en dat moest wel het witte paard zijn geweest. De keuze om toch de relatie te leggen maakt het eenvoudiger om software rondom de data te schrijven want een programmeur wil waarschijnlijk niet de toestand van het spel vanaf het begin reconstrueren aan de hand van de gedane zetten.
De tijd van de zet is van ondergeschikt belang in dit model maar het is voorstelbaar dat de duur tussen zetten interessante informatie geeft over tijdnood of complexiteit van de stelling. Uitbreiding van het model met tijdregistratie van zetten is natuurlijk mogelijk maar kan strijdigheden met de volgorde van de zetten opleveren die vervolgens tegen regels getest moeten worden. In dat geval moet men overwegen om de zetten niet als lijst maar als ongeordende verzameling (“Bag”) op te slaan. OWL biedt een geschikte ontologie om de tijd te modelleren.
Bovenstaand verhaal maakt duidelijk hoe we de informatie in de tekening opslaan. Gelukkig heeft Visio, net als andere CAD of vectoriële tekenprogramma’s een API waarmee we aan de gegevens achter de getekende vormen komen. Het algoritme gaat als volgt
Bovenstaand verhaal maakt duidelijk hoe we de informatie in de tekening opslaan. Gelukkig heeft Visio, net als andere CAD of vectoriële tekenprogramma’s een API waarmee we aan de gegevens achter de getekende vormen komen. Het algoritme gaat als volgt
De triple store die de data achter de tekening huisvest is hier te vinden.
