uri strategie en vocabularyrichtlijnen versie 1.0

LinkedData@vlaanderen: uri strategie en vocabularyrichtlijnen versie 1.0

http://www.vlaanderen.be/opendata [email protected] Skype: opendataforum_ LinkedIn: Open Data Group

Inhoudsopgave 1/ Achtergrond ................................................................................................................................................................................................................................................ 3 2/ Taak 1: het toekennen van een HTTP identifier aan individuele entiteiten .......................................................................................................... 4 3/ Taak 2: het toekennen van een label ........................................................................................................................................................................................... 7 4/ Taak 3: het aanduiden van het type van het ding .............................................................................................................................................................. 8 5/ Taak 4: het beschrijven van het ding .......................................................................................................................................................................................... 10 5.1/ Aanbevolen vocabularia ..................................................................................................................................................................................................... 10 5.1.1/ Voor personen: FOAF ............................................................................................................................................................................................ 11 5.1.2/ Voor organisaties: ORG ...................................................................................................................................................................................... 13 5.1.3/ Voor contactinformatie: vCard ...................................................................................................................................................................... 14 5.1.4/ Voor het beschrijven van publieke diensten: Core Public Service ............................................................................................. 15 5.1.5/ Voor locatie: Basic Geo (WGS84 lat/long) Vocabulary ...................................................................................................................... 16 5.1.6/ Voor ruimtelijke objecten: GeoSparql ........................................................................................................................................................ 17 5.1.7/ Voor tijd: Time .......................................................................................................................................................................................................... 18 5.1.8/ Voor events: Event ................................................................................................................................................................................................. 19 5.1.9/ Voor statistische informatie (metingen, observaties): Data Cube ............................................................................................ 21 5.1.10/ Voor documenten, publicaties, informatie items: Dublin Core ................................................................................................. 22 5.1.11/ Voor begrippen in knowledge organisation systems: SKOS ......................................................................................................... 23 5.1.12/ Voor het beschrijven van RDF datasets: VoID ..................................................................................................................................... 24 5.1.13/ Voor het beschrijven van de herkomst van de data: PROV ........................................................................................................ 25 5.2/ Een eigen vocabularium maken (eigen klassen en properties) ................................................................................................................... 26 5.3/ Value vocabularies ................................................................................................................................................................................................................ 27 6/ Besluit ............................................................................................................................................................................................................................................................ 28

ACHTERGROND

LinkedData@vlaanderen: uri strategie en vocabulary richtlijnen 1.0

1

ACHTERGROND

Dit document situeert zich in het engagement om de data van de Vlaamse Overheid als Open Data te publiceren en dit met de hoogst mogelijke kwaliteit. Daarbij wordt dikwijls verwezen naar volgende sterren classificatie m.b.t. Open Data. Available on the web (whatever format) but with an open licence, to be Open Data Available as machine-readable structured data (e.g. excel instead of image scan of a table) as (2) plus non-proprietary format (e.g. CSV instead of excel) All the above plus, Use open standards from W3C (RDF and SPARQL) to identify things, so that people can point at your stuff All the above, plus: Link your data to other people’s data to provide context De conceptnota goedgekeurd door de Vlaamse Regering gaat uit van minimaal 3 sterren. Op termijn willen wij naar 4 en 5 sterren evolueren en onze data publiceren binnen het Linked Open Data Web. Dan moeten we voldoen aan volgende Linked Data principes: 1/Use URIs to name things; 2/Use HTTP URIs so that things can be referred to and looked up (“dereferenced”) by people and user agents; 3/When someone looks up a URI, provide useful information, using the open Web standards such as RDF, SPARQL; 4/Include links to other related things using their URIs when publishing on the Web. Dit betekent dat wij aan de entiteiten (scholen, hospitalen, departementen, gebouwen, …) waarvan wij de ‘authentieke’ data beheren en willen publiceren een URL moeten toekennen. De vraag stelt zich dan hoe we dit dan het best doen? Dit document biedt hiervoor een aantal patronen en richtlijnen. Uitgangspunt was om deze richtlijnen zo simpel en beperkt mogelijk te houden. Dit is een concrete uitwerking van de adviezen en mogelijke opties zoals die zijn gepresenteerd in het document “URI strategie data.vlaanderen” gemaakt in het kader van het LOD2 project door zijn Belgische partner Tenforce.

1/ Achtergrond

3


TAAK 1: HET TOEKENNEN VAN EEN HTTP IDENTIFIER AAN INDIVIDUELE ENTITEITEN 2

