TOOI - De Xtrn-thesaurus 1.1.0

KOOP Standaard
Vastgestelde versie

Deze versie:
https://standaarden.overheid.nl/tooi/doc/def-st-tooi-thes-xtrn/-20240129
Laatst gepubliceerde versie:
https://standaarden.overheid.nl/tooi/doc/tooi-thes-xtrn/
Redacteur:
TOOI-beheerteam (KOOP)
Auteur:
Kennis- en Exploitatiecentrum voor Officiële Overheidspublicaties (KOOP)

Status van dit document

Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.

Samenvatting

Het doel van TOOI is het definiëren van een gemeenschappelijke taal waarmee data en metadata uitgedrukt kunnen worden, zodat overheidsinformatie beter vindbaar, toegankelijk, interoperabel en herbruikbaar wordt. TOOI-Xtrn (tooixtrn) gaat over file-types en talen en bevat hoofdzakelijk concepten die gemunt zijn in de Authority Tables (AT) van het Publication Office of the EU.

De familie van TOOI-documenten

Dit document maakt deel uit van de familie van TOOI-documenten die gepubliceerd wordt op standaarden.overheid.nl/tooi.

Documentatie

Dit document is gepubliceerd door KOOP, het Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. Zie het beheerplan voor nadere informatie.

Feedback is welkom

Indien u vragen heeft, of op- of aanmerkingen wilt maken op dit document, dan vindt u hier hoe u dat publiekelijk of anoniem kunt doen.

Alle commentaar is welkom.

1. TOOI-Xtrn

1.1 Inleiding, doelstelling, uitgangspunten

De thesaurus TOOI-Xtrn (tooixtrn) gaat over file-types en talen en bevat hoofdzakelijk concepten die gemunt zijn in de Authority Tables (AT) van het Publication Office of the European Union, zie [eu_authority_tables]]. Voor elke conceptsoort hebben we een apart conceptschema gemaakt in de tooixtrn-namespace:

Het is de bedoeling dat bij het metadateren van informatieobjecten volgens het TOOI-model deze concepten gebruikt worden als waarde van de properties dcterms:format, dcterms:language (en later wellicht dcterms:country). Ook genereren we waardelijsten voor diverse afnemers. Een derde doelstelling is om de concepten te gebruiken voor matching. Daartoe is specifieke informatie over de concepten beschikbaar (in dit geval in de vorm van waarden van de property skos:notation). Van matching is sprake als een inkomend, met metadata te verrijken informatieobject een string levert (bijvoorbeeld de string “PDF” of “EN”), op basis waarvan we in de thesaurus het van toepassing zijnde concept kunnen selecteren (in het voorbeeld dus file-type:PDF)

Het overnemen van de concepten uit de AT-tabellen in een eigen thesaurus met eigen conceptschema’s stoelt op praktische overwegingen. De AT-tabellen zijn talrijk, en elke afzonderlijke tabel bevat (veel) meer informatie dan nodig is voor het beoogde gebruik. TOOI-Extern is in deze context handzaam en overzichtelijk. Het is eenvoudig te gebruiken, simpel te queryen en licht van gewicht bij importeren (in de zin van owl:imports). Het bevat daarom een beperkte selectie van uitspraken (assertions, “triples”). De weggelaten informatie is uiteraard te allen tijde beschikbaar bij de bron.

We maken zoveel mogelijk gebruik van de bestaande concepten en van bestaande URIs, inclusief de AT-prefixen. Het is dus file-type:PDF en language:FRA, waarbij de prefix-definities overgenomen worden uit de AT-tabellen. In een aantal gevallen voegen we eigen concepten toe. Deze concepten hebben URIs in de tooixtrn-namespace. Een voorbeeld is tooixtrn:PAP-CW, het concept dat staat voor het Papiamentu, de officiële taal van Curaçau. Voor deze taal is geen concept gedefinieerd in de betreffende AT-tabel. De behoefte eigen concepten toe te kunnen voegen is ook de reden dat we kiezen voor eigen conceptschema’s. Het is in lijn met de good practices beschreven in [skos-primer] om extern gedefinieerde concepten toe te voegen aan eigen conceptschema’s.

