Unconference 9 februari 2017

Op donderdag 9 februari vond bij het Kadaster in Amsterdam de tweede PLDN Unconference plaats. Een groot aantal onderwerpen werd door de deelnemers ingebracht om te bespreken, waarna we bij elkaar horende onderwerpen gebundeld hebben in een aantal discussierondes (zie foto). In de nu volgende tekst is een samenvatting opgenomen van wat besproken is en welke actiepunten zijn afgesproken.

An English summary of this Unconference can be found here

Unconference Topics[bewerken]

DSC01204.JPG


W3C Working Groups Update[bewerken]

Bart: Netage en Taxonic zijn W3C lid en nemen deel aan de ontwikkeling van standaarden (of eigenlijk recommendations). Spatial data on the Web working group update doet Linda, SHACL zitten Netage en Taxonic in, daarnaast is er een community group over SKOS en OWL. Een community group maakt geen standaarden maar kan hier wel aanstichter van zijn.

SKOS en OWL Community Group[bewerken]

De SKOS en OWL community group is opgericht naar aanleiding van discussie op SDSVoc W3C workshop eind vorig jaar. Lieke is initiatiefnemer. SKOS is algemeen bruikbaar, terwijl je voor OWL wel een specifieke use case moet hebben. Deze groep is nog op zoek naar actieve deelnemers.

Spatial Data on The Web Working Group[bewerken]

Linda: geeft update over spatial data on the web working group. Deliverables: Best Practice, OWL time ontology, SSN ontology, en Coverages on the web. De werkgroep loopt tot juni 2017. Pano: is er al uitsluitsel over hoe je naar een CRS refereert vanuit een set coordinaten? Linda: Nee, dit komt in de Best Practice release van eind maart. Wouter: moet er bewijs van implementatie geleverd worden? Linda: voor de best practice niet, voor SSN en OWL time wel. Maar voor de best practice willen we wel graag voorbeelden uit de praktijk. Wouter: belooft met Pano te kijken waar kadaster voorbeelden zouden passen. Wouter: vraag over beginnen met SKOS en later toevoegen van OWL. Pano: je kan ook nog kijken naar meer hierarchische relaties zoals in skos-xl. Misschien moet je wel vanaf het begin goed nadenken over wt je precies nodig hebt.

Data Shapes Working Group[bewerken]

Nicky: zit in de data shapes werkgroep waar shacl gemaakt wordt. Shacl is bedoeld om constraints i.e. Regels over linked data vast te leggen. Dit ontbrak tot nu toe in RDF. Pano vult aan: de werkgroep draait al meer dan 2 jaar. Nicky: shacl is nog in draft fase maar je ziet het wel al behoorlijk veel gebruikt worden, dus er lijkt een grote behoefte te zijn. De werkgroep is nu bezig alle issues op te lossen. Vorige week is er een nieuwe working draft gepubliceerd. Pano: Het is de bedoeling dat dit de candidate recommendation wordt. Er is wel weerstand tegen, sommigen zijn uit de werkgroep gestapt in het verleden. Bart: Shacl is zo opgezet dat je elke shape kunt implementeren met SPARQL. Pano: Kadaster gebruikt shapes, je kan het gebruiken voor bv UI genereren. Triply gebruikt ook shacl oa voor faceted browsing. Nicky: voor de amerikaanse brandweerautoriteit incidentvormen als shacl shapes beschreven op basis van eerdere incidenten. Maar je kan ook bv ook de invoer in formulieren valideren ermee. Wouter: hoe groot is de kans dat er een de facto standaard ontstaat ipv een w3c standaard? Omdat w3c in dit geval achter loopt op bestaande implementaties. Bart: w3c maakt altijd standaarden op basis van member submission. Dat was hierbij ook zo. Ik verwacht dat het goed komt. Nicky: de laatste public draft bevat wel verschillen ten opzichte van bestaande implementaties. Bart: in w3c zie je nu veel dat recommendation tracks worden afgerond en dat daarna een community group ontstaat waarin over een volgende versie wordt nagedacht. Erwin: moet shacl op de pas toe leg uit lijst? Linda: te vroeg, het is nog geen standaard. Overigens, Data on the Web best practice is wel nu een recommendation en zou wel kandidaat kunnen zijn. Erwin: (schrijft dit op)

How-To Convert UML-Diagrams to Correct Semantic Models?[bewerken]

Context: Informatiemodellen van Geonovum zijn allemaal in UML (bijv. IM-GEO, IM Kabels en Leidingen), waar een norm voor is. Vraag naar data publiceren als Linked Data, maar dan is ook een definitie nodig en een richtlijnen over hoe je dat het beste kunt doen.

