Omschrijving brondocument te nauw

[keestrautwein]

De huidige beschrijving van de klasse Brondocument heeft een te beperkte toepassing. Deze constructie is niet uitsluitend bedoeld om naar een bron te verwijzen waarvan de betekenis van het begrip is afgeleid. Er kunnen allerlei redenen zijn om te verwijzen naar een document elders, die bijvoorbeeld in de uitleg property aangeven kunnen worden. Denk aan verwijzing naar regelgeving die niet de betekenis maar alleen de noodzaak van een begrip vastlegt of een verwijzing naar een bibliotheek waarin alle begrippen in een andere vorm voorkomen. Ook meer technische redenen (zie punt 1 en 3 hieronder) kunnen leiden tot een dergelijke constructie. Opvallend is dat we in de Best practise van Bronnen minder strikt lijken te zijn dan in de definitie.

Bij de besprekingen rond de constructie dat nu brondocument heet, heb ik opgepikt dat er een aantal doelen nagestreefd werden. De constructie is bedoeld om te kunnen verwijzen naar een bron elders. Een voorbeeld dat veel partijen herkenden was het verwijzen naar een IRI uit het LIDO, de Linked Data structuur van wetten.nl. We hebben een aantal eigenschappen vastgelegd waarvan we denken dat die een brede toepassing hebben en uitwisselbaar zijn, maar er kunnen eigen velden worden toegevoegd binnen een specifieke implementatie. Er waren een aantal doelen die we met deze constructie wilden bereiken:

1. Het is "goed practise" om direct te verwijzen naar externe bron als die een URI heeft. Maar de behoefte bestaat om binnen het begrippenkader extra informatie aan de verwijzing toe te voegen. Extra informatie kan een label zijn dat gebruikt wordt om de verwijzing mee weer te geven binnen het kader of binnen een applicatie die gebruik maakt van het kader. Ook een uitleg over de verwijzing hebben we gezien als informatie die vaak toegevoegd wordt. Een derde, praktische, reden kan zijn dat niet alle informatie altijd beschikbaar is bij de bron, waardoor het wordt "gecache-t" zodat een lokale applicatie de gegevens toch kan tonen.
2. We willen ook kunnen verwijzen naar bronnen die niet op het internet benaderbaar zijn. In dat geval is er geen URI beschikbaar. Denk bijvoorbeeld aan een rapport of ander document dat niet op het internet bestaat, maar alleen in de fysieke wereld. In dat geval is een omschrijving nodig of moet er gebruikt worden van een aanduiding uit een ander domein dan Linked Data, bijvoorbeeld een codering uit een bibliotheek in het attribuut citeertitel.
3. Als er verwezen wordt naar een bron, bijvoorbeeld met dct:source is er een praktisch probleem. De source mag zowel een string als een URI zijn die verwijst naar een bron op het internet. Het automatisch verwerken van een string heeft echter heel andere mogelijkheden dan het verwerken van een URI. In het geval de waarde een URI is dan willen we daar wellicht informatie ophalen of naar doorverwijzen. Een stringwaarde daarentegen is beperkt en hoofdzakelijk geschikt om door een mens gelezen en geïnterpreteerd te worden. Een automatisch systeem kan aan een string heel moeilijk informatie onttrekken. Een probleem is dat in zijn algemeenheid een automatisch systeem geen onderscheid te maken tussen een URI of een string. Dat maakt het verwerken van dergelijke verwijzingen programmatisch heel lastig. Dankzij de brondocument constructie is de eerste verwijzing naar een bron altijd een URI, namelijk een URI binnen het begrippenkader. Binnen deze bron wordt aangegeven of de bron waarnaar verwezen wordt een IRI is of iets anders. Deze extra informatie maakt de verwerking van de broninformatie praktisch uitvoerbaar.

Mijn voorstel is om in de beschrijving in §2.4 van Brondocument de bredere inzetbaarheid ervan te laten weergeven. Ook vind ik de naam "Brondocument" de functie niet goed weergeven. De verwijzing heeft geen "bron" van een begrip te zijn. Dat heeft binnen Stelselcatalogus al tot verwarring geleid.

[RiX012]

Dankzij de brondocument constructie is de eerste verwijzing naar een bron altijd een URI, namelijk een URI binnen het begrippenkader. Binnen deze bron wordt aangegeven of de bron waarnaar verwezen wordt een IRI is of iets anders. Deze extra informatie maakt de verwerking van de broninformatie praktisch uitvoerbaar.