Een tweede reden om eigen conceptschema’s te hanteren is dat we deze gebruiken in de generatie van schemagebaseerde waardelijsten.

In het hiernavolgende gaan we in op de belangrijkste ontwerpbesluiten. Vervolgens behandelen we elk van de conceptschema’s afzonderlijk.

1.2 Ontwerpbesluiten

1.2.1 Local names en namespace voor zelfgemunte concepten en conceptschema’s

De AT-tabellen hebben een aparte tabel (graaf) voor elke conceptsoort (talen, file-types, etcetera). Voor elke tabel is er dus een aparte baseURI. Daarbij heeft elke tabel ook een eigen namespace en namespaceprefix (language:, file-type:, country:). Dat is ook nodig om bijvoorbeeld het onderscheid te maken tussen language:NLD en country:NLD.

In tooixtrn hanteren we, zoals gezegd, eigen conceptschema’s, gedefinieerd in de tooixtrn-namespace: tooixtrn:taal, tooixtrn:file-type.

In een aantal gevallen definiëren we eigen concepten, namelijk voor zover deze niet beschikbaar zijn in de AT-tabellen. De URIs van deze concepten hebben dezelfde tooixtrn-namespace. Voor de local name volgen de we conventies van de AT-tabellen, gebaseerd op codes (bijvoorbeeld tooixtrn:PAP-CW).

1.2.2 Custom datatypes

Voor talen gebruikt de betreffende AT-lijst notaties met custom datatypes, zoals:

 language:FRA skos:notation "fre"^^euvoc:ISO_639_2B .

We nemen deze notaties over in tooixtrn, inclusief de custom datatypes. Aan de ene kant voorzien we op dit moment geen behoefte aan deze informatie — wat dat betreft zouden we de notaties ook kunnen overnemen in de vorm van xsd:string. Voor conformiteit aan de SKOS Reference maakt dat geen verschil. Aan de andere kant is het onnodig deze informatie weg te laten. De drie betreffende datatype-definities zijn overgenomen in tooiont, zodat het importeren van de brongraaf niet nodig is. Dit is besproken in de paragraaf over afhankelijkheden. Het gaat om de volgende resources:

  • euvoc:ISO_639_1
  • euvoc:ISO_639_2B
  • euvoc:ISO_639_3

Wel moet er rekening gehouden worden met de specifieke SPARQL-constructen die nodig zijn om te werken met custom datatypes. Dit is met name van belang als je (bijvoorbeeld in het proces verrijking) een inkomende string wil matchen aan een concept in de thesaurus. Gegeven de data hierboven geeft de “naïve” implementatie in [1] (waarbij de variabele ?input staat voor de stringwaarde in het brondocument) geen resultaat. Omdat de variabele ?input geen datatype heeft, matcht deze niet met de notatie van language:FRA. De query in [2] probeert de variabele te casten naar het juiste datatype maar is onwelgevormd: alleen (een subset van) de standaard datatypen hebben corresponderende XPATH-constructors in SPARQL 1.1.

De constructie in [3] geeft wél het gewenste resultaat (namelijk language:FRA), waarbij gebruik gemaakt wordt van de standaardfunctie STRDT. Op deze manier kan gericht gematcht worden op een specifiek datatype. Indien het datatype van de notatie niet uitmaakt en elke notatie die matcht een wenselijk resultaat geeft, dan is de vorm in [4] handig in gebruik.

  #### [1] geen resultaat
  SELECT ?c
      WHERE {
      BIND ( "fre" AS ?input )
      ?c a skos:Concept .
      ?c skos:notation ?input .
  }

  #### [2] onwelgevormd
  SELECT ?c
  WHERE {
      BIND ( "fre" AS ?input )
      BIND ( euvoc:ISO_639_2B(?input) AS ?input_c )
      ?c a skos:Concept .
      ?c skos:notation ?input_c .
  }

  #### [3] juiste oplossing, gegeven een specifiek datatype

  SELECT ?c
  WHERE {
      BIND ( "fre" AS ?input )
      BIND ( STRDT(?input, euvoc:ISO_639_2B) AS ?input_c )
      ?c a skos:Concept .
      ?c skos:notation ?input_c .
  }

  #### [4] juiste oplossing, datatype maakt niet uit

  SELECT ?c
  WHERE {
      BIND ( "fre" AS ?input )
      ?c a skos:Concept .
      ?c skos:notation ?n
      BIND ( xsd:string(?n) AS ?n_as_string )
      FILTER ( ?input = ?n_as_string )
  }