REGELS Regel 1: zorg ervoor dat de URI uniek is Regel 2: zo’n URL moet zo kort mogelijk zijn en eenvoudig te begrijpen voor zowel mens en machine. Regel 3: zo’n URL moet ontworpen zijn om ‘eeuwig’ mee te gaan. M.a.w. een identifier moet ‘blijvend’ zijn, ook wel ‘persistent’ genoemd. Dit betekent dat alles wat mogelijk variabel is uit de URL geweerd moet worden en dat een URL nooit verwijderd mag worden. Volgende aspecten nemen we dan beter niet op in de vorming van URL’s: de organisatie(naam) die de URL’s en bijhorende data publiceert merk-, product- of marketing namen status rol of functie Al deze aspecten zijn eerder tijdelijk en verhogen dus de kans dat URL’s moeten veranderen daarbij de ‘eeuwigheidswaarde’ ondermijnend.

STRUCTUUR VAN EEN URL De notatie die we hier hanteren is gebaseerd op de ‘URI template’ specificatie gedefinieerd in RFC6570 met een uitbreiding om repetitie van patronen aan te duiden. Een volledig patroon http://{domein}{/collection}*[{/type}{/key}]+[{/dateversion}]?#id Teken

Betekenis

?

0 of 1 keer voorkomend

*

0 of meerdere keren

+

1 of meerdere keren

[]

eenheid (horen samen)

{}

in te vullen onderdeel

TOELICHTING BIJ DE ONDERDELEN a) domein (verplicht) Domein is een internet DNS name. Regel: De entiteit die een domein gebruikt bij het samenstellen van een URL moet eigenaarschap en authoriteit hebben over dit domein.

Aanbeveling: Om het (sub)domein te laten beginnen met ‘data’ zodat het duidelijk is dat er data gepubliceerd worden in tegenstelling tot documenten.

Voorbeelden: data.vlaanderen.be data.toerismevlaanderen.be (ervan uitgaand dat dit domein persistent is) data.delijn.be (ervan uitgaand dat dit domein persistent is) Men kan indien nodig nog verder opsplitsen gebruik makend van subdomeinen.

2/ Taak 1: het toekennen van een HTTP identifier aan individuele entiteiten

4


Voorbeeld: toerisme.data.vlaanderen.be

b) collectie (optioneel) Een collectie dient om een verdere opdeling van het domein mogelijk te maken zonder daarom beroep te moeten doen op DNS instellingen. Voorbeelden: data.vlaanderen.be/toerisme data.vlaanderen.be/openbaar-transport Dit kan nog verder worden verfijnd indien nodig/handig. Maar hou rekening met de regel: korter is beter. Voorbeeld: data.vlaanderen.be/toerisme/dagtoerisme Collecties kunnen ook gebruikt worden om er zeker voor te zorgen dat de HTTP identifier uniek is.

Aanbeveling: met betrekking tot de vraag subdomeinen binnen data.vlaanderen.be of collecties. Als het om een op zichzelf staand zelfstandig domein gaat raden wij een subdomein aan; gaat het eerder om het verdelen van een domein dan gebruikt men beter collecties.

c) type en key in duo (verplicht) type geeft een hint voor mensen wat voor soort ding er beschreven wordt: een school, een hotel, een bushalte, …. Voorbeeld: data.vlaanderen.be/toerisme/logie key is dan de echte unieke sleutel die het ding krijgt in de dataset. Die key wordt meestal overgenomen van de natuurlijke key die er in de oorspronkelijke data zit of gevormd op basis van beschikbare velden. Voorbeelden: data.vlaanderen.be/toerisme/logie/LOVL123 data.vlaanderen.be/toerisme/logie/Adoma (gevaar: mogelijks niet uniek) data.vlaanderen.be/onderwijs/school/S100032 Dit patroon mag herhaald voorkomen indien er een duidelijke hiërarchie kan gebruikt worden om de ‘entiteit/ding’ te identificeren. Voorbeelden: data.vlaanderen.be/onderwijs/school/S100032/klas/6A data.vlaanderen.be/onderwijs/thesaurus/onderwijsniveaus/term/basisonderwijs

Aanbeveling: hoe de key samenstellen indien de bron geen echte identifier heeft maar enkel een textueel label of titel?

