nyuuzyou/wikis huggingface dataset:
Succesvolle lancering nieuwe PiLOD Platform server

Categorie:Platform LOD
PiLOD heeft nu de beschikking over een eigen krachtige server die gehost wordt bij het Big Data Value Center in Almere. Deze server wordt beheerd door Gerard Persoon
Deze PiLOD server wordt onze primaire leer- en experimenteeromgeving en zal ook een omgeving worden waar organisaties zelf linked datasets kunnen publiceren en onderhouden. Het gaat dan om linked datasets die al wel gemaakt zijn, maar die nog niet gepubliceerd zijn, zodat ze door andere partijen makkelijk geconsumeerd kunnen worden in mogelijke LOD toepassingen.
Op de nieuwe PiLOD server is al de nodige software geinstalleerd die door de PiLOD deelnemers gebruikt kan worden vanuit de verschillende use cases die bedacht en beschreven zijn binnen de diverse PiLOD werkgroepen. Ook kan de nieuwe server omgeving gebruikt worden in combinatie met andere server omgevingen, bijvoorbeeld als men federated queries zou willen testen.
Stap-voor-stap zal nieuwe software op de nieuwe PiLOD server geinstalleerd worden als daar behoefte aan is. Denk dan bijvoorbeeld aan software componenten uit de LOD2 stack. En om het werken met LOD2 componenten zo eenvoudig mogelijk te maken wordt al zoveel mogelijk gewerkt met dezelfde software versies zoals die gebruikt worden binnen de LOD2 stack.
Net zoals voor de PiLOD Wiki zal bij elke PiLOD bijeenkomst een korte update over de voortgang en de wijzigingen gegeven worden.
Support

Categorie:Wiki
__NOTOC__
== Aanvragen account ==
Dit is een Wiki/Website ter ondersteuning van het Platform Linked Data Nederland (PLDN).
Wil je schrijven of commentaar leveren? Vraag dan een account aan bij Pieter van Everdingen: info@pldn.nl.
== Semantic MediaWiki en WikiXL Handleidingen ==
* SMW Quick Reference
* SMW User Manual
* SMW Admin Manual
* (moet ge-update worden naar de laatste versie van de Wiki/Website)
== Support ==
Onderwerp 	Contactpersoon 	E-Mail Adres
Aanvragen user accounts 	Pieter van Everdingen	info@pldn.nl
Technische ondersteuning	Jan Willem van Veen 	jwvveen@archixl.nl
Thema Bestuurlijke Verankering

categorie:Thema A
==Inleiding==
De case bestuurlijke verankering LOD richt zich op het opstellen van een kern boodschap aan bestuurders. Een toegankelijke beschrijving waarin het fenomeen LOD helder wordt gepositioneerd in het speelveld van (geo)informatieontwikkelingen, waarin de voordelen van Linked Open Data voor aanpalende (geo-)projecten worden beschreven en waarin aanbevelingen worden gegeven welke stappen aanpalende (geo-)projecten zouden moeten zetten om de voordelen van Linked Open Data te benutten.
==Trekker==
Naam 	Organisatie
John van Echtelt	CGI
==Deelnemers en geïnteresseerden==
==Activiteiten==
==Resultaten==
==Referenties==
Thema Kennis

Categorie:Thema B
==Inleiding==
Vanuit het thema Kennis proberen we niet alleen inzichten in LOD te verkrijgen maar proberen we daar zelf ook een LOD-toepassing van te maken middels een wiki. Aan de voorkant, voor de gebruiker, staan er nette webpagina's die de gebruiker kan lezen en wijzigen. Aan de achterkant, voor andere machines, kan de kennis als RDF / SPARQL worden opgevraagd. 
Het thema Kennis werkt met Journalisten & Redacteuren:
* Journalisten: 
** nemen de moeite om het antwoord op een vraag te vinden
** delen deze informatie.
* Redacteuren:
** coördineren / stemmen de vragen op elkaar af
** bundelen antwoorden en geven bekendheid aan werk van Journalisten
==Trekker==
Naam 	Organisatie
Marcel van Mackelenbergh	Belastingdienst
==Redacteuren==
Naam 	Organisatie
Marcel van Mackelenbergh	Belastingdienst
Pieter van Everdingen 	OpenInc
==Journalisten==
==Activiteiten==
==Resultaten==
Op 12 maart 2014 is tijdens de 3e PiLOD bijeenkomst de nieuwe PiLOD Wiki gelanceerd, die op 16 maart in productie is gegaan. De volgende deliverables zijn beschikbaar om te gebruiken en om te raadplegen in de Wiki:
* pilod.nl (startpagina van deze Wiki)
* PiLOD Wiki ontwerpdocumentatie
* PiLOD Wiki gebruikersdocumentatie
==Referenties==
* Resultaat van de carrousel Thema Kennis
* Zie ook weblinks linked open data
Themas