Issues bij Kadaster: Object-orientatie in modellen en normalisatie en denormalisatie praktijken in modellen, tijdaspecten in objecten die niet handig zijn, enumeraties, etc.

Kadaster voorbeelden:

  • Alles wat in de BAG staat is een BAG-object met een id en een status een met een begin en eind geldigheid, dus twee dimensies in 1 object, data en metadata, die bij Linked Data bij voorkeur los van elkaar worden gemodelleerd. Wil je dan alles gaan 'verdingen' en van alles classes maken?
  • Binnen bestemmingsplannen wordt veel referentie data gebruikt die je los wilt koppelen van objecten en waar je dan naar kunt refereren.


Ander voorbeeld:

  • ARENA project: INSPIRE voorbeelden Bart?


Probleem: Paradigma-wisseling, waarbij je het goed wilt afspreken voor de nieuwe Linked Data opzet en waarbij je een 'overgangsregeling' wilt afspreken vanuit de oude modellen die er zijn.

Wens: Best practice om modellen semantisch vast te kunnen leggen en on relaties tussen modellen vast te kunnen leggen, waarbij je rekening kunt houden met de relevante wettelijke kaders en waarbij dingen ook beter niet in de wet moeten worden vastgelegd vanuit BAG-ervaring.

Mogelijke oplossingen:

  • ISO-standaard voor conversie van UML naar OWL in de Geowereld, waar de nodige kritiek op is en wat dan de kwaliteit is van de OWL modellen die daarmee gemaakt worden.
  • Met shapes goverance apart vastleggen


Mogelijke vervolgstappen:

  • W3C community group om dit verder op te pakken en te harmoniseren met bijv. Michael Lutz
  • NEN 3610 als werkgroep oppakken met o.a Kadaster, Geonovum, ArchiXL, ... en een Conceptual Friday inplannen, waarbij deelnemers gericht uitgenodigd worden


Towards A Sound and Comprehensive RDF 2.0 Version?[bewerken]

