Dieter en ik namen de INSPIRE Generic Conceptual Model spec en meer bepaald ANNEX H daarvan eens grondig door mbt het definitief afwerken vh datatype Identificator. Wij leerden hieruit het volgende:
INSPIRE spreekt van twee soorten identifiers, de UniqueObjectIdentifier of INSPIREid en de ThematicIdentifier. De INSPIREid is een id voor zgn spatial objects, niet voor de real world spatial things waarvan deze spatial objects de abstracties zijn. Voor de real world spatial things schrijft INSPIRE als id een ThematicIdentifier voor, voor de spatial object dat ermee overeenstemt een INSPIREID (figuur p146):
Concreet wil de INSPIREid spatial objects identificeren, geen spatial things. Of kort door de bocht: de INSPIREid is een identifier voor polygonen, niet voor wat die polygonen precies voorstellen, daarvoor dient de ThematicIdentifer. Het argument dat je hiervan abstractie kan maken door INSPIRE:Identifier:localid gelijk te stellen aan de ThematicIdentifier:Identifier spreekt de spec zelf tegen: “Since the same real world phenomenon may be represented by multiple spatial objects, the thematic identifier cannot in general be used as an identifier for spatial objects, even though the object may truly represent some ‘thing’ in the real world. The spatial object will often include the thematic identifier as an attribute.” (p141-142).
Merk op dat gans deze redenering ook uitgaat van spatial things, ttz “anything with spatial extent, i.e. size, shape, or position” (p13) en dat kan vanalles zijn “people, places, bowling balls, as well as abstract areas like cubes”. Maar dus geen Organisaties, Dienstverlening enzo tenzij iemand weet hoe je de afmetingen ve Dienstverlening bepaalt?
Bijzonder ook aan het INSPIREid is het Namespace veld. Om dubbele waarden te vermijden vd INSPIRE:Identifier:localid hebben we een discriminerend veld nodig met inherent wat info over wie (land & organisatie) het id heeft uitgegeven voor welk doel (product). Die namespace moest bij INSPIRE centraal geregistreerd worden. Echter onderkent INSPIRE nu dat met de komst van URI’s die noodzaak wegvalt:” A need for a central INSPIRE registry for identifier namespaces would therefore no longer be required and the URI approach would encourage greater interoperability” (p142).
Opvallend daarbij blijft ook in dat geval het onderscheid dat INSPIRE zo graag wil maken tussen things en objects. Ipv /id als type of resource, suggereert INSPIRE om /so te gebruiken in de URI. Je ziet dit ook in bovenstaand voorbeeld met het kadastraal perceel.
Het INSPIREid voorziet ook nog een version attribuut in de INSPIREid. Dit is semantisch niet volledig correct aangezien het niet de versie vd Identifier betreft maar vh object waarnaar de identifier verwijst, dat zegt de spec eigenlijk ook zelf “The version identifier is not part of the unique identifier of a spatial object.” (p96). Hoewel in theorie unieke versieid’s mogelijk zijn suggereert de spec dat de version uniek moet zijn binnen de verzameling van versies die ve bepaald object bestaan. Ze moedigt zelfs aan om een timestamp te gebruiken: “The maximum length has been selected to allow for time stamps based on ISO 8601.” (p65). Maw, het veld “begintijd” uit Herkomst is hier een goede kandidaat.
De ThematicIdentifier bestaat uit slechts twee velden: een Identifier en een IdentifierScheme. Maw: volgens INSPIRE hoeft een thematische identifier niet in zijn onderdelen opgesplitst worden, een INSPIREid echter wel. Er wordt door INSPIRE van uit gegegaan dat voor eenzelfde INSPIREid meerdere thematic identifiers overeen kunnen stemmen, volgens verschillende IdentifierScheme's: "Some spatial objects may be assigned multiple unique [thematic] identifiers" (p73).
Een aantal vragen vloeit hieruit voort:
VBR (en bij afleiding BestAdd) heeft de INSPIREid structuur voor Identificator dan wel overgenomen, maar dat levert nog geen echte INSPIREid's op. Je kan wel abstractie maken van het onderscheid tussen spatial things en spatial objects (aannemend dat met een spatial thing hoogstens 1 spatial object overeenstemt), maar in de namespace /so gaan zetten ipv /id voor de URI's gaan we wellicht niet doen.
Eigenlijk promoveert VBR de belangrijkste ThematicIdentifier (vb adresid) tot bijna-INSPIREid zet ze eventueel overblijvende thematische identificatoren (vb crab adresid) in een datastructuur identiek aan ThematicIdentifier mn AlternatieveIdentificator (met een veld AlternatieveIdentificator=ThematicIdentifier:Identifier en een veld AlternatieveIdentificatorBron=ThematicIdentifier.IdentifierScheme).
Kortom: VBR neemt twee aspecten over van INSPIRE: 1) opsplitsen van de sleutel in zijn onderdelen en 2) het aanduiden van 1 hoofdsleutel als er meerdere zijn.
Vraag is dus: Is er een meerwaarde voor OSLO² ih opsplitsen vd sleutel in zijn onderdelen? Noteer dat ISA deze opsplitsing niet doet. Misschien omdat een URI makkelijk te splitsen is in namespace en localid? Ook voorziet ISA extra velden naast Identifier: IssuingAuthority, IssueDate en Type. Type & IssuingAuthority kunnen ook de rol van discriminator spelen bij eventueel overlappende identifiers. Merk op dat Identifier mapt op ThematicIdentifier:Identifier en Type op ThematicIdentifier:IdentifierScheme.
Tweede vraag is dus: Is het opportuun om bij OSLO² het onderscheid te maken tussen hoofdsleutel en alternatieve sleutel? Bedenk dat verschillende uitwisselende partijen een ander idee kunnen hebben over wat de hoofdsleutel is. Informatie Vlaanderen kan dit moeilijk voor elke entiteit opleggen en gebruikers zouden dit dan ergens vooraf moeten kunnen nagaan. Bij ISA kan de gebruiker vd data zelf uitmaken welke identificator hij wil gebruiken op basis vd IssuingAuthority en het Type veld.
Dieter en ik namen de INSPIRE Generic Conceptual Model spec en meer bepaald ANNEX H daarvan eens grondig door mbt het definitief afwerken vh datatype Identificator. Wij leerden hieruit het volgende:
Concreet wil de INSPIREid spatial objects identificeren, geen spatial things. Of kort door de bocht: de INSPIREid is een identifier voor polygonen, niet voor wat die polygonen precies voorstellen, daarvoor dient de ThematicIdentifer. Het argument dat je hiervan abstractie kan maken door INSPIRE:Identifier:localid gelijk te stellen aan de ThematicIdentifier:Identifier spreekt de spec zelf tegen: “Since the same real world phenomenon may be represented by multiple spatial objects, the thematic identifier cannot in general be used as an identifier for spatial objects, even though the object may truly represent some ‘thing’ in the real world. The spatial object will often include the thematic identifier as an attribute.” (p141-142).
Merk op dat gans deze redenering ook uitgaat van spatial things, ttz “anything with spatial extent, i.e. size, shape, or position” (p13) en dat kan vanalles zijn “people, places, bowling balls, as well as abstract areas like cubes”. Maar dus geen Organisaties, Dienstverlening enzo tenzij iemand weet hoe je de afmetingen ve Dienstverlening bepaalt?
Bijzonder ook aan het INSPIREid is het Namespace veld. Om dubbele waarden te vermijden vd INSPIRE:Identifier:localid hebben we een discriminerend veld nodig met inherent wat info over wie (land & organisatie) het id heeft uitgegeven voor welk doel (product). Die namespace moest bij INSPIRE centraal geregistreerd worden. Echter onderkent INSPIRE nu dat met de komst van URI’s die noodzaak wegvalt:” A need for a central INSPIRE registry for identifier namespaces would therefore no longer be required and the URI approach would encourage greater interoperability” (p142).
Opvallend daarbij blijft ook in dat geval het onderscheid dat INSPIRE zo graag wil maken tussen things en objects. Ipv /id als type of resource, suggereert INSPIRE om /so te gebruiken in de URI. Je ziet dit ook in bovenstaand voorbeeld met het kadastraal perceel.
Het INSPIREid voorziet ook nog een version attribuut in de INSPIREid. Dit is semantisch niet volledig correct aangezien het niet de versie vd Identifier betreft maar vh object waarnaar de identifier verwijst, dat zegt de spec eigenlijk ook zelf “The version identifier is not part of the unique identifier of a spatial object.” (p96). Hoewel in theorie unieke versieid’s mogelijk zijn suggereert de spec dat de version uniek moet zijn binnen de verzameling van versies die ve bepaald object bestaan. Ze moedigt zelfs aan om een timestamp te gebruiken: “The maximum length has been selected to allow for time stamps based on ISO 8601.” (p65). Maw, het veld “begintijd” uit Herkomst is hier een goede kandidaat.
De ThematicIdentifier bestaat uit slechts twee velden: een Identifier en een IdentifierScheme. Maw: volgens INSPIRE hoeft een thematische identifier niet in zijn onderdelen opgesplitst worden, een INSPIREid echter wel. Er wordt door INSPIRE van uit gegegaan dat voor eenzelfde INSPIREid meerdere thematic identifiers overeen kunnen stemmen, volgens verschillende IdentifierScheme's: "Some spatial objects may be assigned multiple unique [thematic] identifiers" (p73).
Een aantal vragen vloeit hieruit voort:
VBR (en bij afleiding BestAdd) heeft de INSPIREid structuur voor Identificator dan wel overgenomen, maar dat levert nog geen echte INSPIREid's op. Je kan wel abstractie maken van het onderscheid tussen spatial things en spatial objects (aannemend dat met een spatial thing hoogstens 1 spatial object overeenstemt), maar in de namespace /so gaan zetten ipv /id voor de URI's gaan we wellicht niet doen.
Eigenlijk promoveert VBR de belangrijkste ThematicIdentifier (vb adresid) tot bijna-INSPIREid zet ze eventueel overblijvende thematische identificatoren (vb crab adresid) in een datastructuur identiek aan ThematicIdentifier mn AlternatieveIdentificator (met een veld AlternatieveIdentificator=ThematicIdentifier:Identifier en een veld AlternatieveIdentificatorBron=ThematicIdentifier.IdentifierScheme).
Kortom: VBR neemt twee aspecten over van INSPIRE: 1) opsplitsen van de sleutel in zijn onderdelen en 2) het aanduiden van 1 hoofdsleutel als er meerdere zijn.
Vraag is dus: Is er een meerwaarde voor OSLO² ih opsplitsen vd sleutel in zijn onderdelen? Noteer dat ISA deze opsplitsing niet doet. Misschien omdat een URI makkelijk te splitsen is in namespace en localid? Ook voorziet ISA extra velden naast Identifier: IssuingAuthority, IssueDate en Type. Type & IssuingAuthority kunnen ook de rol van discriminator spelen bij eventueel overlappende identifiers. Merk op dat Identifier mapt op ThematicIdentifier:Identifier en Type op ThematicIdentifier:IdentifierScheme.
Tweede vraag is dus: Is het opportuun om bij OSLO² het onderscheid te maken tussen hoofdsleutel en alternatieve sleutel? Bedenk dat verschillende uitwisselende partijen een ander idee kunnen hebben over wat de hoofdsleutel is. Informatie Vlaanderen kan dit moeilijk voor elke entiteit opleggen en gebruikers zouden dit dan ergens vooraf moeten kunnen nagaan. Bij ISA kan de gebruiker vd data zelf uitmaken welke identificator hij wil gebruiken op basis vd IssuingAuthority en het Type veld.