We gebruiken dan dat label of die titel, maar normalizeren de tekst: zet in lowercase haal alle karakters weg die speciale URL encoding nodig hebben (deze karakters vindt men op http://www.blooberry.com/indexdot/ html/topics/urlencoding.htm; enkele voorbeelden: $, &, +,<, {.). vervang spaties met een verbindingsstreepje


5


verifieer of het resultaat uniekheid garandeert (zo niet, voeg een context (collectie) toe in het pad).

Voorbeeld: data.vlaanderen.be/toerisme/logie/hotel-zonnestraal

d) datum of versie (optioneel en exceptioneel) Voor de meeste entiteiten is het zeker niet nodig om voor het geven van een identifier een tijdsindicatie mee te geven in de URI. Ik blijf ook gedurende gans mijn leven hetzelfde sociaal zekerheidsnummer behouden, al verander ik dagelijks. Maar klas 6A in school S100032 is wel elk jaar anders; dat kan en mag dan opgevangen worden door tijdsinformatie op te nemen in de URL. Aanbeveling: Voor het aanduiden van tijd in URL’s wordt het W3C Date Time formaat gebruikt. Wenst men een versie nummer te geven dan gebruikt men volgend patroon vX(.Y)? waarbij X een integer is en de major versie voorstelt en Y optioneel de minor versie. Voorbeelden: data.vlaanderen.be/onderwijs/school/S100032/klas/6A/2013-09 data.vlaanderen.be/software/linked-data-server/v2.4

e) #id Aanbeveling: We raden aan alle identifiers van dingen af te sluiten met #id. Daardoor is het voor de gebruiker duidelijk dat het een identifier is van een ‘ding’.

Op deze manier vermijden we het implementeren van een 303 ‘See Other’ redirect. Zie het Linked Data boek op http://linkeddatabook.com/editions/1.0/#htoc12. Wie wel 303 wil implementeren, mag dat natuurlijk. Dan bevelen wij volgend patroon aan: http://{domein}{/collection}*/id/[{/type}{/key}]+[{/dateversion}]? Wat dan leidt naar een 303 Location: http://{domein}{/collection}*/doc/[{/type}{/key}]+[{/dateversion}]?

f) Voorbeelden Aanbeveling: korter is beter, maar ook niet te kort zodat er geen ‘uniekheid’ meer gegarandeerd is.

Standaard toepasbaar in de meeste gevallen

http://{domein}{/type}{/key}#id

http://data.vlaanderen.be/logie/LOVL123#id http://toerisme.data.vlaanderen.be/logie/Adoma#id http://toerisme.data.vlaanderen.be/logie/LOVL123#id http://data.toerismevlaanderen.be/logie/LOVL123#id

http://{domein}{/collectie}*{/type}{/key}#id

http://data.vlaanderen.be/toerisme/logie/LOVL123#id http://data.vlaanderen.be/toerisme/logie/Adoma#id

Bij hiërarchische identificatie

http://{domein}[{/type}{/key}]+#id

http://data.vlaanderen.be/logie/LOVL123/kamer/12#id http://toerisme.data.vlaanderen.be/logie/Adoma/kamer/12#id http://toerisme.data.vlaanderen.be/logie/LOVL123/kamer/12#id http://data.toerismevlaanderen.be/logie/LOVL123/kamer/12#id

http://{domein}{/collectie}*[{/type}{/key}]+#id

http://data.vlaanderen.be/toerisme/logie/LOVL123/kamer/12#id http://data.vlaanderen.be/toerisme/logie/Adoma/kamer/12#id

Bij tijdsgebonden entiteiten http://{domein}{/collection}*[{/type}/{key}]+[{/dateversion}]?#id

http://data.vlaanderen.be/onderwijs/school/S100032/klas/6A/2013-09#id http://data.vlaanderen.be/school/S100032/klas/6A/2013-09#id http://onderwijs.data.vlaanderen.be/school/S100032/klas/6A/2013-09#id


6


3

TAAK 2: HET TOEKENNEN VAN EEN LABEL

Elk ‘ding’ moeten we een menselijk leesbaar label geven. Voorbeelden: ID

label

http://toerisme.data.vlaanderen.be/logie/Adoma#id

Hotel Adoma

http://data.vlaanderen.be/onderwijs/school/S100032#id

Sint-Lutgardisinstituut

http://onderwijs.data.vlaanderen.be/school/S100032/klas/6A/201309#id Sint-Lutgardisinstituut, klas 6A, schooljaar 2013-2014 Voor het toekennen van een label bestaat er een standaard: , afgekort rdfs:label We krijgen dan uitspraken die uit 3 delen bestaan (triples): Waarover gaat het (subject)

Welke property (predicate)

Met welke value

“Hotel Adoma”

Door het vastleggen van het prefix rdfs dat staat voor het URI deel kunnen we afkorten tot rdfs:label. Enkele voorbeelden: @prefix rdfs: . rdfs:label “Hotel Adoma”. rdfs:label “Sint-Lutgardisinstituut”. rdfs:label “Sint-Lutgardisinstituut, klas 6A, schooljaar 2013-2014”