Pieter: de huidige stack van standaarden kent problemen, er zou een RDF update moeten komen. Wouter: welke problemen? Pieter: we willen kunnen redeneren, maar er ontbreken wat relatietypen in de basis. Wouter: als je de entailment wilt uitbreiden denk ik eerder aan initiatieven buiten de RDF standaard om. Het is eerder SKOS en OWL. Pano: is het niet meer een performance probleem, theoretisch kun je wel veel inferencing doen maar in de praktijk is het onhaalbaar. Wouter: bijvoorbeeld de partOf relatie ontbreekt zie je in de praktijk. Maar je zou dat kunnen toevoegen in een eigen vocabulaire. OWL blokkeert dat niet. Bart: wat ontbreekt er dan in de basis? Heb je wel eens gekeken in de W3C RDF 1.1 archieven waarom bepaalde dingen niet opgenomen zijn. Pieter: dat is wel veel werk. Gerard: OWL is een consensus geweest, het is niet gelukt om alles er in te krijgen. Pieter: maar de relaties moeten allemaal een wiskundige onderbouwing hebben. Wouter: als die vervolgens in de praktijk gebruikt worden, is dat vaak met de verkeerde interpretatie. Bv owl:sameAs. Rdfs:sameAs zou misschien toegevoegd moeten worden als minder formele variant. Er is een voorstel hiervoor en nog een paar relaties van Jim Henson. Wouter: RDF wensenlijstje (over de basis)`: blank nodes afschaffen, in plaats daarvan wellknown URIs; literals ook op subject en predicate positie kunnen gebruiken (je kan dan nl over een string ook dingen gaan zeggen, wat handig is). Pano: is dat niet in conflict met je blank nodes wens? Wouter: ik denk het niet. In het ideale geval heeft alles een eigen url. Maar blank nodes afschaffen heeft hogere prioriteit. Bart: Reification mag er ook uit. Nicky: literals op subject positie kun hje ook anders oplossen (gemist wat de oplossing precies was) Wouter: dan trek ik mijn tweede wens terug. [onbekend]: voor mij zou het helpen als duidelijk is wanneer je RDF, SKOS of OWL gebruikt. Pieter: we moeten wel de mensen voor wie het nieuw is, helpen.

Need & Proper Usage of Indirect Identidiers (id & doc URI's)?[bewerken]

Linda; legt het indirect identifiers probleem uit. Wouter: het onderscheid is alleen belangrijk bij digitale dingen, niet bij fysieke dingen. Wouter: is er empirische informatie over wie nu wel of niet indirect identifiers gebruikt. Het meest gebruikte zou je het best in best practice kunnen zetten. Bart: dit speelt ook bij brandweerincidenten. Je kan het ook uitmodelleren waarbij je duidelijk maakt dat iets een beschrijving van iets anders is. Gerard: +1 zorg dat je model goed is en je die dingen scheidt van elkaar. Bart: incident is een gebeurtenis, die krijgt een id op het moment dat het gemeld wordt. De informatie over de reactie van de brandweer krijgt ook een id. Pano: je zou het onderscheid goed duidelijk willen maken zodat mensen niet meer in verwarring raken. Bv isdescribedby Linda: in de best practice is hiervoor nu een issue, wil wil kan daarop reageren in Github. https://github.com/w3c/sdw/issues/208 En zie ook http://w3c.github.io/sdw/bp/ sectie Status of this Document. Nicky: misschien is het probleem ook dat de id en doc uris te veel op elkaar lijken. Bart: misschien in de link header van http oplossen. Wouter: dat zou inderdaad wel uptake kunnen gebruiken want web developers gebruiken dit veel. HTTP RFC heeft hier geen mogelijkheid voor nu, maar je zou een keyword kunnen toevoegen en registreren bij IANA. Bart: misschien iets voor LDP next (de community group die vervolg is op linked data platform). Actie Bart dit oppakken.

How-To Query Geo Data with Acceptable Performance?[bewerken]

Wens: Naast 2D polygonen ook 3D data en tools om dat vast te kunnen leggen in Linked Data en te kunnen query-en met een aanvaardbare responsetijd (bijv. een containment vraag). Met Lucene en goede index strategieen kunnen op dit moment al redelijke resultaten bereikt worden. Inclusie-relatie wil je op functieniveau beschrijven. Commerciele implementaties bewegen nog te weinig in die richting, waarbij producten van bijv. Oracle en Stardog nog verder onderzocht moeten worden.

Vragen:

  • Wat maakt Geo data zo anders dat het niet goed performt?
  • Hoe zit GeoSPARQL in elkaar en zijn custom (user-defined) functies goed gedefinieerd?
  • Hoe wordt index aangesproken vanuit het graaf-paradigma?
  • Moeten we WKT uit elkaar trekken in triples of niet? (tripel explosie)
  • Bij Linked Data benchmark consortium neerleggen? (Geodata benchmarks bij LDMC, HOBBIT of een andere organisatie of project?)
  • Is dit wel haalbaar en realistisch vanuit de commerciele partijen die ermee bezig zijn (sommige van ons zijn positief hierover)?
  • Is er binnen H2020 een specifieke use case die om Geospatial queries vraagt? (naast bijv. de NWO, omgevingswet context)


Vervolgactie:

  • Binnen OGC bijeenkomst volgende maand dit onderwerp aankaarten (actie: Wouter)


How-To Make Linked Data Tooling More Sustainable?[bewerken]

Voorbeeld: LOD2/Linked Data stack, etc. 'beklijft' niet, is geen duurzame oplossingsrichting

Kanttekeningen: Stacks zijn vaak 'lomp', moeilijk te installeren (met of zonder Docker) en tools zijn soms nog onvolwassen en nadat een Europees project is gestopt zouden commerciele partijen de inzichten uit dat project verder moeten oppakken en dat gebeurt op kleine schaal (wereldwijd geen kritische massa en al helemaal niet binnen de community alleen).

Goede voorbeelden: De producten van Eccenca, de Semantic Web Company, LD-R, YASGUI en HDT, maar het kost heel veel inspanning om deze sustainable te maken. Het is dus wel haalbaar om kleine componenten duurzaam te maken, maar hele stacks zijn niet haalbaar en ontwikkelaars bouwen vaak ook sneller zelf een tool in elkaar (moeilijk te beteugelen tegenkracht). We zien wel dat commerciele partijen deze componenten omzetten naar Java om meer marktconform te kunnen zijn.

How-To Make Linked Data Publishing Less Challenging?[bewerken]

Willen wij het gebruik van validators om data kwaliteit en kwaliteit van API's te kunnen toetsen verder laten onderzoeken binnen een research project op een universiteit (voortbouwend op wat de LOD Laundromat kan op dataset niveau)?

How-To Organize Coordination & Trust in Collaboration Chains?[bewerken]

Vraagstelling: Hoe kunnen deel-economieen met elkaar samenwerken met behulp van DEMO (http://www.ee-institute.org/en/demo) en Linked Data toepassingen? Denkende vanuit het delen van Resources, Labor, Planning, Goals en Knowledge. We zien in de praktijk vooral uitdagingen op het gebied van het delen van Goals en Planning. En hoe gaan we van ruilwaarden naar gebruikswaarden?

Gerelateerde initiatieven:

  • het SOLID project, het gedistribueerde sociale web met o.a. Tim Berners-Lee (en het World Garden project uit 2005, met WebID o.b.v. FOAF waarbij je je identiteit kunt meenemen)
  • Crypto currency initiatieven
  • Data science initiatief binnen Jheronimus colllege (JADS): ZZie http://www.jads.nl/
  • Linked Data Blockchain / Hyperledger initiatieven


Knelpunten:

  • alle initiatieven zijn met name technisch georienteerd en hebben nog geen goede business case en incentive voor de eindgebruiker, de business case zit vooral binnen een centraal model (zoals Facebook)
  • Query-en over 1 centrale bron is veel makkelijker en is goed schaalbaar, terwijl het query-en over vele nodes vaak niet haalbaar is met de huidige technologie


How-To Develop More Data-Aware User Interfaces & Why?[bewerken]

Websites met ongestructureerde data, zoals Wikipedia, waarbij statische templates worden gebruikt om een website op te bouwen versus websites met gestructureerde data, zoals DBpedia, die slimmer gebruik zouden kunnen maken van de data die beschikbaar is, die de betekenis van de data begrijpen en de voorkeuren van de gebruiker (profile based) om web pagina's dynamisch te kunnen genereren.

Gerelateerde initiatieven en ideeen:

  • Web of intent
  • Intent uitdrukken door gebruik te maken van UI profiles en Schema.org
  • Yahoo initiatief van vele jaren geleden? (die hetzelfde heeft nagesteefd)
  • PoolParty presentatie (taxonomy driven UX van Andreas Blumauer)
  • Personalized learning (Elsevier education application for nurses)
  • LD-R, which is a 'toolkit' of web components using Linked Data


Knelpunten:

  • De graaf structureren in Linked Data moeten vertaald worden naar de standaard boomstructuren worden in UI's


Possible Synergies between Graph Data & Machine Learning?[bewerken]

Project van Netage: Met veel historische data, waarbij data shapes gemaakt zijn en machine learning is gebruikt om patronen en clusters te kunnen herkennen. Semantische en statistische verschillen in modellen, waarbij je semantiek en de relaties in de data zou willen gebruiken binnen een statistische context.

Vraagstellingen:

  • Hoe kun je Machine Learning beter maken door meer met semantiek te werken?
  • Hoe kun je Machine Learning gebruiken om Linked Data te maken?


Oplossingsrichtingen:

  • In Netage project: Wiskundig model gebruiken, waarbij de aanname is gedaan, dat semantiek in de data impliciet aanwezig is (een bepaald soort brand komt vrijwel altijd voor op een bepaalde soort locatie) en dus gebruikt kan worden om patronen en clusters te herkennen.
  • 2 a 3 onderzoeksrichtingen op universiteiten vanuit Linked Data (speerpunt binnen de VU, waarbij dit jaar het Maestro Graph project zal starten om symbolische en niet-symbolische systemen beter met elkaar te kunnen combinerenen, RDF2Vec is nog in het begin van zijn ontwikkeling)
  • 10 onderzoeksrichtingen vanuit Machine Learning


Maar waar gaan deze twee onderzoeksrichtingen elkaar vinden om betere oplossingen te maken.

How-To Use Text Mining to Discover The Semantics of Data?[bewerken]

Vraagstelling: Kun je definities van concepten die nog niet beschreven zijn uit teksten halen?

Gerelateerde initiatieven:

  • Wordnet
  • Concept.io


SKOS Taxonomies versus More Exact Knowledge Modelling?[bewerken]

Een heel exacte beschrijving is nodig van de data binnen elk kennisdomein, maar de data moet ook goed ontsluitbaar zijn. SKOS is vooral een thesaurus taal die zich goed leent voor ontsluiting van data, maar schiet tekort om van data heel exacte beschrijvingen te maken.

Gerelateerde initiatieven:

  • DBpedia werkgroep (verbeteren DBpedia ontology)
  • Kadaster projecten (UML modellen, SKOS- èn domeinmodelbeschrijving)


Oplossingsrichtingen:

  • Deelname aan SKOS vs OWL for interoperability community group vanuit DBpedia (Actie: Gerard)
  • Kadaster best practice delen binnen de PLDN community voor de Kadaster begrippen


How-To Deal with Conflicting Statements over Time in History?[bewerken]

Vraagstelling: Statements die op meerdere momenten anders kunnen zijn en die je wel wilt kunnen bevragen vanuit de historie van de data.

Oplossingsrichting:

  • Elke versie van een object is een Named Graph, maar het query-en daarover is lastig en hoe leg je de relaties tussen Named Graphs vast?
  • Memento i.c.m. LDF, op documentniveau, single source, terug in de tijd (geen endpoint)