1.3 De conceptschema’s van tooixtrn

1.3.1 File-types

In het conceptschema tooixtrn:file-type brengen we alle formats onder die genoemd worden in de aansluitvoorwaarden voor PLOOI (zie [aansluitvw_plooi]) of de lijst DCAT AT DONL [dcat_ap_donl], aangevuld met een aantal formats die we in de praktijk al tegenkomen in contentstromen. De specifieke formats voor PLOOI en DONL zijn opgenomen in aparte collecties. Uiteraard kan een format in beide collecties opgenomen zijn.

Per concept worden de volgende elementen overgenomen uit AT als waarde van skos:notation in de vorm van string-literals:

  • at:op-code (MPEG4)
  • IANA mime type (audio/mp4, application/mp4, video/mp4)
  • file extension (mp4, mpeg, mpg)

Daarnaast worden overgenomen: skos:prefLabel, skos:definition.

In een aantal gevallen is er een mismatch tussen codes die gehanteerd worden in de aansluitvoorwaarden voor PLOOI en de systematiek die AT hanteert (conform IANA). Wij houden hier de AT-systematiek aan.

op-code in AT URI Notaties (niet-limitatief) Label in PLOOI
MPEG-4 file-type:MPEG4 MPEG-4, MPEG4, MPG, MP4, MPEG, audio/mp4, application/mp4, video/mp4 MPG, MP4
MPEG-2 file-type:MPEG2 MPEG-2, MPEG2, m2v, MPEG, MPG, MP3, MP2, audio/mpeg MP3
BWF file-type:BWF BWF, WAV, audio/vnd.wave WAV
JPEG file-type:JPEG JPEG, JPG, image/jpeg JPG

Het volgende is een voorbeeld van een formatbeschrijving in tooixtrn:

  file-type:ODT
    a skos:Concept ;
    skos:definition "ODT is the word processing file format of OpenDocument, an open standard for electronic documents."@en ;
    skos:inScheme tooixtrn:file-type ;
    skos:notation "ODT" ;
    skos:notation "application/vnd.oasis.opendocument.text" ;
    skos:notation "odt" ;
    skos:prefLabel "ODT"@en ;
    skos:scopeNote "aansluitvoorwaarden PLOOI" ;
    skos:scopeNote "DCAT AP DONL" ;
  .

1.3.2 Talen

In het conceptschema tooixtrn:taal nemen we 24 officiele EU-talen op zoals benoemd in [languages_eu], met de ISO-codes zoals benoemd in [languages_codes_eu]. We voegen daar nog aan toe de volgende in Nederland als officiële talen erkende isolecten:

  • Fries (met AT-URI language:FRY)
  • Papiamento, de variant van het Papiaments die gesproken wordt op Curaçao en Bonaire en die een van de officële talen is van de BES-eilanden (met de eigen gemunte URI tooixtrn:PAP-CW)
  • Papiamentu, de variant van het Papiaments die erkend wordt als officiële taal van Aruba (met de eigen gemunte URI tooixtrn:PAP-AW)

Papiamento en Papiamentu zijn officiële talen krachtens [stb_2010_717] en [AB2003_83]. Daarom moeten we deze kanoniek kunnen benoemen in de metadatabeschrijving van officële publicaties.