3/ Taak 2: het toekennen van een label

7


TAAK 3: HET AANDUIDEN VAN HET TYPE VAN HET DING 4

Verder duid je best ondubbelzinnig aan om wat voor ‘type’ ding het gaat. Voorbeeld: http://toerisme.data.vlaanderen.be/logie/Adoma#id Dit is een hotel. Meer specifiek http://toerisme.data.vlaanderen.be/logie/Adoma#id is een instantie van de klasse hotel. Op het linked open data web wordt die klasse ‘hotel’ ook aangeduid met een HTTP identifier. Er zijn nu 2 mogelijkheden: ofwel gebruik je al een bestaande identifier ofwel definieer je zelf een klasse voor hotels. Best practice: kijk eerst of er al een klasse voor hotels beschikbaar is op het linked open data web. Een handig hulpmiddel hiervoor is de LOV website: http://lov.okfn.org/dataset/lov/index.html

Een zoekactie op hotel levert dan de volgende resultaten:

4/ Taak 3: het aanduiden van het type van het ding

8


Men krijgt een aantal zoekresultaten die verder onderzocht moeten worden of ze de behoeften afdekken. Eén van de resultaten is acco:Hotel, wat een afkorting is voor http://purl.org/acco/ns#Hotel. Hotel is een klasse gedefinieerd in het vocabularium met naam http://purl.org/acco/ns#. Daar vinden we volgende uitleg:

En hotel zelf is als volgt gedefinieerd:

Op basis hiervan kunnen we beslissen om deze klasse te gebruiken: ID

type

http://toerisme.data.vlaanderen.be/logie/Adoma#id

http://purl.org/acco/ns#Hotel

Voor het toekennen van een ding aan een klasse bestaat er een standaard: . We krijgen dan uitspraken die uit 3 delen bestaan (triples): Waarover gaat het (subject)

Welke property (predicate)

Met welke value

Door het vastleggen van het prefix ‘rdf’ dat staat voor het URI deel kunnen we afkorten tot rdf:type. We krijgen dan: @prefix rdf: . rdf:type . In het volgende deel beschrijven we vocabularia die veel voorkomende klassen beschrijven: Persoon, Organisatie, Event, ...

4/ Taak 3: het aanduiden van het type van het ding

9


5

TAAK 4: HET BESCHRIJVEN VAN HET DING

In onze back offices beheren wij de data van de entiteiten waar wij de authentieke bron van zijn. hun kenmerken (attributen), b.v. het aantal kamers van een hotel, het mailadres van een persoon. hun relaties, b.v. persoon ‘a’ werkt in departement ‘x’ en rapporteert aan persoon ‘b’. Belangrijk: In het linked open data verhaal moeten deze attributen en relaties ook een unieke http identifier krijgen. Dit om zo éénduidig mogelijk te zijn. Best practice: Maak gebruik van al bestaande vocabularia (klasses, attributen/relaties) om uw entiteiten te beschrijven. Een overzicht van bestaande vocabularia vindt men op: http://lov.okfn.org/dataset/lov/index.html. De hieronder beschreven lijst bestaat uit vocabularia die al veelvuldig gebruikt zijn en hun degelijkheid hebben bewezen.

5.1 AANBEVOLEN VOCABULARIA Voor het beschrijven van

Gebruik vocabularium

Personen

FOAF

Organisaties

ORG, ROV

Contactinformatie

vCARD

Services

Core Public Service

Locaties

Geo, GeoSparql

Tijd

Time

Events

Event

Statistische observaties/metingen

Data Cube

Documenten, publicaties, informatie assets

Dublin Core

Concepten/begrippen

SKOS

Datasets

VOID

Provenance

PROV

Zeer belangrijk: bij de beschrijving van een entiteit kan men properties uit verschillende vocabularia gebruiken; men hoeft zich dus niet te beperken tot één vocabularium.

5/ Taak 4: het beschrijven van het ding

10


5.1.1 VOOR PERSONEN: FOAF Voor het beschrijven van personen raden wij FOAF aan. Documentatie te vinden op: http://xmlns.com/foaf/spec/ Metadata van FOAF: http://lov.okfn.org/dataset/lov/details/vocabulary_foaf.html URL van het vocabularium: Deze URL leidt naar RDF en HTML representaties op basis van de http ACCEPT header. Schematisch:

Klasse Persoon:


11