==Thema A: Bestuurlijke verankering==
De case bestuurlijke verankering LOD richt zich op het opstellen van een kern boodschap aan bestuurders. Een toegankelijke beschrijving waarin het fenomeen LOD helder wordt gepositioneerd in het speelveld van (geo)informatieontwikkelingen, waarin de voordelen van Linked Open Data voor aanpalende (geo-)projecten worden beschreven en waarin aanbevelingen worden gegeven welke stappen aanpalende (geo-)projecten zouden moeten zetten om de voordelen van Linked Open Data te benutten.
==Thema B: Kennis==
Vanuit het thema Kennis proberen we niet alleen inzichten in LOD te verkrijgen maar proberen we daar zelf ook een LOD-toepassing van te maken middels een wiki. Aan de voorkant, voor de gebruiker, staan er nette webpagina's die de gebruiker kan lezen en wijzigen. Aan de achterkant, voor andere machines, kan de kennis als RDF / SPARQL worden opgevraagd.
Voor meer informatie zie ook de Thema Kennis detailpagina.
URI-Strategie voor de Basisregistraties

Categorie:URIStrategie
De werkgroep URI-Strategie voor de Basisregistraties is in 2015 overgegaan in de Werkgroep_URI-Strategie.
=Werkgroep URI-Strategie voor de Basisregistraties=
* Arjen Santema - Kadaster
* Linda van den Brink - Geonovum
* Hans Overbeek - KOOP
* Marco Brattinga - Ordina
* Jeroen Baltussen - Geonovum
* Martijn Odijk - Ministerie I&M BAG
* Janette Storm - Kadaster BAG
* Ine de Visser - Geonovum
* Marjan Bevelander - Ministerie I&M
=Doelstelling =
De Werkgroep URI-Strategie die in de context van het Platform Linked Data is opgericht stelt in overleg met een groot aantal betrokkenen een advies op voor de URI-Strategie voor de Basisregistraties. Het advies is gericht aan de Programmaraad Stelsel Basisregistraties die in november bijeen komt. 
=Waarom is een URI-Strategie nodig?=
De objecten in de basisregistraties zijn al voorzien van betrouwbare identificatie. Personen hebben een BSN nummer, panden hebben een BAG identificatie enzovoort. Het gaat hier echter om het toekennen van een vast adres op het internet voor elk object. 
Zo kun je dit adres als identificatie van het object gebruiken en op een duurzame manier naar het object linken. Zo’n link die als identificatie wordt gebruikt, wordt ook wel een URI genoemd (Uniform Resource Identifier). 
=De URI-Strategie is gericht op de basisregistraties=
Het advies beperkt zich tot de URI-strategie voor het stelsel van Basisregistraties. Een voorbeeld zou kunnen zijn: BAG.Overheid.nl/….. en BGT.Overheid.nl/… 
Op basis van dit model kan elke basisregistratie zelf aan de slag met de implementatie en het beheermodel. Afhankelijk van het gekozen model kan het nodig zijn om één partij aan te wijzen als beheerder van de domeinnamen, in dit geval dus van de 13 huidige basisregistraties. Dat kunnen er in de toekomst meer worden.
Lees het advies URI strategie basisregistraties (conceptversie) voor meer informatie:
*
Van Relationele Database naar Linked Data