Deze isolecten zijn varianten van het Papiaments (ISO-639-3 PAP), de macrotaal die beide omvat. De varianten verschillen significant in spelling. Ook zijn er lexicale en idiomatische verschillen en is de uitspraak niet identiek.

Voor Papiamento en Papiamentu is geen ISO-code beschikbaar. Als taalcode gebruiken we de combinatie van de ISO-639-3-tabel en de regiocode volgens ISO3166-1. De notie taalcode, inclusief het gebruik van regiocodes daarbij, is gedefinieerd in [rfc5646] en [rfc4647]. Het is deze taalcode die we bij Papiamento en Papiamentu opnemen als waarde van skos:notation, met als datatype xsd:string. De preflabels zijn respectievelijk "Papiamento"@nl en "Papiamentu"@nl.

Ook language:PAP is opgenomen in tooixtrn, met ISO-639-3-code PAP. Dit om te voorkomen dat de behoefte kan ontstaan om “PAP” op te nemen als alternatieve notatie voor PAP-CW dan wel PAP-AW. Een relevante situatie is dat een bronhouder documenten levert die “PAP” als taalindicatie hebben. In dergelijke situaties zal het verrijkingsproces altijd moeten kiezen tussen tooixtrn:PAP-CW of tooixtrn:PAP-AW als output. Geen van de eilanden in de Cariben heeft language:PAP als officiële taal.

Opmerking. > In de EU geldt EST als de officiële code van het Estisch. In de ISO-639-tabellen wordt EST aangemerkt als macrotaal, en EKK als standaard Estisch. Het EU-standpunt is in tegenspraak met ISO-639. Een macrotaal is een verzamelbegrip voor een groep isolecten en heeft dus geen politieke of normatieve status. De spelling “skuur” is in het Algemeen Beschaafd Nederlands (de officiële, gestandaardiseerde taal van Nederland) in strijd met de norm en dus fout. In het Nederlands, opgevat als parapluterm voor in Nederland gesproken inheemse isolecten, is de spelling prima: in het Noord-Hollands wordt het zo uitgesproken en geschreven. Onder EST vallen bijvoorbeeld Keskmurre, Tartu, Mulgi, Võro en het Kirderanniku. EST kan volgens deze definitie dus niet gelden als een officiële taal: het is niet gestandaardiseerd en stelt geen norm. Deze conclusie wordt bevestigd door [glottolog_estonian]: > > Estonian, Standard (ekk-ekk) = 1 (National). Statutory national language (1992, Constitution, Article 52(1)).

In tooixtrn hanteren we de EU-conventies, dus EST en niet EKK.

De AT-tabel language: biedt maximaal vier codes per taal:

  • ISO-639-1, tweeletterige code (“fr”)
  • ISO-639-2B, drieletterige code op basis van Engels (“fre”)
  • ISO-639-2T, drieletterige code (“fra”)
  • ISO-639-3, drieletterige code (“fra”); dit is de enige code die voor álle talen in de tabel beschikbaar is

In alle meer dan 7000 gevallen is de ISO-639-2T-code of gelijk aan de ISO-639-3-code of niet gespecificeerd. In tooixtrn: nemen we daarom alleen de ISO-639-1-, de ISO-639-2B- en de ISO-639-3-code op. We doen dit op dezelfde manier als de AT-tabel: als een waarde van skos:notation in de vorm van een literal met een custom datatype, zoals euvoc:ISO_639_3. Zie de paragraaf in het voorafgaande over custom datatypes voor verdere details.

Het volgende is een voorbeeld van een taalbeschrijving in tooixtrn:

  language:FRA
    a skos:Concept ;
    skos:inScheme tooixtrn:taal ;
    skos:notation "fr"^^<http://publications.europa.eu/ontology/euvoc#ISO_639_1> ;
    skos:notation "fra"^^<http://publications.europa.eu/ontology/euvoc#ISO_639_3> ;
    skos:notation "fre"^^<http://publications.europa.eu/ontology/euvoc#ISO_639_2B> ;
    skos:prefLabel "Frans"@nl ;
    .
KOOP Standaard - Vastgestelde versie