Voorbeelden Beschrijving van Persoon 1 Daarbij maken we gebruik van volgende properties gedefinieerd door het foaf vocabularium (tussen haakjes ziet u de klasse) : family_name (Person), firstName (Person), gender (Agent), name, mbox=mailbox (Agent), workInfoHomepage (Person). Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

foaf:Person

rdfs:label

“Noël Van Herreweghe”

foaf:family_name

“Van Herreweghe”

foaf:firstName

“Noël”

foaf:gender

“male”

http://data.vlaanderen.be/persoon/A123#id>

foaf:name

“Noël Van Herreweghe”


foaf:mbox

<mailto:[email protected]>


foaf:workInfoHomepage

Waarover het gaat (ID)

Attribuut/relatie

waarde

rdf:type

foaf:Person

rdfs:label

“Mathias De Schrijver”

foaf:family_name

“De Schrijver”

foaf:firstName

“Mathias”

foaf:gender

“male”

http://data.vlaanderen.be/persoon/B345#id>

foaf:name

“Mathias De Schrijver”

http://data.vlaanderen.be/persoon/B345#id>

foaf:mbox

<mailto:[email protected]>

Beschrijving van Persoon 2

En bovendien kennen zij elkaar, gebruik makend van de relatie knows (Person): Waarover het gaat (ID)

Attribuut/relatie

waarde

foaf:knows

foaf:knows

Opmerking: Op europees niveau is er het Core Person Vocabulary ontwikkeld https://joinup.ec.europa.eu/asset/core_person/description. Maar zolang de in dit vocabularium gebruikte URL’s niet resolven (niks teruggeven) raden wij het gebruik ervan in een LOD context niet aan.


12


5.1.2 VOOR ORGANISATIES: ORG Voor het beschrijven van organisaties raden wij ORG aan. Documentatie: http://www.w3.org/TR/vocab-org/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_org.html URL: Deze URL leidt enkel naar een machine readable versie.

Klasse Organisatie:

Voorbeeld: In dit voorbeeld gebruiken we de properties subOrganizationOf, hasSite, hasPrimarySite uit het Organization vocabularium. Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

org:Organization

rdfs:label

“Studiedienst van de Vlaamse Regering”

org:subOrganizationOf

org:hasPrimarySite

org:hasSite

Opmerking: Er is een profiel van dit vocabularium gemaakt om legaal geregistreerde organisaties zoals bedrijven te beschrijven: Registered Organization Vocabulary. Documentatie te vinden op: http://www.w3.org/TR/vocab-regorg/ Metadata van ROV: http://lov.okfn.org/dataset/lov/details/vocabulary_rov.html URL van het vocabularium: De URL leidt enkel naar een niet machine readable versie. Dit vocabularium bevat syntax errors (invalid RDF) en kan dus niet gebruikt worden.


13


5.1.3 VOOR CONTACTINFORMATIE: VCARD Voor het vastleggen van contactinformatie van personen en organisaties het vCard vocabularium. Documentatie: http://www.w3.org/TR/vcard-rdf/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_vcard.html URL: Opgelet: er is een nieuwe versie van vCard in de maak; een aantal klassen en properties worden ‘deprecated’. Klasse Adres:

Voorbeeld: Om een adres te beschrijven gebruiken we volgende properties: streetAddress, postalCode, locality, country. Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

vc:Address

rdfs:label

“adres Boudewijngebouw”

vc:streetAddress

“Boudewijnlaan 30 bus 23”

vc:postalCode

“1000”

vc:locality

“Brussel”

vc:country

“België”

We kunnen dit adres dan gebruiken bij attribuut hasAddress van de hierboven al beschreven organisatie. Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

org:Organization

rdfs:label

“Studiedienst van de Vlaamse Regering”

vc:hasAddress

vc:email

“[email protected]”

vc:telephone

“02 553 52 07”

Opmerking: Op europees niveau is er het Core Location Vocabulary ontwikkeld https://joinup.ec.europa.eu/asset/core_location/description. Maar zolang de in dit vocabularium gebruikte URL’s niet resolven (niks teruggeven) raden wij het gebruik ervan in een LOD context niet aan.


14


5.1.4 VOOR HET BESCHRIJVEN VAN PUBLIEKE DIENSTEN: CORE PUBLIC SERVICE Voor het beschrijven van de diensten die de overheid/publieke sector biedt. Documentatie: https://joinup.ec.europa.eu/asset/core_public_service/description URL: De URL leidt enkel naar een machine readable versie.


attribuut/relatie

waarde

rdf:type

cpsv:PublicService

rdfs:label

“het afleveren van een stedenbouwkundige vergunning”


15


