Samenvatting

Samenvatting van het document.

Status van dit document.

Inleiding

Het IMGolf model betreft een voorbeeldmodel waarmee uitgelegd wordt hoe NEN3610 in elkaar zit. Het oorspronkelijke voorbeeld model was een UML model. Voor de Linked Data toets is dit voorbeeld uitgewerkt in drie stijlen:

De Koninklijkse Haagse Country & Golfclub golfbaan is vervolgens als voorbeeld data opgepakt. Deze voorbeeld data is in vier formaten beschikbaar:

Door deze opzet, kunnen we een goed beeld krijgen wat de verschillen op data-niveau zijn als je deze verschillende stijlen toepast.

Het vergelijken van deze stijlen is pas goed mogelijk als je de verschillende modellen van de data naast elkaar kunt houden. Dat is lastig, omdat deze vanzelfsprekend van elkaar verschillen: ze kennen een eigen metamodel (respectievelijk dat van UML, COINS, GWSW-OROX en W3c)

Wel is het mogelijk vanuit de data, in het geval van de Linked Data situatie, voor elk van de stijlen een model te genereren. Hierdoor zijn de verschillen goed zichtbaar

Ook geldt dat de drie metamodellen van COINS, GWSW en OROX gegenereerd kunnen worden uit de drie IMGolf modellen. Zo kunnen we ook op metaniveau een vergelijking doen.

Deze aanpak is hieronder uitgewerkt

De IMGolf modellen

Deze sectie beschrijft de vier IMGolf modellen

IMGolf UML

Hieronder is het originele UML IMGolf model afgebeeld

IMGolf W3c

Hieronder is het IMGolf model afgebeeld conform W3c RDF/OWL/SHACL

IMGolf COINS

Hieronder is het IMGolf model afgebeeld conform W3c COINS

IMGolf GWSW-OROX

Hieronder is het IMGolf model afgebeeld conform W3c GWSW-OROX

Meer informatie over het IMGolf model conform OROX is hier te vinden.

IMGolf gegenereerd

Op basis van de concrete data van 1 golfbaan kan een model gegenereerd worden, zodat het makkelijker wordt om de verschillende stijlen met elkaar te vergelijken

Generatie opzet

Bij de generatie wordt het originele databestand opgepakt, en vervolgens wordt een model gegenereerd door de volgende stappen uit te voeren:

  1. Indien de data een subclassificatie bevat, dan wordt deze overgenomen in het model en wordt de superklasse ook in het model gezet.
  2. Klassen (owl:Class) worden aangemaakt voor elk unieke object op de positie ?subject rdf:type ?object
  3. Eigenschappen worden aangemaakt voor elk unieke predicate op de positie ?subject ?predicate ?object
    • Een eigenschap owl:ObjectProperty wordt aangemaakt indien het ?object een resource is (IRI en/of Blank node)
    • Een eigenschap owl:DatatypeProperty wordt aangemaakt indien het ?object een literal is
  4. Een rdfs:label element wordt toegevoegd indien deze nog niet aanwezig was (afgeleid uit de URI van een klasse of eigenschap: het deel na de '#' of na de laatste '/')
  5. Een nodeshape (sh:NodeShape) wordt aangemaakt voor elke gevonden klasse
  6. Een datatype propertyshape (sh:PropertyShape) wordt aangemaakt voor elke gevonden datatype-eigenschap per klasse
    • Het datatype wordt afgeleid uit het datatype van het ?object. Dit kunnen (dus) meerdere datatypes zijn
  7. Een class propertyshape (sh:PropertyShape) wordt aangemaakt voor elke gevonden object-eigenschap per klasse
    • Dit geldt alleen indien het ?object een IRI is (dus geen blank node)
    • De class wordt afgeleid uit het type van het ?object (dwz: de triple ?object rdf:type ?type). Dit kunnen (dus) meerdere classes zijn, en het is ook mogelijk dat er geen class is
    • Een class propertyshape kun je zien als een relatie tussen twee klassen
  8. Een blank node propertyshape (sh:PropertyShape) wordt aangemaakt voor elke gevonden object-eigenschap per klasse
    • Dit geldt alleen indien het ?object een Blank node is
    • De class wordt afgeleid uit het type van het ?object (dwz: de triple ?object rdf:type ?type). Dit kunnen (dus) meerdere classes zijn, en het is ook mogelijk dat er geen class is
    • Een blank node propertyshape kun je zien als een complexe eigenschap bij een klasse

Bovenstaande zou nog verder uitgebreid kunnen worden. Te denken valt bijvoorbeeld aan:

Vanzelfsprekend kan alleen maar die dingen gegenereerd worden die ook in de brondata zitten. Uitleg of afwijkende namen zijn niet mogelijk, en ook kunnen cardinaliteiten of subklassificaties niet met zekerheid worden afgeleid.

Hoewel we voor de generatie uitgaan van het W3c RDF/OWL/SHACL metamodel, zul je zien dat het gegenereerde IMGolf model toch zal afwijken van het met de hand opgestelde IMGolf model. Het verschil geeft mooi aan wat je als modelleur nog toevoegd als uitleg.

Ook is het niet mogelijk om deze aanpak te gebruiken voor de UML/GML data, aangezien dit geen Linked Data is en dus niet generiek in te lezen is (hier zou dus eerst een basale vertaling van GML naar Linked Data gemaakt moeten worden.

Een dergelijke omzetting zou een mooi beginpunt kunnen zijn van een generieke aanpak

Gegenereerd COINS model

Onderstaand diagram is de visualisatie van het RDF/OWL/SHACL model dat gegenereerd is conform bovenstaande aanpak op basis van het COINS voorbeeldbestand van de Koninklijke Haagse Golf & Country club

Gegenereerd GWSW-OROX model

Onderstaand diagram is de visualisatie van het RDF/OWL/SHACL model dat gegenereerd is conform bovenstaande aanpak op basis van het GWSW-OROX voorbeeldbestand van de Koninklijke Haagse Golf & Country club

Gegenereerd W3c model

Onderstaand diagram is de visualisatie van het RDF/OWL/SHACL model dat gegenereerd is conform bovenstaande aanpak op basis van het W3c RDF/OWL voorbeeldbestand van de Koninklijke Haagse Golf & Country club