Publicatie:Verslag Expertmeeting Interoperabiliteit

Samenvatting

Referentie

Titel	Verslag Expertmeeting Interoperabiliteit (Voorkeurstitel)
Locatie	[ ]
Uitgever	PACKED vzw
Jaar van uitgave	2010
Rechten
Persistent ID

Trefwoorden

expertmeeting | interoperabiliteit |

Verslag

• Onderwerp: Verslag expertmeeting Interoperabiiteit
• Datum: 2010-06-03
• Locatie: FARO
• Aanwezig: Sam Coppens (IBBT), Chris De Loof (KMKG-MRAH), Patrick Hochstenbach (UGent), Jef Malliet (Erfgoedplus), Dries Moreels (BAM), Henk Vanstappen (CEST, verslag)
• Verontschuldigd: -

Inleiding

• Voorstelling van project CEST en de gehanteerde werkwijze. Deze expertmeeting kadert in een brede bevraging van de sector en verwerking van beschikbare expertise betreffende het hanteren van standaarden bij het uitvoeren van digitaliseringsprojecten.
• Opzet van de expertmeeting: er wordt commentaar gevraagd aan de hand van een aantal use cases, waarvan een ontwerpversie op de projectwiki is gepubliceerd. Er zal worden getracht rekening te houden met de gegeven beperkingen van het opzet, d.i. 'standaarden identificeren die essentieel of aangewezen zijn voor degelijk uitvoeren van een digitaliseringsproject'. Dit moet los worden gezien van verwante problemen en noden aan expertise (projectmatig uitvoeren van digitaliseringsprojecten, selecteren van geschikte software, correct toepassen van standaarden, ...)

Algemene opmerkingen