5.1.5 VOOR LOCATIE: BASIC GEO (WGS84 LAT/LONG) VOCABULARY Om een ruimtelijk object als punt geografisch te situeren. Documentatie: http://www.w3.org/2003/01/geo/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_geo.html URL: Deze URL leidt naar RDF en HTML representaties op basis van de http ACCEPT header. Voorbeeld: We gebruiken de properties lat en long om in dit geval een gebouw als geografisch punt te localiseren. Waarover het gaat (ID)

attribuut/relatie

waarde

http://data.vlaanderen.be/gebouw/Boudewijngebouw#id>

rdf:type

geo:SpatialThing

rdfs:label

“Boudewijngebouw”

geo:lat

“50.856776”

geo:long

“4.354802”


16


5.1.6 VOOR RUIMTELIJKE OBJECTEN: GEOSPARQL Documentatie: http://www.opengeospatial.org/standards/geosparql Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_gsp.html URL: De URL leidt enkel naar een machine readable versie. Klasse Spatial Object:

Voorbeeld: Het Boudewijngebouw heeft een geometry; meer specifiek een punt gedefinieerd in GML. Waarover het gaat (ID)

attribuut/relatie

waarde

http://data.vlaanderen.be/gebouw/Boudewijngebouw#id>

rdf:type

geo:Feature

rdfs:label

“Boudewijngebouw”

geo:hasGeometry

rdf:type

sf:Point

geo:asGML

“”” 4.354802, 50.856776 ”””^^geo:gmlLiteral


17


5.1.7 VOOR TIJD: TIME Voor het beschrijven van tijdsentiteiten, het Time vocabularium. Documentatie: http://www.w3.org/TR/owl-time/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_time.html URL: De URL leidt enkel naar een machine readable versie. Klasse ‘TemporalEntity’:

Voorbeeld: Voor het vastleggen van een tijdsinterval gebruiken we hasBeginning en hasEnd van het time vocab. Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

time:TemporalEntity

time:hasBeginning

time:hasEnd

time:inXSDDateTime

“2013-06-14T09:00:00”^^xsd:dateTime

time:inXSDDateTime


“2013-06-14T18:00:00”^^xsd:dateTime

18


5.1.8 VOOR EVENTS: EVENT Voor het beschrijven van events, de Event ontologie. Documentatie: http://motools.sourceforge.net/event/event.html Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_event.html URL: URL leidt naar RDF en HTML representaties op basis van de http accept header. Schematisch overzicht:

Klasse ‘Event’:

Voorbeeld: Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

event:Event

rdfs:label

“Open Data dag van de Vlaamse overheid 2013”

event:agent

event:place

event:time

time:hasBeginning

time:hasEnd


19



attribuut/relatie

time:inXSDDateTime

time:inXSDDateTime

waarde “2013-06-14T09:00:00”^^xsd:dateTime “2013-06-14T18:00:00”^^xsd:dateTime

Opmerking 1: Het herbruik van het Time vocabularium (cf. supra) zorgt voor indirectie. Dit betekent dat men eerst naar een instantie van time:TemporalEntity moet verwijzen alvorens men start en einde kan ingeven. Dit kan veel simpler en directer door dit mechanisme te vervangen met schema:startDate en schema:endData met ‘schema’ als prefix voor http://schema.org/. Dan krijgen we:

schema:startDate

“2013-06-14T09:00:00”^^xsd:dateTime

schema:endDate

“2013-06-14T18:00:00”^^xsd:dateTime

Opmerking 2: Er zijn nog 2 andere vocabs voor het beschrijven van events die goed bruikbaar zijn: lode Documentatie: http://linkedevents.org/ontology/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_lode.html URL: sem Documentatie: http://www.cs.vu.nl/~guus/papers/Hage11b.pdf Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_sem.html URL:


20


5.1.9 VOOR STATISTISCHE INFORMATIE (METINGEN, OBSERVATIES): DATA CUBE Voor het vastleggen van statistische observaties over verschillende dimensies, DataCube Documentatie: http://www.w3.org/TR/vocab-data-cube/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_qb.html URL: De URL leidt enkel naar een machine readable versie. Klasse ‘Observation’:

Een simpel en beperkt voorbeeld: De gebruikte prefixen: prefix qb: prefix eg: prefix sdmx-dimension: prefix sdmx-code: prefix sdmx-attribute: Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

qb:Observation

qb:dataSet

eg:refArea

eg:refPeriod

sdmx-dimension:sex

sdmx-code:sex-M

sdmx-attribute:unitMeasure

eg:lifeExpectancy

76.6