Ikzelf (--Mackm02 (overleg) 27 jan 2014 09:56 (CET)) maar ook anderen hebben vaak data in een relationele database staan als vertrekpunt voor Linked Data. Vorig jaar maakten we Linked Data van een Relationele Database op de volgende manier --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET) wat je hier beschrijft is denk ik de werking van de D2R tool die RDB naar RDF omzet:
# de tabelnaam wordt het type (rdfs:type)
# de sleutel van de rij wordt het subject, (URI-)identifier van iedere (versie van iedere) instantie
# de kolomnaam wordt de predicate, (URI-)identifier van de eigenschap (het attribuut)
# de cel wordt heb object, een string met daarin de waarde, eventueel een foreign key (URI)
Dit geeft een resultaat dat niet erg bevredigend is:
* er ontstaan erg veel triples. Niet alleen wordt iedere cel een triple maar ook iedere relatie tussen twee tabellen vormt een triple. --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET) waarom is dat erg? performance problemen lossen zich wel op..
* veel velden zijn administratief: ze dienen voor het beheer van de data en bieden de meesten van ons weinig informatie --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET)precies! 
* relationele databases maken vaak een compleet nieuwe rij als er iets veranderd is in het object. Dit geeft veel redundantie en maakt het erg onoverzichtelijk als je daar rechtstreeks RDF van maakt --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET)ook dit gaat zich wel oplossen..soms wil je gewoon dat er een nieuw object ontstaat omdat er een nieuwe werkelijkheid is.. 
De discussie op afgelopen Conceptual Friday (24 januari 2014) gaf het volgende beeld:
# Tabellen van een relationele database moeten in elkaar geschoven worden, zodanig dat iedere tabel de objecten weergeeft die er toe doen volgens de gebruiker/business. Is het streven bij relationele databases om te normaliseren, het streven bij Linked Data is om te denormaliseren. Het verhaal achter de data moet weer te zien zijn in de data. --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET) je bedoelt dat je goed de betekenis van de data moet vastleggen denk ik? Mee eens!!
# De verschillende versies van een object horen thuis in het object. JSON-LD geeft hiervoor goede mogelijkheden vanwege haar opzet. --Bartvanleeuwen ik snap je enthousiasme over JSON-LD, maar in deze discussie is dat volkomen irrelevant, met TTL/N3/TRIG kan het net zo makkelijk, het is maar een serialisatie 
# Er zal behoefte zijn aan meerdere modelleringen van dezelfde data. --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET) ja inderdaad ..AAA principe ..Het verdient daarom aanbeveling om dezelfde ruwe data meerdere keren op te werken naar verschillende RDF-versies. --LiekeVerhelst (overleg) 27 jan 2014 19:31 (CET) of met meerdere semantische beschrijvingen die betekenisvol aan elkaar gelinkt zijn. Dit zou kunnen met Pig en Hadoop (Big Data). "all models are wrong but some are useful" De brandweer heeft de actuele stand nodig van de BAG maar fraudebestrijding bij Toezicht van de Belastingdienst wil graag ook de materiële geschiedenis hebben. Beide zijn niet geïnteresseerd in formele geschiedenis.
Versies van dingen in een dataset

== Het probleem ==
Datasets beschrijven vaak een bepaalde staat van de dingen waarover data zijn vastgelegd. Vaak stelt dit de huidige, of laatst bekende staat voor. Maar in werkelijkheid veranderen dingen: Dingen onstaan, ondergaan veranderingen en verdwijnen soms weer. Om de werkelijkheid goed te beschrijven moeten datasets dus een notie van geschiedenis hebben. Met andere woorden, de dingen die worden beschreven in een dataset kunnen versies hebben. De vraag is hoe dat het beste aangepakt kan worden bij publicatie van een dataset als vijfsterrendata.
== Vereisten van een oplossing ==
De volgende algemene (niet toepassingsspecifieke) eisen kunnen aan een oplossing worden gesteld:
# Het moet makkelijk zijn de laatst bekende staat van de data op te vragen;
# het moet mogelijk zijn om de staat van de data op een zeker tijdstip op te vragen;
# het moet mogelijk zijn een overzicht te krijgen van de veranderingen die de data hebben ondergaan tijdens een tijdinterval;
# het zou zo simpel mogelijk moeten zijn;
# het moet logisch zijn.
== Voorstel voor een oplossing ==
Hieronder wordt een simpel voorbeeld uitgewerkt in Turtle-notatie, om duidelijk te maken hoe versies van objecten kunnen worden gepubliceerd. Het voorbeeld gaat over een kerk die op 30 september 1929 in gebruik genomen is met de naam "OldName". Op 20 juni 1990 wordt de naam veranderd in "NewName".
 :c1 a ex:Church ;
 dcterms:title "NewName" ;
 dcterms:valid "start=1990-06-20;"
 dcterms:replaces <c1/version1> .
 
 <c1/version1> a ex:Church ;
 dcterms:title "OldName" ;
 dcterms:valid "start=1929-08-20; end=1990-06-19;"
 dcterms:isVersionOf :c1 ;
 dcterms:isReplacedBy :c1 .