Dit is inderdaad wel een goed idee.

Mijn voorstel is om in de beschrijving in §2.4 van Brondocument de bredere inzetbaarheid ervan te laten weergeven. Ook vind ik de naam "Brondocument" de functie niet goed weergeven. De verwijzing heeft geen "bron" van een begrip te zijn. Dat heeft binnen Stelselcatalogus al tot verwarring geleid.

Is het meer een isDerivedFrom dan?

[hoverbee]

Zullen we ook dit simpel houden? We hebben in eerste instantie meer aan een eenvoudige oplossing voor de meeste gevallen dan een complexe oplossing voor alle (dream on!) gevallen. Je kunt altijd uitbreiden als het standaard profiel niet voldoende is voor jouw use case. En als er brede behoefte blijkt te zijn aan iets ingewikkelds kunnen we dat in een toekomstige versie van het profiel opnemen.

[keestrautwein]

Even korte reactie op het bovenstaande. @hoverbee: De toepassingen hierboven beschreven zijn toch niet zo ver gezocht? En deze constructie is juist heel eenvoudig breed inzetbaar te maken. Technisch hoeft er niets aangepast te worden, alleen de begeleidende tekst.

@RiX012: Over de naam "Brondocument". De term is verwarrend, maar daar kan ik nog wel leven. Ik zou eerst willen voorstellen de tekst aan te passen:

"Een brondocument is een verwijzing naar een bron die relevant is voor een begrip. Het is een good practice om voor ieder begrip de bron waarop de definitie van het begrip is gebaseerd op te nemen. Brondocumenten verhogen de kwaliteit en de betrouwbaarheid van het begrip. Het gebruiken van de hieronder beschreven structuur wordt ten zeerste aanbevolen voor het beschrijven van bronnen en het relateren van begrippen aan bronnen."

Bovenstaande aanpassing heeft ook gevolgen voor de definitie van "brondocument", maar laten we eerst kijken of we deze aanpassing willen opnemen. Wel lijkt het handig om bij de taalbinding van brondocument iets te zeggen over de toepassing die ik hierboven punt 3 heb genoemd: Het creeëren van een URI om binnen het kader alle mogelijk brondocumenten te kunnen identificeren.

[architolk]

Er spelen hier voor mijn gevoel twee zaken:

1. De definitie van de relatie tussen begrip en "het-ding-dat-we-nu-brondocument-noemen". Hiervoor gebruik we nu de term "heeft bron" met de definitie "relateert een begrip aan een brondocument waarvan het is afgeleid." en de taalbinding naar dct:source. Dit lijkt me correct en ook de manier waarop we tegen het gebruik van deze relatie aankijken: we willen juist "bron" van de betekenis van het begrip op deze wijze duidelijk maken;
2. Of het terecht is dat we het object van bovengenoemde relatie typeren als "Brondocument". Ik denk zelf wel dat dit terecht is binnen de context die wij gebruiken. Immers: er is geen enkele andere relatie die we op dit moment gebruiken in onze beschrijving. Het is "dus" altijd een brondocument in onze context. Overigens vind ik het daarbij prima om de definitie te wijzigen zoals kees hierboven aangeeft, "relevant is voor" of "is bron voor" vind ik wel dicht genoeg bij elkaar.

Een mogelijke suggestie voor een alternatief is "Kennisbron". Deze term wordt bij de Belastingdienst gehanteerd en duid erop dat we een verwijzing maken naar "iets" dat een bron van kennis is. Ik denk dat dit altijd opgaat voor hetgeen we nu een "brondocument" noemen. Bovendien verschuift het de betekenis ook van "document" naar een iets breder ding (waardoor er ook meer dingen onder kunnen vallen die mensen wellicht niet direct met een "document" associeren).

[architolk]

Besluit: we nemen het voorstel van de definitie van Kees over. En we voegen een extra toelichting toe bij de eigenschap "heeft bron" waarin we aangeven dat deze eigenschap alleen bedoeld is voor bronnen die definieerd zijn voor het begrip, als je andere bronnen wilt relateren aan het begrip, dat je dan een andere/eigen eigenschap moet gebruiken.

[ArjenSantema]

verwerkt in versie ter vaststelling en akkoord