Opmerking: het data cube vocabularium is redelijk complex. Verwachting is dat er de volgende jaren tools zullen verschijnen die vertrekkend van een spreadsheet redelijk geautomatiseerd linked data volgens het data cube vocabularium kunnen genereren.


21


5.1.10 VOOR DOCUMENTEN, PUBLICATIES, INFORMATIE ITEMS: DUBLIN CORE Voor het beschrijven van informatie objecten: Dublin Core. Dit vocabularium is zeer generiek en wordt ook dikwijls gebruikt voor het beschrijven andere types van entiteiten. Documentatie: http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_dcterms.html URL: http://purl.org/dc/terms/ URL leidt naar RDF en HTML representaties op basis van de http accept header.


attribuut/relatie

rdf:type

waarde foaf:Document

rdfs:label

“Open data dag aankondiging”^^xsd:string

dcterms:title

14 Juni 2013: Open Data Dag in Vlaanderen!”^^xsd:string

dcterms:contributor

dcterms:creator

dcterms:date

“2013-05-05”^^xsd:date

dcterms:description

“Programma van de open data dag van de Vlaamse overheid in Brussel”^^xsd:string

dcterms:subject

Opmerking: Omdat het hier gaat om het toekennen van metadata aan een bestaande webpagina (een informatie object dat wel over het web kan verstuurd worden) gebruikt die zijn bestaand url-adres als identifier en hoeft de #id in dit geval dus niet. Er moet immers geen onderscheid gemaakt worden tussen het ding en het document dat het ding beschrijft.


22


5.1.11 VOOR BEGRIPPEN IN KNOWLEDGE ORGANISATION SYSTEMS: SKOS Voor het maken van thesauri, controlled vocabularies, … waarmee andere zaken, meestal informatie objecten, kunnen geclassificeerd worden. Documentatie: http://www.w3.org/2009/08/skos-reference/skos.html Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_skos.html URL: URL leidt naar RDF en HTML representaties op basis van de http accept header. Klasse ‘Concept’:

Voorbeeld: Voortwerkend op het dublin core voorbeeld (cf. supra) kunnen we nu met behulp van skos het subject van die pagina verder uitwerken. dcterms:subject ta#id> En verder uitwerken m.b.v. skos: Waarover het gaat (ID)

attribuut/relatie

waarde

rdf:type

skos:Concept

skos:prefLabel

“open data”@nl

skos:prefLabel

“data ouverts”@fr

skos:broader

skos:related


23


5.1.12 VOOR HET BESCHRIJVEN VAN RDF DATASETS: VOID VOID staat voor Vocabulary of Interlinked Datasets. Documentatie: http://www.w3.org/TR/void/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_void.html URL: Klasse ‘Dataset’:

Opmerking: Zo’n void file gaat men zelden handmatig editeren maar eerder automatisch genereren vanuit een database (triple store). Hieronder een voorbeeld van bij de Nederlandse overheid, in bestandsformaat turtle. a

void:Dataset , prov:Entity ;

rdfs:label “Stelselcatalogus dataset” ; dcterms:description “Begrippen en gegevenselementen zoals gebruikt door de basisregistraties” ; dcterms:title “Stelselcatalogus dataset” ; void:classes 6 ; void:dataDump ; void:distinctObjects 4297 ; void:distinctSubjects 1200 ; void:entities 1200 ; void:exampleResource , , , , ; void:feature , , ; void:properties 38 ; void:triples 17950 ; void:uriRegexPattern “^http://data\\.stelselvanbasisregistraties\\.nl/(.+)/id/(gegevenselement|concept|basisregistratie)/(.*)$” ; void:vocabulary void: , olca: , foaf: , skos: , dc: , , dcterms: , prov: ; prov:generatedAtTime “2013-08-23T17:46:16.015+02:00”^^xsd:dateTime ; prov:wasGeneratedBy


24


5.1.13 VOOR HET BESCHRIJVEN VAN DE HERKOMST VAN DE DATA: PROV Herkomst (‘provenance’ in het Engels) is de verzamelnaam om aan te duiden hoe data zijn aangemaakt (door wie, wanneer, met welke tools, …). Documentatie: http://www.w3.org/TR/prov-o/ Metadata: http://lov.okfn.org/dataset/lov/details/vocabulary_prov.html URL: Klasse ‘Activity’:


attribuut/relatie

waarde

rdf:type

prov:Entity

prov:wasAttributedTo

prov:wasGeneratedBy

rdf:type

prov:Create

prov:endedAtTime

“2013-05-03T08:53:00”^^xsd:dateTime

prov:wasAssociatedWith


25