Eigenschappen van de oplossing zijn:
# Elke verandering van een eigenschap van een object (of combinatie van veranderingen van eigenschappen op eenzelfde moment) heeft een nieuwe versie van het object tot gevolg.
# Er wordt gebruik gemaakt van algemene vocabularia: Dublin Core;
# De meest recente (huidige) versie heeft altijd dezelfde URI;
# Oudere versies zijn gekoppeld met de huidige versie (via dcterms:isVersionOf);
# Versies vormen een keten via dcterms:replaces en dcterms:isReplacedBy.
===problemen===
# Er wordt gebruik gemaakt van DCMI Period (http://dublincore.org/documents/dcmi-period/) om een tijdinterval aan te duiden. Dat is nodig omdat dcterms:valid als waarde een rdfs:Literal moet hebben. Maar het zou beter zijn als een tijdinterval als een complex object kan worden beschreven, dat gebruik maakt van algemenere datatypes als xsd:DateTime, xsd:gYear of xsd:integer. Met xsd:DateTime of xsd:integer (voor jaren) zouden de data bijvoorbeeld makkelijker in een SPARQL-query gefilterd kunnen worden.
# Wat nog ontbreekt is een manier om vast te leggen (in de metadata van de dataset) dat het om een dataset met objecten die versies kunnen hebben gaat. Als een gebruiker dat niet weet kunnen verkeerde conclusies worden getrokken. Wordt in het voorbeeld bijvoorbeeld gevraagd hoeveel kerken er zijn (instanties van ex:Church), dan is het antwoord 2. Maar de dataset bevat maar 1 courante kerk.
Vind linked data

Een actuele lijst met meer dan 200 actieve SPARQL endpoints is beschikbaar via de EU Knowledge Graph Query Service:
* SPARQL endpoints lijst
Deze lijst wordt regelmatig aangevuld met nieuwe SPARQL endpoints. Als er nog actieve SPARQL endpoints ontbreken op deze lijst dan kunnen deze als reactie op dit Twitter-bericht worden aangemeld. Meer informatie over SPARQL kan gevonden op de volgende SPARQL Wiki.
Binnen onze PLDN community zijn onder andere ook de volgende omgevingen interessant, omdat zij hun linked data ook op andere, meer laagdrempelige manieren beschikbaar maken, zoals via browse/search faciliteiten, API's of via GraphQL.
* Datasetregister voor alle erfgoeddatasets!
* Kadaster Labs (Developer resources)
En uiteraard kun je in onze eigen PLDN-experimenteeromgeving ook linked open data vinden, die je kunt gebruiken om mee te experimenteren en om nieuwe, rijkere linked data mee te maken en die je dan ook meteen in die omgeving kan publiceren.
* PLDN Experimenteeromgeving Triple Store
Virtuoso bulk loader

Categorie:Platform LOD
Deze procedure ontving ik (--Mackm02 (overleg) 25 feb 2014 17:48 (CET)) van Patrick van Kleef:
Ik stel voor dat je nog een test doet met de bulkloader feature. 
Deze zit in zowel versie 6 als 7 en is gemakkelijker dan via het web interface of via ttlp_mt.
Korte instructie:
1. compress alle bestanden in de delen directory. Dit is niet echt nodig, maar maakt het lezen nog iets sneller.
2. maak connectie met isql-vt tool naar database 
Edit [Gebruiker:Rvtveer]: 
Deze tool is op het Pilod-platform te vinden onder /opt/stores/virtuoso/bin/isql
en voer volgende commando uit:
ld_dir_all ('/pad/naar/delen', '*.gz', 'http://www.marcelvanmackelenbergh.nl/doorvoor');
 Indien data in verschillende graph namen ingelezen moeten worden, is het handig om files te splitsen in diverse subdirs en in iedere
 directory een bestand global.graph te leggen met de graph naam die voor al die bestanden gebruikt moet worden. Indien global.graph in
 subdir bestaat, overruled deze de graph naam die je hierboven hebt opgegeven.
3. controleer welke bestanden zullen worden ingelezen:
 select * from load_list;
 De kolom ll_state geeft aan of het bestand nog verwerkt moet worden (0), op dit moment wordt ingelezen (1) of klaar is (2).
4. run de bulk loader:
 rdf_loader_run();
 Aangezien de i7 processor meerdere threads tegelijk kan uitvoeren, kun je dit laatste commando nogmaals via een andere isql sessie opstarten,
 waardoor het lezen nog sneller gaat.