• De use case die centraal staat in deze expertmeeting is genaamd 'website', maar het onderwerp van deze meeting is breder, namelijk: hoe publiceer je data zodanig dat zowel mensen als machines er optimaal van gebruik kunnen maken. Dit heeft betrekking op een breed spectrum aan standaarden en normen: van gebruikte formaten, 'leesbaarheid' van de webpagina (ook voor blinden), tot het aanbieden van machineleesbare gegevens, die als (linked) open data worden beschikbaar gesteld (cf. semantisch web). Het is daarom beter deze twee invalshoeken uit te splitsen over even veel use cases: websites en open data.
• Hoe definieer je interoperabiliteit? [Interoperabiliteit betekent in het algemeen dat systemen (of apparatuur) in staat zijn tot onderlinge uitwisseling of/en communicatie. De systemen kunnen m.a.w. 'praten met elkaar' en zijn in zekere zin 'compatibel'. Om interoperabiliteit te bereiken zijn standaarden, protocollen en procedures erg belangrijk. Het is een geheel van standaarden en maatregelen. Zolang het geheel niet geregeld is, is er geen echte interoperabiliteit, en 'werkt' het niet.
• Bovendien is het erg belangrijk standaarden ook 'goed' te gebruiken. Te vaak nog wordt beweerd dat men een (beschrijvings-)standaard toepast, maar blijken de data in de praktijk sterk van die standaard af te wijken.
• Wat niet mag ontbreken in een tekst over open data en interoperabiliteit, is een vermelding van Tim-Berners Lee rule of 4:[1]
  • Use URIs as names for things.
  • Use HTTP URIs so that people can look up those names.
  • When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
  • Include links to other URIs so that they can discover more things.

Metadataschema's

• Interoperabiliteit wordt niet bepaald door 'een' schema systematisch toe te passen. Zo is het niet noodzakelijk het DC (XML) schema op te leggen, maar kan het wel zinvol zijn om schema's te gebruiken die dc-terms (2) gebruiken. Dublin Core geldt wel als aanbeveling.
• Zie ook opmerking m.b.t. ID's en ESE bij Identifiers. ESE zou daarom beter niet of onder voorbehoud vermeld worden
• Gegevens aanbieden in Dublin Core kan zinvol zijn, maar er moet ook gekeken worden naar bestaande application profiles [2]. Hieruit zou een minimale elementenset kunnen afgeleid worden. [3]

Woordenlijsten

• Voor uitwisselbaarheid van gegevens in de context van het semantisch web, zijn woordenlijsten uiterst belangrijk.
• Woordenlijsten moeten meer bieden dan het trefwoord zelf: ook scope note en biografische gegevens moeten aanwezig zijn.

Identifiers

• Essentieel is dat elk digitaal object (record, file, ...) een eigen identifier heeft. Een goed basis is om bij het creëren van een database elk onderdeel een uniek ID toe te kennen, dat een basis kan vormen voor een persistent identifier wanneer de data op het web gepubliceerd worden. Dit is overigens een manco in het Europeana ESE schema, waar een ID voor het object zelf en voor (digitale) derivaten wordt opgenomen in eenzelfde schema. Dit gaat ook in tegen de het 1-op-1-principe van Dublin Core [4].
• Welk systeem wordt gebruikt voor persistent identifiers is van minder belang: DOI, PURL, ARC, ... belangrijk is dat er wel 'iets' gebruikt wordt dat onafhankelijk is van de gebruikte software: de URI moet 'neutraal' of 'abstract' zijn, en ook na migratie naar een andere database, platform, ... nog werken.

Data beschikbaar stellen

• Als ideale dataformaat wordt (valide!) XML en RDF naar voor geschoven, maar het belangrijkste is dat data in machineleesbare vorm wordt aangeboden. Ook CSV is vaak voldoende om mee aan de slag te kunnen. Het heeft anderzijds weinig zin gegevenstabellen als HTML te presenteren: dit is immers niet machineleesbaar.
• Belangrijkste eis m.b.t. protocollen voor interoperabiliteit is dat ze HTTP/REST gebaseerd moeten zijn.
• OAI-PMH moet niet opgelegd of zelf aangeraden worden (zoals in Nederland gebeurt): in de praktijk zijn de implementaties beperkt.
• Een protocol als Z39.50 is zelfs af te raden omdat het niet HTTP-gebaseerd is.
• SRU kan dan weer wel, maar ook SRW is af te raden.
• WSDL of SOAP zijn eveneens minder geschikt.
• Een alternatief voor SRU is OpenSearch of SPARQL.
• Een alternatieve oplossing is het verrijken van webpagina's met gestructureerde gegevens, zoals RDFa of Microformats. Het is een eenvoudiger, maar voor veel organisaties beter haalbare methode dan bovengenoemde protocollen.
• Tenslotte verdient ook ATOM te worden vermeld als uitwisselingsstandaard.

Aandachtspunten voor websites

• De aanbeveling om javascript te vermijden moet geschrapt: javascript is bijna onvermijdelijk, en een erkende standaard.
• Verwijzen naar CreativeCommons-licentie is niet zinvol voor databases: op databases kan zo'n licentie niet toegepast worden. Een Standaard:CC is wel zinvol voor de (al dan niet via een database ontsloten) objecten. Minimum eis moet zijn dat rechten waaronder iets wordt beschikbaar gesteld, duidelijk moeten aangegeven worden, en dat er niets mag verspreid worden waarop de aanbieder (organisatie) geen rechten heeft.
• Er moet aandacht besteed worden aan een breed scala aan usability guidelines [5]: type en grootte van downloadbare files aangeven, letten op comptabiliteit met meest courante browsers, bij digitaliseren rekening houden met formaat van het scherm, ...
• Het is beter in algemene termen te verwijzen naar de aanbevolen formaten en codecs voor het aanbieden van video en geluidsbestanden op het web. Met name codecs evolueren zeer snel, en het is zeer lastig om er strakke aanbevelingen in te geven. Wel duidelijk is dat H.264 eerder te vermijden is, nu er toch licentiebeperkingen zijn opgedoken. Dit pleit eens te meer voor het hanteren van werkelijk open formaten. Wanneer proprietary formaten worden gebruikt (bv. voor het ter beschikkingstellen van downloadbare files), kan beter gebruik worden gemaakt van een niet te recente versie: dit verhoogt de kans dat het bestand voor meerdere gebruikers leesbaar zal zijn. Een voorbeeld is het aanbieden van .docx, dat door veel office-toepassingen nog niet herkend wordt - in tegenstelling tot het .doc-formaat van Microsoft (ook leesbaar in bv. OpenOffice). Hetzelfde geldt voor het aanbieden van spreadsheets: XLS kan, maar niet in de laatste versie.
• Het is een aanbeveling rekening te houden met HTML5. Ook voor HTML en HTML5 geldt dat dit vooral valide gecodeerd moet zijn. Testen is erg belangrijk. In dit verband kan de W3C html validator vermeld worden. Het wordt aangeraden 'betekenisvolle' tags te gebruiken (in tegenstelling tot de wildgroei aan DIV-tags). Combinatie XML / XSLT wordt in praktijk niet toegepast, is niet doorgebroken en mag als verouderd worden beschouwd. Ook XHTML is 'doodverklaard'. Tenslotte is het scheiden van inhoud en vorm is mooi principe, maar soms moeilijk hanteerbaar. CSS Stylesheets zijn daarom wel aan te bevelen, maar moeilijk afdwingbaar.
• UTF-8 is in de praktijk niet steeds haalbaar: beter is dit aan te bevelen in plaats van als minimum eis op te leggen.

Voetnoten

[1] Zie http://www.w3.org/DesignIssues/LinkedData.html
[2] Zie http://dublincore.org/usage/documents/profile-guidelines/
[3] Zie http://www.w3.org/TR/mediaont-10
[4] Zie http://dublincore.org/documents/dcmi-terms/
[5] Zie http://www.useit.com/alertbox/20030825.html