GeertThijs
commented
6 years ago Conclusie is alvast dat we niet zomaar een klasse Locatie willen invoeren, zelfs al heeft deze nog geen invulling. Argumentatie:
- We zouden een associatie met deze klasse moeten leggen voor Bestuurseenheid wat overkill lijkt.
- Locatie (in de betekenis van Ligging) is een kenmerk van iets en kan als dusdanig op verschillende manieren worden ingevuld:
- plaats(naam)
- geometrie
- adres
- etc
- Bij INSPIRE:
- is plaats een klasse (NamedPlace) waarmee gassocieerd kan worden of een attribuut (GeographicalName). Er zijn maw plaatsen en plaatsnamen (topniemen). Zie http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_GN_v3.0.pdf.
- is geometrie een attribuut vh datatype Geometry. Zie https://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4rc3.pdf.
- is adres een associatie met een klasse Address of een attribuut vh type AddressRepresentation. Zie http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.pdf.
- Bij ISA/W3C (zie https://www.w3.org/ns/locn#locn:location):
- is plaats een klasse (dcterms:Location) waaraan een attribuut GeographicalName is toegevoegd (althans op het diagram, het attribuut heeft geen domain).
- is een klasse Geometry waarbij dmv een gebruiksnota wordt gezegd hoe deze kan worden ingevuld. OSLO-Generiek heeft een datatype Geometrie die hierop is gemapt en wordt ingevuld dmv subtypes en gml/wkt serialisatie.
- is een Adres een klasse gebaseerd op het datatype Adresvoorstelling uit INSPIRE.
- Bij OSLO is al een invulling voor geometrie en adres, voor plaats gebruiken we de enumeratie Plaarscode en voor plaatsnamen het datatype GeografischeNaam. Locatie op zich komt niet voor.
- Sowieso zou Locatie een datatype moeten zijn en geen klasse, het is een kenmerk van iets anders, een kenmerk dat de ligging aanduidt en dit kan dus op verschillende manieren.
Verschillen invulling attribuut PubliekeOrganisatie.werkingsgebied & attribuut Bestuurseenheid.werkingsgebied:
Definities:
Hierover dit:
het werkingsgebied van Bestuurseenheid wordt neergezet als een subproperty vh werkingsgebied ve PubliekeOrganisatie, maw het is er een verdere specialisatie van
dat de ranges van beide verschillend zijn (skos:Concept vs prov:Location) is daarbij geen probleem, zelfs niet dat een skos:Concept verwijzend naar een codelijst van plaatsnamen een veel gespecialiseerdere manier is om een locatie te beschrijven dan prov:Location. Maw: subproperty slaat op de semantiek vh attribuut, niet op zijn range.
prov:Location is wel heel erg ruim om het werkingsgebied vd Bestuurseenheid te beschrijven, laat om het even welke manier toe om een locatie te beschrijven (plaatsnaam, gerometrie, adres...).
anderzijds is skos:Concept verwijzend naar de NAL-ATU ook een slechte oplossing aangezien in praktijk de ATU-lijst onvolledig is.
prov:Location wordt in het UML-diagram vertegenwoordigd door een klasse Locatie. Maar een modelleringsregel zegt: attribuut voor een datatype, associatie voor een klasse.
Locatie heeft verder geen enkel attribuut, als we een associatie ermee zouden maken is het een associatie met een klasse zonder attributen.
vraag is ook waarom prov:Location en niet locn:Location. Prov:Location is ruimer gedefinieerd in die zin dat het bv ook over de locatie ve record in een databank kan gaan, maar die verruiming hebben we hier niet nodig. Plus dat we eerder al op ISA afstemden.