5. Als alle bestanden verwerkt zijn, kun je met het volgende commando kijken of er fouten tijdens het lezen zijn gevonden:
 select ll_file, ll_error from load_list where ll_error is not null;
Voorbeelden

SparQL endpoint:
https://api.data.pldn.nl/datasets/playalod/dieren/services/dieren/sparql
Voorbeeld SparQL query om blogs uit te lezen:
PREFIX a: <http://www.pilod.nl/wiki/Speciaal:URIResolver/>
PREFIX dct: <http://purl.org/dc/terms/>
select ?URI ?Samenvatting ?Publicatiedatum ?Blog ?Maker
where
{?URI a:Eigenschap-3AElementtype ?title. 
FILTER (regex(?title, "Blog")) .
OPTIONAL
{?URI a:Eigenschap-3APublicatiedatum ?Publicatiedatum . }
OPTIONAL
{?URI a:Eigenschap-3AKorte_samenvatting ?Samenvatting . }
OPTIONAL
{?URI a:Eigenschap-3ABlogtekst ?Blog . }
OPTIONAL
{?URI dct:creator ?Maker . }
}
Of het uitlezen van personen:
PREFIX a: <http://www.pilod.nl/wiki/Speciaal:URIResolver/> 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dct: <http://purl.org/dc/terms/>
select ?URI ?Voornaam ?Achternaam ?Email ?LinkedIn ?Beschrijving
where
{?URI a:Eigenschap-3AElementtype ?title. 
FILTER (regex(?title, "Persoon")) .
OPTIONAL
{?URI foaf:firstName ?Voornaam . }
OPTIONAL
{?URI foaf:lastName ?Achternaam . }
OPTIONAL
{?URI foaf:mbox ?Email . }
OPTIONAL
{?URI a:Eigenschap-3ALinkedIn ?LinkedIn . } 
OPTIONAL
{?URI dct:description ?Beschrijving . } 
}
Het opvragen van alle relaties van een pagina via SparQL
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?p ?o where { 
<http://www.pilod.nl/wiki/Speciaal:URIResolver/Jan_Willem_van_Veen> ?p ?o .
?p rdfs:label ?URI. 
}
VraagEnAntwoord

In het tweede PiLOD jaar hebben we onder andere een thema Kennis. Op deze plaats kun je je vraag kwijt. Het is zinvol als je bij je vraag ook je contactgegevens zet. Meestal heeft een vraag verduidelijking nodig. Ook willen we graag weten of je vraag beantwoord is.
* Wat is het voordeel van Linked Data?
** Het belangrijkste is dat we de dingen zelf gebruiken als bron voor informatie. Zie onder andere de uitzending van Tegenlicht (VPRO) waar de dingen zelf worden gebruikt als bron om informatie te verzamelen. Hier staat een kopie van deze uitzending.
VraagEnAntwoord 1

__NOTOC__
== Wat doe je met geometrie? ==
== Waar haal je een vocabulary vandaan? ==
== Kan je UML naar OWL/RDFs vertalen? ==
Kort antwoord op deze vraag is ja, het is mogelijk. 
Om de vraag nader te specificeren. In de geo wereld zijn veel informatiemodellen beschreven in UML. Door deze informatiemodellen om te zetten naar een OWL vocabulary kunnen ze gebruikt worden voor het publiceren van linked data. Hieronder ga ik de volgende vraag beantwoorden: Hoe maak ik van een UML Diagram in Enterprise Architect een vocabulary dat ik in Google Refine als vocabulary kan gebruiken? 
== Hoe regelen we de toegang en vertrouwen? ==
In een linked data omgeving voor de Nederlandse overheid zullen niet alle gegevens toegankelijk zijn voor iedereen. Hoe bouw je nu een linked data infrastructuur waar niet iedereen toegang heeft tot alles. In het architectuurplaatje van het semantic web is het in de vakjes Proof, Trust en Cryptography nog angstvallig leeg en.wikipedia.org/wiki/Semantic_Web. Hieronder vind je dus geen antwoorden, maar alleen maar meer vragen: 
*In de semantic web wereld kan je alle gegevens modeleren als subject predicaat object tripels. Kun je de hele het hele toegangsmechanisme modelleren als een ACL (Access Control List) op deze tripels?
Vragen

