Er is nogal wat verwarring over het verschil tussen OGC CSW, CSW ISO AP en INSPIRE Discovery Services en hoe al die verschillende standaarden op elkaar aansluiten. In dit blogbericht een poging om daarin wat duidelijkheid te scheppen. Voorlopig enkel de niet-transactionele operaties.
CSW staat voor “Catalogue Services for the Web” en slaat op de HTTP protocol binding implementatie van de OpenGIS Catalogue Services Specification. De standaard voor web-based catalogue services dus.
Tegen de CSW standaard kan je applicatie profielen schrijven. De “OpenGIS Catalogue Services Specification 2.0.2 – ISO Metadata Application Profile” [CSW ISO AP] is er daar één van. De INSPIRE Implementing Rules for Discovery Services is gebaseerd op [CSW ISO AP]. Dus in theorie heb je deze ketting:
INSPIRE Implementing Rules for Discovery Services
is conform aan
CSW ISO AP
gebruikt
CSW HTTP Protocol binding
is conform aan
Catalogue Services Specification algemeen model
In de praktijk zijn de INSPIRE Implementing Rules for Discovery Services niet volledig conform aan de [CSW ISO AP].
SOAP/KVP
INSPIRE verplicht het gebruik van SOAP Protocol bindings voor alle operaties. [CSW ISO AP] verplicht een mix van zowel SOAP als Key Value Pair (KVP) bindings. Voor de implementatie van de GetCapabilities request moet bv. verplicht KVP binding gebruikt worden. Ook de GetRecordById operatie moet naast SOAP als KVP geïmplementeerd worden (OGC 07-045 p.61). Volgens [CSW ISO AP] is het gebruik van de SOAP 1.2 standaard verplicht (OGC 07-045 p.60). INSPIRE kiest voor versie 1.1 van het SOAP protocol, tenminste zolang “WS-I Basic Profile 2.0” in draft is. Besluit: INSPIRE wijkt af van de standaard.
Queryables
Volgens [CSW ISO AP] zijn “Title”, “AnyText” en “Identifier” verplicht te implementeren elementen waarop gezocht kan worden (OGC 07-045 p.41). “Title” mapt op CI_Citation.title, “AnyText” is een full text enabled search in de metadata catalogus en “Identifier” mapt op MD_Metadata.fileIdentifier. In de INSPIRE Implementing Rule is er van deze queryables geen spoor. In het technische document staan ze wel opgelijst als niet verplicht te implementeren. Bizar, want full text search en zoeken op titel en id lijken mij toch belangrijke manieren om naar data te zoeken. Vandaar dat het AGIV deze methodes wel geïmplementeerd heeft in zijn Discovery service. AnyText zoekt in CI_Citation.title en MD_Identification.abstract. Besluit: INSPIRE wijkt af van de standaard.
Optionele en verplichte operaties
Volgens [CSW ISO AP] zijn er 4 verplichte operaties, nl. GetCapabilities, DescribeRecord, GetRecords en GetRecordById (OGC 07-045 p.33). Dit zijn allemaal niet-transactionele operaties. De transactionele operaties zijn optioneel. Voor INSPIRE volstaan 3 operaties. DescribeRecord ontbreekt. Voor de gemakkelijkheid heeft INSPIRE die operaties ook een andere naam gegeven, nl. GetDiscoveryServiceMetadata (GetCapabilities), DiscoverMetadata (GetRecords) en GetMetadata (GetRecordById). Besluit: INSPIRE wijkt af van de standaard.
GetDiscoveryServiceMetadata (of was het nu GetCapabilities?)
OGC gebruikt consequent de GetCapabilities operatie om de metadata van een service op te vragen, of dit nu CSW, WMS of WFS is. INSPIRE noemt deze operatie GetDiscoveryServiceMetadata. GetCapabilities heeft altijd één verplicht argument, nl. de naam van de service waarvan je metadata wil opvragen, vb. “CSW”. De GetDiscoveryServiceMetadata operatie heeft geen argumenten, wat logisch is, want de naam van de service zit in de naam van de operatie. Besluit: INSPIRE wijkt af van de standaard.
DiscoverMetadata (of was het nu GetRecords?)
INSPIRE gebruikt de DiscoverMetadata operatie, OGC gebruikt GetRecords. Daarnaast zegt OGC dat het gebruik van de ConstraintLanguageVersion verplicht is in de request message als je een de catalogus bevraagt via een query. Dit argument is niet opgenomen door INSPIRE. Ook hier hebben veel van de parameters een andere naam dan in [CSW ISO AP]. In de technische handleiding worden die dan wel gemapt op de OGC benamingen en in de SOAP berichten hebben ze ook de juiste naam, maar overzichtelijk en eenvoudig is het niet.
Helemaal onduidelijk wordt het wanneer de response message beschreven wordt in de Implementing Rule. Volgens INSPIRE moet het bericht drie elementen bevatten: RequestValidity, ResultCount en MetadataElementIDList. Dit slaat nergens op. RequestValidity mapt volgens het technische document op SearchStatus. Dan is het een timeStamp en geen boolean, zoals in de Implementing Rule vermeld staat. ResultCount is volgens de Implementing Rule “used to count the number of record position the catalogue should start generating output”. Heb je deze zin begrepen? Ik niet. De technische documentatie is duidelijker, die zegt dat het element mapt op numberOfRecordsMatched. Gelukkig vind je dit element terug in het XML-schema van het response SOAP bericht. Volgens dit schema ontbreken dan wel weer twee andere verplichte elementen in de Implementing Rule, nl. numberOfRecordsReturned en nextRecord. De beschrijving van het MetadataElementIDList element slaat alles. Volgens de Implementing Rule bevat dit element “the list of metadata(record) element identifiers”. Volgens het technische document echter komt dit overeen met resultSetId. Als dit zo is dan is het gewoon een id die door de server aan het resultaat toegekend wordt. Maar waar zitten dan de echte resultaten van de request? Gewoon een lijst met id’s terugsturen zoals gesuggereerd in de Implementing Rule, is misschien wel een goede oplossing, maar niet conform de OGC standaard. Die zegt dat als je in de request niet opgeeft op welke manier je resultaat wil, er een summary resultaat gegenereerd moet worden (de andere mogelijkheden zijn “brief” en “full”). AGIV heeft dit opgelost door titel en id van de metadatasets die voldoen aan de request op te nemen in de response, waardoor het bericht conform de minimum Dublin Core standaard is. Besluit: INSPIRE wijkt af van de standaard.
GetMetadata (of was het nu GetRecordById?)
GetMetadata volgens INSPIRE, GetRecordById volgens OGC. Hier zijn er wat onduidelijkheden tussen de Implementing Rule en het technische document, maar na wat gepuzzel is wel duidelijk wat er bedoeld wordt. Het enige probleem is hier dat als je volgens CSW ISO AP geen outputSchema parameter opgeeft de resultaten dan moeten voldoen aan het csw (Dublin Core) schema, wat uiteraard niet de bedoeling is van INSPIRE, want zij gebruiken de ISO19115 metadata standaard. Dus in principe is ook hier het besluit: INSPIRE wijkt af van de standaard.
Is dit nu erg?
Is het nu erg dat INSPIRE afwijkt van het CSW ISO Metadata Application Profile waar INSPIRE zich op baseert? Ja en nee. Ja omdat INSPIRE verwacht dat alle lidstaten de INSPIRE standaard volgen en implementeren terwijl zij zelf het niet altijd zo nauw nemen met de standaarden die INSPIRE eigenlijk zou moeten naleven. Bovendien is het niet altijd duidelijk waarom er van de standaard wordt afgeweken (vb. niet implementeren van verplichte operaties en argumenten of het wijzigen van naamgevingen). De standaard zou even goed werken als ze de standaard wel zouden volgen. Het is natuurlijk niet erg op Europees niveau. Indien alle lidstaten de INSPIRE standaard implementeren is er perfecte interoperabiliteit. Het zou alleen mooier zijn mocht INSPIRE ook op zijn beurt internationale standaarden volgen, of indien ze ervan afwijkt, argumenteren waarom dat gebeurt.
Zie [CSW ISO AP] (OGC 07-045) en de INSPIRE Implementing Rules for Discovery Services voor meer informatie