Om de scope van het individu te bepalen is het handig de life-cycle van het individu langs te lopen.
Het uitgangspunt is dat het individu de fysieke overstortput is en deze ontstaat bij de fabrikant en wordt dan al of niet via tussenhandel geleverd, geplaatst en in gebruik genomen in Roosendaal. Tijdens het gebruik wordt onderhoud gepleegd en andere activiteiten aan de put. Aan het einde van het gebruik van deze put, kan hij worden vervangen door een andere put.
Er rijzen twee vragen:
Heeft de nieuwe put een andere GUID?
Heeft de nieuwe put ook het label P123?
Dit hangt helemaal van de scope af van Roosendaal. Ik neem aan dat er naast een overstortput ook andere assets zijn zoals pompen. Een asset, dus een overstort put en een pomp, wil je functioneel en fysiek volgen.
Het antwoord op de vraag of het handig is Roosendaal in de URI op te nemen als dat kan wijzigen in een andere gemeente, is compleet afhankelijk van de scope. Wel adviseer ik dat de volgende eigenaar dezelfde UUID gebruikt om de asset blijvend uniek te kunnen identificeren. Dat er in de URI dan een eigendomsrelatie zit verstopt is alleen in dit geval niet erg.
In het geval van een pomp is het anders. Stel de pomp wordt vervangen door een andere pomp. De nieuwe pomp heeft een eigen UUID. De label P123 moet dan verhangen worden naar de nieuwe UUID en de oude pomp mag niet meer het label P123 hebben. Een oplossing zou zijn om SKOS-XL te gebruiken voor labels en alt labels.
Verder kan de oude pomp na onderhoud ergens anders in het areaal worden ingezet en krijgt dan het label P234 bijvoorbeeld. Het voor assetmanagement noodzakelijk dat onderscheid gemaakt wordt tussen de functionele asset en de fysieke asset.
Eigendomsrelaties, relaties tussen een functie en technische oplossing zijn van tijdelijke aard. Stop deze niet in de URI. Dit geeft teveel beperkingen, zeker voor beheer.
Mijn advies voor de URI:
• Maak onderscheid tussen de functionele asset en de fysieke asset
• Stop alleen universele en tijdloze betekenissen in de URI
3.1.1 Waarom
Beschrijft de reden waarom dit goed is om te doen. Een best practice is er om te zorgen dat de complete sector/domein de vruchten kan plukken van de lessons learned van anderen in de sector. Een beschrijving van een best practice heeft uitleg waarom het wordt toegepast. In dit geval houdt rekening met de life cycle van het individu waar de URI naar wijst.
3.1.2 Beoogd resultaat
Beschrijft het beoogde resultaat. Over de hele sector een voorspelbare en zelfde wijze van toepassen en implementatie van LD voor eenvoudigere uitwisseling tussen ON en OG. Maar ook dat de ON door alle OG de informatie op een zelfde wijze krijgt aangeboden.
Een individu wordt geïdentificeerd met een unieke ID. In de URI-BP wordt voorgesteld in een voorbeeld voor een overstortput in Roosendaal:
https://{domain}/{type}/{owner}#{reference}
https://data.gwsw.nl/id/061674#b2ad189a-8c46-49f2-557ba07c49a2
Om de scope van het individu te bepalen is het handig de life-cycle van het individu langs te lopen. Het uitgangspunt is dat het individu de fysieke overstortput is en deze ontstaat bij de fabrikant en wordt dan al of niet via tussenhandel geleverd, geplaatst en in gebruik genomen in Roosendaal. Tijdens het gebruik wordt onderhoud gepleegd en andere activiteiten aan de put. Aan het einde van het gebruik van deze put, kan hij worden vervangen door een andere put. Er rijzen twee vragen:
Dit hangt helemaal van de scope af van Roosendaal. Ik neem aan dat er naast een overstortput ook andere assets zijn zoals pompen. Een asset, dus een overstort put en een pomp, wil je functioneel en fysiek volgen.
Het antwoord op de vraag of het handig is Roosendaal in de URI op te nemen als dat kan wijzigen in een andere gemeente, is compleet afhankelijk van de scope. Wel adviseer ik dat de volgende eigenaar dezelfde UUID gebruikt om de asset blijvend uniek te kunnen identificeren. Dat er in de URI dan een eigendomsrelatie zit verstopt is alleen in dit geval niet erg.
In het geval van een pomp is het anders. Stel de pomp wordt vervangen door een andere pomp. De nieuwe pomp heeft een eigen UUID. De label P123 moet dan verhangen worden naar de nieuwe UUID en de oude pomp mag niet meer het label P123 hebben. Een oplossing zou zijn om SKOS-XL te gebruiken voor labels en alt labels.
Verder kan de oude pomp na onderhoud ergens anders in het areaal worden ingezet en krijgt dan het label P234 bijvoorbeeld. Het voor assetmanagement noodzakelijk dat onderscheid gemaakt wordt tussen de functionele asset en de fysieke asset.
Eigendomsrelaties, relaties tussen een functie en technische oplossing zijn van tijdelijke aard. Stop deze niet in de URI. Dit geeft teveel beperkingen, zeker voor beheer.
Mijn advies voor de URI: • Maak onderscheid tussen de functionele asset en de fysieke asset • Stop alleen universele en tijdloze betekenissen in de URI
3.1.1 Waarom
Beschrijft de reden waarom dit goed is om te doen. Een best practice is er om te zorgen dat de complete sector/domein de vruchten kan plukken van de lessons learned van anderen in de sector. Een beschrijving van een best practice heeft uitleg waarom het wordt toegepast. In dit geval houdt rekening met de life cycle van het individu waar de URI naar wijst.
3.1.2 Beoogd resultaat
Beschrijft het beoogde resultaat. Over de hele sector een voorspelbare en zelfde wijze van toepassen en implementatie van LD voor eenvoudigere uitwisseling tussen ON en OG. Maar ook dat de ON door alle OG de informatie op een zelfde wijze krijgt aangeboden.