5.2 EEN EIGEN VOCABULARIUM MAKEN (EIGEN KLASSEN EN PROPERTIES) Het is best mogelijk dat de bestaande vocabularia niet of niet helemaal of niet juist uw domein beschrijven. Dan is het natuurlijk mogelijk om zelf klassen en properties/relaties te gaan definiëren. Het gesuggereerde URI patroon hiervoor: http://{domein}{/collection}*/def#{key} waarbij key: de naam van de klasse is (UpperCamelCase) de naam van de property (lowerCamelCase)

Voorbeelden: URI Patroon

Voorbeeld

http://{domein}/def#{key}

http://toerisme.vlaanderen.be/def#Hotel http://toerisme.vlaanderen.be/def#aantalKamers

http://{domein}{/collection}*/def#{key}

http://data.vlaanderen.be/toerisme/def#Hotel http://data.vlaanderen.be/toerisme/def#aantalKamers

Voor hoe die klassen en properties verder moeten getypeerd en gespecifieerd worden verwijzen wij naar het boek “Semantic Web for the Working Ontologist” (http://workingontologist.org/).


26


5.3 VALUE VOCABULARIES We hebben tot nu toe aan entititeiten identifiers toegekend, hebben aangeduid tot welke klasse(n) zij horen en welke properties en relaties zij hebben. In bepaalde is het handig om gecontroleerde lijsten van toegelaten waarden te hebben om de waarde aan properties en relaties toe te kennen. Zo’n (controlled vocabularies) waardenlijstjes noemt men ‘value vocabularies’. Wij sommen hier een aantal herbruikbare value vocabularia op: Inhoud

Identifier

tijdsfrequenties

http://dublincore.org/groups/collections/frequency/2013-06-26/freq.rdf#

tijdsintervallen

http://reference.data.gov.uk/def/intervals

talen

http://publications.europa.eu/mdr/resource/authority/language/skos/languages-skos.rdf

filetypes

http://publications.europa.eu/mdr/resource/authority/file-type/skos/filetypes-skos.rdf

landen

http://publications.europa.eu/mdr/resource/authority/country/skos/countries-skos.rdf

currencies

http://publications.europa.eu/mdr/resource/authority/currency/skos/currencies-skos.rdf

Opmerking: de controlled vocabularies beheerd door het publications office van de Europese Unie komen pas in de loop van 2014 ter beschikking in de LOD cloud. Een voorbeeld: Voor het aanduiden van tijdsfrequenties kunnen we het volgend controlled vocabularium gebruiken http://dublincore.org/groups/collections/frequency/2013-06-26/freq.rdf#. Deze somt de voorziene en toegelaten waarden op: identifier

label

freq:annual

Annual

freq:biennial

Biennial

freq:bimonthly

Bimonthly

freq:biweekly

Biweekly

freq:continuous

Continuous

freq:daily

Daily

freq:irregular

Irregular

freq:monthly

Monthly

freq:quarterly

Quarterly

freq:semiannual

Semiannual

freq:semimonthly

Semimonthly

freq:semiweekly

Semiweekly

freq:threeTimesAMonth

Three times a month

freq:threeTimesAWeek

Three times a week

freq:threeTimesAYear

Three times a year

freq:triennial

Triennial

freq:weekly

Weekly

Dit wordt dan als volgt gebruikt b.v. bij de property accrualPeriodicity uit het Dublin Core vocabularium. Waarover het gaat (ID)

attribuut/relatie dct:accrualPeriodicity

waarde freq:quarterly

In 2014 voorziet de Open Data team van de Vlaamse Overheid heel wat eigen Vlaamse controlled vocabularia te publiceren (lijst van entiteiten, lijst van gebouwen, lijst van beleidsdomeinen, ….) met bijhorende reconciliatie service zodat het makkelijk is om op basis van een label de bijhorende identifier op te vragen. 5/ Taak 4: het beschrijven van het ding

27


6

BESLUIT

Om zo éénduidig mogelijk te zijn werken wij met identifiers, meer bepaald URL’s. Individuen krijgen zo’n identifier, maar ook de klassen waartoe zij behoren en de properties om hen te beschrijven. Dit document beschreef de richtlijnen voor het munten van deze URL’s voor die dingen waarvan wij zelf de (authentieke) bron zijn. Voor klassen en properties kan men de url’s gebruiken van al bestaande vocabularia, waarvan wij de meest gebruikte hebben aangehaald. Wil men zelf klassen en properties definiëren dan hebben we ook daarvoor een richtlijn aangehaald.

6/ Besluit

28

uri strategie en vocabularyrichtlijnen versie 1.0

Recommend Documents