Erfgoed en linked data en locatie

category:case3
== Intro ==
Als hoofdactiviteit in case 3 willen we een prototype opzetten met verschillende datasets die iets te maken hebben met erfgoed en / of met locatie. We besteden aandacht aan het opnemen van metadata voor deze datasets (DCAT, VoID). Gaandeweg doen we ervaring op met het publiceren van linked geodata en met LD vocabulaires voor locatie, in het bijzonder GeoSPARQL (inhoudelijk, technisch, en ondersteuning door tools). 
== Het prototype ==
We hebben een keuze gemaakt uit datasets die al als linked data beschikbaar zijn, of datasets waarvan de bronhouder zelf al de intentie en resources heeft om deze om te zetten naar linked data. Als linked data sets hebben we gekozen: 
* Archeologische monumentenbank RCE
* RCE beeldbank (foto's met geolocatie als linked data) - Rein is hier mee bezig
* Waternet peilbuisdata
Het prototype dat wordt gerealiseerd combineert archeologische monumentendata van de Rijksdienst Cultureel Erfgoed (RCE) met peilbuis-sensordata verkregen via Waternet. Wellicht wordt ook RCE beeldbank data gegeorefereerd (via BAG geocodeerservice) en meegenomen in dit prototype. We gaan kijken of we (al dan niet met federated queries) de data uit verschillende endpoints kunnen combineren en ontsluiten via een website. Door het combineren kun je dan de vraag beantwoorden welke archeologische monumenten bedreigd worden door wisselende grondwaterstanden.
Tussen de geo-datasets en erfgoed linked data worden mogelijk links aangebracht (geautomatiseerd, bijvoorbeeld op basis van locatie). Of zijn deze links niet nodig omdat de locatie-component met GeoSPARQL benut kan worden? Daar gaan we achterkomen. 
Hoe publiceren: 
* als meerdere SPARQL of GeoSPARQL endpoints
* als webinterface met kaart en met GeoJSON-LD
Een ambitie, die we op dit moment nog niet, maar later misschien wel realiseren is om de data niet te kopiëren in één end point maar juist op verschillende end points laten staan (of deze voor zover nodig inrichten) zodat we ervaring op kunnen doen met federated queries. Een meerwaarde van linked data is het niet meer hoeven kopiëren van elkaars data om slimme dingen te kunnen doen met combinaties van data. Het is nog wel de vraag of federated queries een goede optie zijn. Hoe verhoudt zich dit bijvoorbeeld met performance optimalisatie voor ruimtelijke vragen? 
Federated queries zijn mogelijk vanaf versie 1.1 van SPARQL, zie http://www.w3.org/TR/sparql11-federated-query/. Het maakt het mogelijk in een enkele query verschillende SPARQL-endpoints te bevragen. Dat is op zich al mooi, maar het zou helemaal een feest zijn als we bij dat soort gedistribueerde queries ook topologische relaties kunnen gebruiken, bijvoorbeeld de relaties die in GeoSPARQL zijn gedefinieerd. Dan zou je vragen kunnen stellen als "geef mij de locaties van alle bomen die op archeologische vindplaats X staan", als de bomendataset en de archeologiedataset verschillende SPARQL endpoints hebben. 
In de Erfgoed en Locatie pilot (externe pilot van stichting DEN) wordt al geëxperimenteerd met GeoSPARQL endpoints: http://erfgoedenlocatie.nl/2013/11/geosparql-demo-erfgoed-locatie/
==Werkzaamheden==
1a. Metadata beschrijvingen over de gehele sets maken (Rein, Han)
*	o.a. wie is eigenaar van de set, waar staat de set etc
*	archeologische monumenten
*	peilbuizen
 
1b. Vocabulaires onderzoeken
*	Twee redenen om een bekende sensor vocabulaire te gebruiken: omdat dan anderen het ook kunnen snappen, maar ook omdat je er dan mogelijk een reasoner over kan gebruiken. Zijn er ook domeinspecifieke reasoners voor?
*	zie demo “context-tooltje” van Thijs Brentjes
*	kijken naar vocabulaires die er al zijn mbt sensordata SNN, ...(Roel, Linda, Ann)
** SSN
** WaterML
** Data cube
*	geo vocabulaires (Linda, Rein, Thijs)
**	keuze maken (Geosparql, basicGeo, GeoJson, neogeo, ...)
 
1c. Strategie(n) onderzoeken tav (dynamische) grootschalige sensor data ontsluiting (Arnoud, Matthijs)
*	denk aan situatie waarbij alle peilbuizen in NL elk uur een stand doorgeven. Ergo: een immer groeiende set data
*	enkele mogelijkheden
**	alleen soort metadata (gemiddelden, laatste waarde) als LOD (en geen raw data)
**	volledige dataset (meta + sensor) als LOD -> alles “vertrippelen”
**	sensordata in “normale” database en achter een URI-proxy zetten
**	Json / Json-LD (zie demo Thijs Brentjes)
*	Alles kan, maar wat is handig (en in welke situatie)
 
2.a Onderzoek naar mogelijkheden/beperkingen bij keuze voor Pilod platform
*	Virtuoso 7.1 (is al geïnstalleerd, maar geeft nog wat issues)
*	of combi van Sesame en USeekM installeren (zoals ook door DEN is gebruikt)
 
2b. n-tripples maken voor alle peilbuizen in alle lagen (Arnoud iom Rein)
*	juiste formaat voor de coördinaten
*	hoe doen we de sensor data?
*	eerst even: laatste meting (tijdstip + waarde)
*	wat doen we met afgesloten buizen?
**	expliciet toevoegen van start en eind tijdstip aan de data
*	Toevoegen waterstandsverschillen (Rein, Arnoud)
**	hoe uitrekenen (ipv de random dummy)
**	welke eenheid (cm/jaar?)
**	alleen laatste waarde en/of ook per jaar
* URI strategie:
**	 wijzigen in: peilbuizen.pilod.nl (ipv peilbuizen.nl)
 
3. Gecombineerde queries/federated queries (case 3)
*	in 1 keer 1 query over verschillende end-points
*	dezelfde query achterelkaar/parallel over verschillende end-points en combineer resultaat
*	NB: moet SPARQL1.1 compliant zijn
 
4. Combinaties met andere datasets (indien makkelijk en tijd toestaat)
*	Beeldbank (bv. archeologische opgravingen / voorwerpen)
*	Zijn andere grondwaterstanden beschikbaar? Bijv. via DINO
*	Info over grondsamenstellingen
== Metadata en registers ==
Geo-data is goed voorzien van allerlei gestandaardiseerde metadata, bijvoorbeeld eigenaar van de dataset, creatiedatum, en gebruiksbeperkingen, maar ook nauwkeurigheid van coördinaten (ISO19115). Deze metadata wordt opgenomen in het Nationaal Georegister (NGR). Metadata is een belangrijk onderwerp, want het is nodig om datasets goed van metadata te voorzien zodat ze vindbaar zijn en mensen snel kunnen beoordelen of ze te gebruiken zijn en hoe. 
Voor Linked Data zijn er bijvoorbeeld de metadata vocabulaires VoID en DCAT. DCAT wordt gebruikt in data.overheid.nl. Onderzocht kan worden of deze bestaande vocabularia voor metadata geschikt zijn om geo-linked-datasets te metadateren, en of er misschien uitbreidingen voor nodig zijn.
Tijdens het inrichten van het prototype willen we ervaring opdoen met het metadateren van linked geo-datasets. Dit willen we doen door de voor het prototype geselecteerde erfgoed linked data sets te beschrijven met metadata. Hierbij wordt gebruik gemaakt van de in het NGR gehanteerde metadatastandaard en DCAT en VoID en deze worden vervolgens met elkaar vergeleken. 
Een mogelijke uitkomst zou kunnen zijn dat de metadata velden in NGR wat uitgebreid moeten worden om er ook linked data sets in op te kunnen nemen; maar ook bijvoorbeeld een keuze tussen DCAT en VoID, en uitbreiding hiervan om geo-aspecten van linked datasets te kunnen beschrijven. 
Onze ervaringen met metadata zouden we ook naar de internationale community kunnen rapporteren (nog niet bedacht waar dan).
== Locatie in RDF ==
Hoe neem je locatie-informatie (geometrie, coördinaten) het beste op in RDF? En welke toevoegingen aan Linked Data standaarden zijn er eventueel nodig voor het goed kunnen opnemen en benutten van locatie-informatie als linked data? Dit willen we door te werken aan en met het prototype ontdekken.
Voor het opnemen van geo-informatie in RDF bestaan verschillende vocabularia, zoals W3C Basic Geo, INSPIRE Core Location Vocabulary, NeoGEO, en OGC GeoSPARQL. Een inventarisatie en selecteren van een van de standaarden zijn nodig. Misschien zouden we ook aanbevelingen voor het verbeteren van deze standaarden kunnen doen.
Deze onderzoeksvraag valt voor een groot deel samen met de missie van de Geospatial Semantic Web Community Group van het W3C. Het is de intentie om onze bevindingen met die groep te delen.
Ook komen er wellicht wijzigingsvoorstellen voor de linked data standaarden van W3C en/of OGC hieruit voort.
== GeoSPARQL ==
Speciale aandacht voor deze standaard. Met behulp van het prototype kunnen we gaan ervaren hoe goed GeoSPARQL wordt ondersteund. We bedenken zoekvragen die door het combineren van de datasets van het prototype beantwoord kunnen worden en proberen die te antwoorden met GeoSPARQL. Op deze wijze doen we experimenteel kennis op over deze standaard, zowel inhoudelijk als technisch. 
Deze standaard uit 2012 is nog weinig toegepast. Het is interessant om hier ervaring mee op te doen. Is dit een standaard die waardevol is voor linked data toepassingen? Zijn er verbeteringen voor de standaard aan te dragen? (dit zou een wijzigingsvoorstel aan de OGC kunnen worden)
Kennis (inhoudelijke, technisch) over GeoSPARQL die we opdoen leggen we vast op deze wiki.
Een eerste aanzet voor de kennisvastlegging over GeoSPARQL staat op GeoSPARQL kennispagina.
== Beoogde resultaten ==
 
* Een prototype met geo linked data op het gebied van historisch erfgoed
* Antwoord op de vragen: 
** Hoe druk je metadata voor datasets uit in RDF en kun je hier ook geo-metadata in kwijt? 
** Hiermee samenhangend: nemen we LOGD datasets op in het NGR?
** Hoe neem je locatie op in RDF? 
*** Over dit onderwerp willen we onze ervaringen brengen naar de Geosemweb W3C community group
** Welke toevoeginen aan LD standaarden zijn nodig voor locatie?
** Hoe goed wordt GeoSPARQL ondersteund door GIS producten en door triple stores?
* Papers / artikelen
** GeoSPARQL kennisoverdracht op wiki
** Benodigde toevoegingen aan LD standaarden voor locatie - wordt ingediend voor Linking Geospatial Data workshop
* Wijzigingsvoorstellen standaarden (if any)
** SPARQL
** GeoSPARQL
Hier even geparkeerd: Een plaatje van Paul Hermans over het onderwerp 'vocabulaire voor historisch erfgoed en geo'.