Er is binnen Platform Linked Data Nederland veel discussie geweest over het wel of niet toevoegen van forum-functionaliteit aan de Wiki, omdat we de discussies die op LinkedIn gevoerd worden soms moeilijk samen te vatten zijn in kennis die we met elkaar kunnen delen en omdat we toch graag een centrale bron willen hebben waar we vragen en antwoorden (Q&A) rondom Linked Data kunnen verzamelen en met elkaar kunnen delen.
Er is voor gekozen om deze forum-functionaliteit met standaard Wiki-functionaliteit te implementeren, zodat we geen versiebeheerproblematiek hebben vanuit de gebruikte Wiki tooling en extensies die je hievoor zou kunnen gebruiken. Op de hoofdpagina staan alle vragen overzichtelijk vermeld die verwijzen naar de detail-pagina's voor elke vraag waar de reacties en antwoorden gegeven kunnen worden op de vraag die van toepassing is.
Om vragen te kunnen stellen (en antwoorden te kunnen geven), moet je ingelogd zijn met je Wiki-account. Mocht je deze nog niet hebben dan kun je deze aanvragen bij een van de Wiki beheerders.
==Business vragen==
* Welke Linked Data business cases zijn bekend en beschreven?
* Welke werkprocessen worden bij Linked Data onderscheiden?
* Welke functies en rollen zijn bij Linked Data projecten belangrijk?
* Welke resultaten worden bij Linked Data projecten opgeleverd?
* Welke juridische aspecten kunnen een rol spelen bij Linked Data projecten?
* ...
==Technische vragen==
* Wanneer is semantiek wel of niet belangrijk bij een vraagstuk?
* Welke vocabulaires worden in Nederland het meest gebruikt?
* Waarom is een goede URI-strategie zo belangrijk bij Linked Data?
* ...
Wat we doen

Met het Platform Linked Data Nederland willen we de kennis over en het gebruik van linked data op een hoger niveau brengen. De levendige community gebruikt het platform om kennis te delen en toepassingsmogelijkheden te verkennen. Wij organiseren daarvoor bijeenkomsten, onderhouden deze website, geven publicaties uit en kunnen dankzij het netwerk ook toegang bieden tot een experimenteeromgeving.
==Bijeenkomsten==
Het Platform Linked Data Nederland organiseert verschillende bijeenkomsten:
* Grote bijeenkomsten - grote symposia waar presentaties gegeven worden over Linked Data of daaraan gerelateerde onderwerpen, met soms één of meer internationale sprekers. Deze bijeenkomsten kunnen 100+ bezoekers hebben en zijn vrij toegankelijk. Basiskennis over Linked Data is niet nodig. 
* Werksessies - kleine bijeenkomsten waar de nadruk ligt op het werken met Linked Data. De focus ligt op binnen het Platform Linked Data Nederland draaiende projecten. Deze bijeenkomsten hebben rond de 35 bezoekers. De beoogde bezoeker is iemand die al kennis over Linked Data heeft en actief met Linked Data bezig is, bijvoorbeeld in één van de draaiende projecten. Projectleden krijgen voorrang bij de aanmelding voor dit soort bijeenkomsten.
* Conceptual Fridays - kleine, informele bijeenkomsten bij Geonovum rondom een specifiek onderwerp of één van de projecten. Het maximum aantal bezoekers ligt rond de 15 personen.
* Handson-sessies - kleine bijeenkomsten met het karakter van een korte hands-on cursus. Deze sessies zijn bedoeld voor bezoekers met goede basiskennis van Linked Data. Het heeft de voorkeur om een laptop mee te nemen voor het uitvoeren van opdrachten of het samen werken aan een oplossing voor een probleem. Het maximaal aantal bezoekers ligt rond de 15 personen.
==Publicaties==
De kennis die we opbouwen in het netwerk, bundelen we met enige regelmaat in een publicatie. Deze publicaties zijn via deze website in te zien en te downloaden.
==Experimenteer==
Wilt u zelf aan de slag met linked data? Dan bent u hier op de juiste plek. Op deze website vindt u praktische tips, handige links naar bijvoorbeeld online trainingen en diverse publicaties. Zowel om linked data te maken als te gebruiken. Tevens kunt u gebruik maken van de experimenteeromgeving. Overigens maakt deze website zelf ook gebruik van linked data.
WaterML

category:case3
WaterML 2.0 is een OGC standaard. Uit de abstract: WaterML 2.0 is a standard information model for the representation of water observations data, with the intent of allowing the exchange of such data sets across information systems. 
Het is echter geen linked data vocabulaire maar een UML model met XML implementatie. 
http://www.opengeospatial.org/standards/waterml