nyuuzyou/wikis huggingface dataset:
Data cube

category:case3
http://www.epimorphics.com/web/projects/data-cube-vocabulary
"The data cube captures the notion of a data set comprising observations organized along one or more dimensions, where each observation includes one or more measures and the values of those measures are interpreted according to some attributes. For example a data set on population and demographics might have dimensions of time period, geographic region and sex, a measure of life expectancy and attributes defining the units, in this case years. The set of dimensions, attributes and measures is explicitly represented as a first class information object, the data structure definition that describes the cube. This in turn makes a data cube data set self-describing, enabling us to build tools that can automatically generate APIs and visualizations for a data set."
Data cube is volgens de beschrijving bedoeld voor statistische data maar klinkt toch alsof ook sensordata erin zou kunnen passen. Het is bijvoorbeeld toegepast in de bekende Bathing Water linked data pilot (http://www.epimorphics.com/web/projects/bathing-water-quality).
Dit artikel beschrijft hoe SSN en Data cube gecombineerd te gebruiken zijn: 
http://ceur-ws.org/Vol-904/paper10.pdf
De Miljoenennota met Linked Data – 10 maart 2022

Dit is de derde sessie in de maandelijkse reeks van PLDN sessies op de tweede donderdag van de maand om twee uur 's middags. Deze sessie wordt in samenwerking met het Ministerie van Financiën georganiseerd.
Datum: Donderdag 10 maart 2022
Tijd: 14:00-15:00 uur (online)
Video-opname: Link naar de opname
Slides: 
==Programma==
14:00	Introductie – Erwin Folmer (PLDN)
14:05	De Miljoenennota met Linked Data: De Datareis van Rijksfinanciën – Flores Bakker (Ministerie van Financien)
14:55	Afronding – Pieter van Everdingen (PLDN)
De iGO Knowledge Graph - Kadaster - 13 januari 2022

De naam zegt het al, de Integrale Gebruiksoplossing (iGO) maakt het mogelijk om data uit meerdere geobasisregistraties integraal te kunnen gebruiken. Het Kadaster Datascience team heeft het afgelopen jaar in opdracht van het programma DiS-Geo van BZK gewerkt aan de ontwikkeling van de iGO.
Datum: Donderdag 13 januari 2022
Tijd: 14:00-15:00 uur (online)
Presentatie: 
Video-opname: Link naar de opname
Tijdens deze demo sessie neemt het Kadaster Datascience Team je mee in het project. We staan stil bij de uitdagingen en gaan in op de gekozen architectuur bij de ontwikkeling van de iGO Knowledge Graph.
Neem alvast een kijkje op de publicatieomgeving om meer te weten over de iGO Knowledge Graph.
Details Linking Tools Silk and Limes presentation on june 20

The SIlk and Limes webinar will be held on June 20 2014.
Agenda:
*10.30 Presentation on Silk by Robert Isele (brox GmbH)
*10.50 Presentation on Limes by Axel Ngonga (University Leipzig)
*11.10 Q&A
*11.30 End
We will setup a beamer for a large audience, colocated with Conceptual Fridays.
Address: Barchman Wuytierslaan 10, 3818 LH, Amersfoort
To join to webinar go to the following link: https://www4.gotomeeting.com/register/926492055
==Silk==
The Silk Link Discovery Framework is a tool for discovering relationships between data items within different Linked Data sources.
The declarative Silk Link Specification Language (Silk-LSL) allows the user to specify identity resolution heuristics which define the conditions data items must fulfil in order to be interlinked. The LOD2 stack employs Silk to identify URIs which represent the same real-world entity.
Recording of a previous webinar on Silk: http://www.youtube.com/watch?v=CPl5eeyW-Xk
==LIMES==
Born from the wish to make linking tractable, the Link Discovery Framework for Metric Spaces (LIMES) is tailored towards the time-efficient and lossless discovery of links across knowledge bases. LIMES is an extensible declarative framework that encapsulates manifold algorithms dedicated to the processing of structured data of any sort. Built with extensibility and easy integration in mind, LIMES allows implementing applications that integrate, consume and/or generate Linked Data. Within LOD2, it will be used for discovering links between knowledge bases.
Recording of a previous webinar on Limes: http://www.youtube.com/watch?v=4XjVq1jOnI8
Details OntoWiki presentation on 9 may

Categorie:Platform LOD
The OntoWiki presentation will be held on may 9 2014.
Presenter: Sebastian (Tramp) from University of Leipzig
*Time: 
**10.00 am arrival & coffee
**10.30am to 12.00pm presentation
* Location: Ringwade 1, Nieuwegein (Ordina Office)
Questions as input for the presentation: OntoWiki questions
Please feel welcome to come to this presentation
Gerard Persoon
Details Poolparty on june 27

The Poolparty webinar will be held on June 27 2014.
Agenda:
*10.30 Presentation on Poolparty by Andreas Blumauer (productmanager at Semantic Web Company)
*11.45 End
We will setup a beamer for a large audience, colocated with Conceptual Fridays.
Address: Barchman Wuytierslaan 10, 3818 LH, Amersfoort
To join to webinar go to the following link: https://www4.gotomeeting.com/join/155236511
== Poolparty ==
PoolParty is a thesaurus management system and a SKOS editor including text analysis functionalities and Linked Data capabilities. 
The system helps to build and maintain multilingual thesauri providing a simple user interface and several semantic web services. 
Recording of a previous webinar on Poolparty: http://www.youtube.com/watch?v=L93af5zl8As
Slides on Poolparty: http://www.slideshare.net/lod2project/lod2-webinarpool-partyskosandlinkeddat2a-13491755
Details virtuoso webinar on 25 april

The Virtuoso webinar will be held on april 25 2014.
Presenter: Hugh Williams and Patrick van Kleef of Openlink Software
Time: 10.30am to 12.00pm CET
We will setup a beamer for a large audience, colocated with Conceptual Fridays.
Address: Barchman Wuytierslaan 10, 3818 LH, Amersfoort
To join to webinar go to the following link:
*https://www4.gotomeeting.com/register/952689183
Questions as input for the webinar: Virtuoso questions
Recording of a previous webinar on virtuoso: https://www.youtube.com/watch?v=MKs7QVi9ciE
Doorontwikkelen BAG showcase

Een belangrijke ambitie voor het onderwerp basisregistraties en semantiek voor de periode 2014/2015 is het doorontwikkelen van de showcase van de BAG op de volgende onderwerpen/deliverables:
* Toevoeging geometrie aan panden en verblijfsobjecten. 
* Koppeling semantiek aan core location (Locn) vocabulaire van Inspire en aan Vcard vocabulaire van de W3C en construeren van Vcard en Locn adressen in de linked data store. Daardoor kan bijvoorbeeld een app op basis van Vcard visitekaartgegevens combineren met adresinformatie uit de BAG, zonder de interne structuur van de BAG te hoeven kennen.
* Dagelijkse bijwerking linked data store. 
* Ondersteuning van queries via de browser. 
* Beschikbaar stelling van een (Geo)Json/LD api op de BAG voor bouwers van toepassingen zoals apps.
* Verbetering van het huidige webportaal, onder andere met een mogelijkheid van het tonen van adressen op een achtergrondkaart (OpenStreetmap).
* Verbindingen met andere Linked Data verzamelingen als Geonames en Dbpedia. 
‘The proof of the pudding is the eating’. Dat betekent dat de cirkel pas rond is als de ontwikkelaars community enthousiast wordt over deze vorm van publiceren van dat en ook daadwerkelijk wat gaat doen met deze data, dus toepassingen gaat bouwen. Een hackathon is een mogelijk middel om dit proces op gang te brengen.
Dutch Linked Data Sets

Categorie:Platform LOD
This is an overview of Dutch Linked Data sets
See also Rdfendpoints
==Dutch linked data sets - Production==
Dataset 	Contents 	Usage examples	Documentation via Parrot
data.stelselvanbasisregistraties.nl	Wiki 	
Kenteken
RDF
ttl
nt
JsonLD	Parrot stelselvanbasisregistraties
 	Bag by Geodan	
Bag
ttl
rdf 	Parrot bag
ELD uitdagingen 1

Categorie:EnterpriseLinkedData
Een van de geinteresseerden in Enterprise Linked Data loopt tegen de volgende uitdagingen aan in de praktijk:
* Inkomende en uitgaande berichten op koppelvlakken (een Enterprise Service Bus) omzetten naar triples is moeizaam,
** als je in de broncode geen domeinkennis wilt stoppen vanwege onderhoudbaarheid (bv. op een generieke manier vertalen van edifact naar triples)
** als je gegevens wilt synchroniseren naar clients (smartphones en tablets) want dat is per definitie zelfbouw
* We hebben 50.000 fatclients (business-logica in javascript runt in browser)
** hoe ga je stukjes van de massief samenhangende graaf aan de backend uitdelen aan de clients
** hoe ga je updates op deze stukjes terug synchroniseren naar de backend, en doorsturen naar andere clients indien relevant
** atomair, rol-back etc.
* Een rdf-store als ODS voor 15.000 concurrent gebruikers werkt technisch niet vanwege performance problemen
** indexering is niet te dimensioneren (execution paths worden niet geoptimaliseerd)
** open path-queries hebben te lange latency-tijden
** Sparql is geen handige taal om over een graaf 'te wandelen' als je het pad dat je bewandelen wilt niet van te voren weet.
Deze uitdagingen zijn kort besproken op de Conceptual Friday van 9 januari. 
LDP biedt een oplossing voor transacties met Linked Data en de W3C LDP Working Group werkt aan een verbeterde versie van LDP waarin ook authentication zit. Met de huidige versie van LDP moet je de beveiliging van data nog op HTTP-niveau regelen.
Indexering is nog lastig met Linked Data, maar grote partijen als IBM en Oracle werken gestaag aan verbeteringen op dit gebied.
Schaalbaarheid kan een issue zijn bij het werken met Linked Data. Er zijn verschillende manieren om dit op te lossen. Tussenstappen inbouwen in het proces, waarbij data geaggregeerd wordt in 'data containers' die beter te verwerken zijn in een volgende processtap (bijv. bij hele grote hoeveelheden sensordata). Partijen als Google en Facebook hebben dit opgelost door hun server park en hun data centers dubbel uit te voeren (meerdere data centers die kunnen bijspringen daar waar nodig).
In een volgende Conceptual Friday zouden wij deze uitdagingen nog meer in detail willen bespreken met een vertegenwoordiger van deze praktijkcase.
Endpoints & API's

Een van de vragen die je jezelf stelt als je Linked Data gaat gebruiken is of je toegang wilt hebben tot alle data van de databronnen die je wilt gebruiken of tot maar een deel van die data. In het eerste geval wil je dan graag toegang hebben tot de SPARQL endpoints waarin die data is opgeslagen, zodat je zelf kunt bepalen welk deel van de data je op wilt halen uit die endpoints en wilt gebruiken binnen toepassingen. Voor een overzicht van beschikbare endpoints, zie de Endpoints in Nederland lijst en het W3C overzicht. 
Echter om endpoints goed te kunnen gebruiken heb je kennis van SPARQL nodig. En in de praktijk blijkt, dat voor ontwikkelaars SPARQL soms te complex en te hoogdrempelig is. Zij geven de voorkeur aan het werken met API’s en met formaten zoals JSON. Om die reden zien we een aantal ontwikkelingen die het werken met Linked Data laagdrempeliger maken. Denk dan aan het werken met JSON-LD in combinatie met RESTful API’s. Dit is voor ontwikkelaars makkelijker om te gebruiken. 
Een nadeel van API’s is, dat je dan geen toegang hebt tot alle data van een databron. Bij API’s krijg je een deel van de data aangeboden conform de afspraken zoals deze binnen een API gedefinieerd zijn. Bekende voorbeelden zijn de Postcode API en de Kenteken API. Soms zal dit voldoende zijn voor het maken van een toepassing, maar in andere gevallen wil je juist wel toegang tot alle data. En het mooie van SPARQL is, dat je meerdere endpoints kunt bevragen in 1 query.
Belangrijk bij het maken en gebruiken van API’s is dat je gebruik maakt van open standaarden, zodat je niet afhankelijk bent van een leverancier. Het mooie is, dat er op dit moment een aantal goede ontwikkelingen gaande zijn, die het maken en gebruiken van Open API’s stimuleren en dat ook ondersteunen met tooling. Zo is het Open API Initiative (OAI) opgericht en is een tool als Swagger beschikbaar om open API’s mee te kunnen maken. En nog een goede ontwikkeling is dat deze tooling ook gebruikt binnen het Linked Data Theatre, een tool kit voor Linked Data.
En als laatste willen we de LOD Laundromat nog een keer noemen. De LOD Laundromat bevat alle Linked Open Data, zoals die op dit moment in de wereld beschikbaar is en dan gaat het om zeer grote aantallen triples (miljarden triples). De LOD Laundromat is dan ook een zeer goed startpunt om te bepalen of er al Linked Data beschikbaar is, die je vervolgens kan gebruiken in een of meer toepassingen.
Erfgoed & Linked Data + Lancering LD Wizard – 10 februari 2022

Dit is de tweede sessie in de maandelijkse reeks van PLDN sessies op de tweede donderdag van de maand om twee uur 's middags. Deze sessie wordt in samenwerking met Netwerk Digitaal Erfgoed (NDE) georganiseerd.
Datum: Donderdag 10 februari 2022
Tijd: 14:00-15:00 uur (online)
Video-opname: Link naar de opname
==Programma==
14:00	Introductie – Erwin Folmer (PLDN) ()
14:00	Linked Data in het Erfgoed domein – Enno Meijers (NDE) ()
14:30	De LD Wizard & PLDN community plannen:
* Erfgoed Wizard, praktijkvoorbeeld en demo - Ivo Zandhuis (NDE) (geen slides, zie demo in de video-opname)
* Geodata Wizard, extra functionaliteit - Erwin Folmer (PLDN) ()
* Lancering PLDN LD Wizard Werkgroep - Erwin Folmer (PLDN) ()
15:00	Afronding – Erwin
In het eerste deel van de sessie zal Enno Meijers (KB) ingaan op de rol van Linked Data in het Erfgoed domein. Sinds 2015 werken de cultureel erfgoedinstellingen in Nederland structureel samen om erfgoedinformatie beter houdbaar, bruikbaar en zichtbaar te maken voor iedereen. In samenwerking met het ministerie van OCW zijn de kaders voor de samenwerking vastgelegd in een Referentie Architectuur voor Digitaal Erfgoed (DERA). Hierin staat het standaardiseren bij de bron door middel van Linked Open Data centraal. Op basis van Linked Data technologie bouwt NDE aan een landelijke infrastructuur die de vindbaarheid van digitaal erfgoedinformatie moet vergroten. In deze sessie wordt een overzicht gegeven van de stappen die gezet zijn en de resultaten die tot nu toe bereikt zijn.
In het tweede deel van deze sessie zullen we de LD Wizard tool & community plannen lanceren binnen de PLDN-context.
Example Step 1: Select data

The first step is to identify and select the data to be published. 
Liander collects data on energy consumption and (local) production, e.g. through the use of energy meters. Liander would like to publish this data in order to:
*Be transparent as a public utility company
*Stimulate open innovation
*Gain insight into data needs
*Improve data quality by receiving feedback
The table below shows a snapshot of the raw metering data. It contains the electricity consumption at 15 minute intervals of a number of households with smart meters.
Bestand:LianderSnapshotStep1.PNG 
Although this data can be interesting for data consumers, e.g., to visualize energy consumption for individual households at different periods during a day, there are several issues with this data and publication will have to be restricted in a number of ways. 
Firstly, this data is subject to data protection laws. It is personal data and publication will violate the privacy of the households concerned. Therefore, it cannot be published as is.
Secondly, Liander is providing a commercial service based on this data to large energy consumers. Publishing the data as open data would cannibalize one of their own revenue streams. 
Thirdly, the quality of the data varies a lot. Households with smart meters may provide measurements at 15 minute intervals, but not all households have smart meters yet. In the worst case, for households without smart meters meter readings are only validated once every three years. And even for households with smart meters readings are sometimes received only once a quarter.
In order to deal with these issues, the data is restricted in the following ways:
*The data is anonymized. Rather than publishing the annual usage for each individual household, the annual usage is aggregated for all households in the geographical area determined by the 6-digit postcode. If there are less than ten households in one postcode, the annual usage of two or more consecutive postcode areas are aggregated.
*Commercially sensitive data is removed from the dataset, i.e., only energy usage of private households, the so called small users, is published.
*The data quality is standardized. Rather than publishing actual meter readings at regular intervals, Liander only publishes the estimated, standardized annual usage. This value is recalibrated once a quarter using recent readings, but will be published only once a year.
 Go back to example overview
Example Step 3: Model the data

In this step we create a vocabulary that describes the dataset. 
The starting point for this step is the documentation of the database. Part of the documentation is presented in the table below. This gives us an idea about the meaning of the data and is our starting point for a conceptual model of the data. 
Variabele/veld 	Mogelijke waarden 	Toelichting
[A.07] Postcode 	4 cijfers 2 letters	Twee kolommen: van en naar
[A.10] Straatnaam 	Naam 	Bij verschillende postcodes bij “van” en” naar”: de straatnaam van de eerste postcode
[A.11] Woonplaats 	Naam 	Naam van de woonplaats
[A.17] Productsoort 	ELK of GAS 	De energiesoort waarover het SJV gegeven wordt: ELK= elektriciteit, GAS = aardgas
Aantal aansluitingen 	getal 	Het aantal aansluitingen in het betreffende postcodegebied voor het betreffende product.
[A.33] SJV 	kWh of m3 	Gemiddeld Standaardjaarverbruik, waarbij voor aansluitingen met een normaal én laagtarief SJV het totale SJV wordt meegenomen in de middeling, zonder decimalen. Het standaardjaarverbruik is het verwachte jaarverbruik van een afnemer op een netaansluiting bij gestandaardiseerde condities en op basis van een genormaliseerd jaar.	Wanneer een aansluiting uit bedrijf is blijft het laatste SJV staan tot het moment waarop de aansluiting weer in bedrijf genomen wordt.
[A.34] SJV laag tarief 	% 	Percentage van de aansluitingen dat een laagtarief SJV heeft, oftewel een dag/nachttarief geactiveerd heeft.
[M.102] Type meter 	% 	Percentage slimme meters. Het betreft alle typen slimme meters, zowel de op afstand schakelbare als de niet op afstand schakelbare meters (resp codes DUS en DUN)
[M.115] Aantal telwielen	getal 	Gemiddeld aantal telwielen van de meters
We identify the following concepts:
*Usage Area: a geographical area defined by a range of consecutive postcodes in which energy is consumed and/or produced.
*Usage Point: a (possibly virtual) connection point at which energy is transferred from the network to and from (a set of) energy prosumer(s).
*Measurement: amount of energy consumption or production measured or predicted for a certain date/time interval in a certain unit of measure.
*Product Kind: kind of energy product being delivered and consumed at a certain usage point. Currently either electricity or gas.
The figure below shows how these concepts, their properties and relations could be modelled as an ontology. 
 
In this case we have opted to create our own basic ontology for this dataset. This has the advantage that it can be created to closely match the structure of the dataset, and that it does not require knowledge of other external ontologies (faster time to publication). The disadvantage is that the data is less accessible, because it is unlikely that data consumers will be familiar with this ontology. That is the reason why best practice prescribes to reuse existing vocabularies as much as possible to model your data. The nice thing about the Semantic Web, however, is that such links to other ontologies can always be added at a later stage as we will show later in Step 9 (linking the data). 
 Go back to example overview
Example Step 4: Define a naming scheme

In this step we define a scheme for assigning URIs to the dataset. We deviate slightly from the proposed Dutch national URI strategy. Our URIs have the following structure:
http://{domain}/{type}/{dataset|ontology}/{concept}/{reference}
where 
*{domain} should be an internet domain (URL) that the data owner controls where the data will be published and the URIs can be dereferenced. In this case, ‘data.liander.nl’ seems appropriate.
*{type} is either ‘id’ if the URI is an identifier of an object (individual/instance), ‘doc’ if it refers to the metadata about an object, or ‘def’ if it refers to the definition of a concept in an ontology. 
*{dataset|ontology} is either the short name of the dataset or of the ontology. In our case, we use the name ‘energy’ for both. We have made this addition for pragmatic reasons. We intend to publish this dataset alongside other datasets and ontologies on the same server. Therefore, we need a way to distinguish datasets and ontologies.
*{concept} is the name of the concept to which the object identified by the URI refers.
*{reference} should be a unique number or code identifying the object within the namespace. It can be a name or a number, as long as they are unique and not too long. For usage areas, we will use the concatenation of the starting and final postcodes as reference; for usage points, the postcodes followed by ‘E’ (for Electricity) or ‘G’ (for Gas); for Measurements, the date and the reference of the usage point.
Concepts in an ontology are referenced by their name. Therefore, the {reference} is left empty in this case. And rather than a ‘/’ the hash (#) is used to separate the {concept} from the rest of the URI. This is a best practice for naming ontology concepts that is supported by most ontology editors.
Following this scheme we get for example the following URIs:
*<http://data.liander.nl/def/energy> for the energy ontology.
*<http://data.liander.nl/def/energy#UsageArea> for the concept of Usage Area within the energy ontology.
*<http://data.liander.nl/id/energy/UsageArea/7231JS7231JT> for the Usage Area that starts at postcode 7231JS and ends at postcode 7231JT.
 Go back to example overview