Een emissiebron kan zowel een activiteit als een entiteit zijn

[gezever]

Emissiebron

Beschrijving Oorsprong van een emissie. Gebruik Het kan een inrichting zijn zoals een fabriek, installatie of schoorsteen maar ook een activiteit zoals bemesting. Typisch onderworpen aan milieuwetgeving en opgelijst als potentieel hinderlijk, zie bv. IIOA's van VLAREM.

Ik heb een dataset met een lozingspijp, een meetpunt, een installatie, een emissie, een fabriek, een verantwoordelijke en een activiteit 'productie van ...' I Volgens het model map ik dan zowel de fabriek, als de lozingspijp, als de installatie en de activiteit op emissiebron, waardoor er meerdere emissiebronnen zijn op meerdere locaties, waarbij de lozingspijp eventueel de ontvanger van de emissie van de activiteit en de installatie is .

Indien er nog een waterzuivering tussen zou zitten, of nog maar een afkoeling, komen we al snel tot iets dat op een provenance model lijkt. Provenance is dan ook exact wat de definitie van "Emissiebron" zegt, de oorsprong van een emissie.

In "The rationale of PROV", hieronder toegevoegd, stelt een eerste requirement dat het de bedoeling is om Class disjointness maximaal te vermijden. Een van de enige uitzonderingen, waar expliciet voor disjointness wordt gekozen, is dat iets niet tegelijk een activiteit en een entiteit kan zijn.

Daarom zou ik dit niet doen.

The-rationale-of-PROV_2015_Journal-of-Web-Semantics.pdf

[GeertThijs]

Hierover dit:

• In PROV wordt inderdaad een onderscheid gemaakt tussen Entities en Activities en deze zijn uiteraard disjoint, een Entity is geen Activity.
• Maar in PROV gaat het om herkomst: hoe is een Entity ontstaan, welke Activity heeft ze veroorzaakt en welke Agent voerde deze uit.
• Bvb in de media: de Entity "Boek123" is onstaan tijdens een Activity "Schrijven456" uitgevoerd door Agent "Schrijver789".
• Toegepast op deze context: CO2emissie123 is ontstaan tijdens Productieproces456 uitgevoerd door Fabriek789. Of StikstofEmissie123 is ontstaan tijdens Bemesting456 uitgevoerd door Landbouwer789.
• Eigenlijk is Emissie dus de PROV:Entity en EmissieBron staat voor de PROV:Activity+PROV:Agent.
• Het klopt dat we EmissieBron gedefinieerd hebben als zijnde de inrichtring OF activiteit die de Emissie veroorzaakt, maar dat staat volgens mij los van de opdeling tussen Entities en Activities in PROV die een ander doel dient.
• Dat hoewel Emissiebron dus voor PROV:Activity+PROV:Agent staat het niet enkel een activiteit zoals bemesting kan zijn maar ook een fysieke vorm kan aannemen zoals een fabriek of schouw is verder geen probleem: het is nl het productieproces (een activiteit!) dat uiteindelijk via de fabriek of schouw voor Emissie zorgt, fabriek of schouw is gewoon de proxy voor de achterliggende activiteit.

[GeertThijs]

Nog ter info verder:

• De klassen Emissie en Emissiebron zijn slechts haakjes naar een meer uitgebreid model van inrichtingen en activiteiten dat buiten de scope van het model Waterkwaliteit valt.
• Inspiratie kwam uit INSPIRE Production and Industrial Facilities waarin het onderscheid tussen TechnicalUnits en Activities wel gemaakt wordt maar uiteindelijk ook wordt samengevoegd in ProductionProces met Emission als output.
• Maw: Emissiebron mapt eerder op iets als ProductionProces, gerealiseerd door TechnicalUnits + Activities.
• Zie bijgevoegde nota Lozingspunt.pdf met de analyse van het INSPIRE model die uitgvoerd werd tbv het OSLO Waterkwaliteit traject.

[GeertThijs]

Vb van gebruik van emissiebron (OPMERKING zonder context, niet-gevalideerd, louter ter illustratie):

{
    "@context": "",
    "@graph": [
        {
            "@id": "https://example.com/id/observatie/obs123",
            "@type": "ChemischAgensVrachtObservatie",
            "ChemischAgensVrachtObservatie.geobserveerdKenmerk": {
                "@id": "https://example.com/concept/chemisch-agens-kenmerktype/emissie",
                "@type": "skos:Concept"
            },
            "ChemischAgensVrachtObservatie.agens": {
                "@id": "https://example.com/concept/chemisch-agens/co2",
                "@type": [
                    "skos:Concept",
                    "Agens"
                ]
            },
            "Observatie.geobserveerdObject": "_:emb01",
            "ChemischAgensVrachtObservatie.resultaat": {
                "@type": "Maat",
                "Maat.maat": {
                    "@type": "KwantitatieveWaarde",
                    "KwantitatieveWaarde.waarde": {
                        "value": 1,
                        "@type": "Getal"
                    },
                    "KwantitatieveWaarde.standaardEenheid": {
                        "@type": [
                            "qudt-schema:Unit",
                            "StandaardEenheid"
                        ],
                        "@id": "http://qudt.org/vocab/unit/TON_Metric-PER-DAY"
                    }
                }
            }
        },
        {
            "@id": "https://example.com/id/emissiebron/emb456",
            "@type": "Emissiebron",
            "Emissiebron.type": {
                "@id": "https://example.com/concept/emissiebrontype/schoorsteen",
                "@type": "skos:Concept"
            },
            "Emissiebron.locatie": {
                "@type": [
                    "Locatie",
                    "Adresvoorstelling"
                ],
                "Adresvoorstelling.locatienaam": {
                    "@value": "Brussel-Energie",
                    "@language": "nl"
                }
            }
        }
    ]
}

[brechtvdv]

Voor het vervolgtraject zou ik Emissiebron als "abstracte" klasse laten staan, en uitbreiden met activiteiten en exploitaties (cfr. TechnicalUnits + Activities). Daarbij prov relaties toevoegen zoals prov:wasInfluencedBy (Emissie prov:wasInfluencedBy Exploitatie). Dit lijkt me net heel waardevol voor OSLO implementaties.

[GeertThijs]

Voor het vervolgtraject zou ik Emissiebron als "abstracte" klasse laten staan, en uitbreiden met activiteiten en exploitaties (cfr. TechnicalUnits + Activities). Daarbij prov relaties toevoegen zoals prov:wasInfluencedBy (Emissie prov:wasInfluencedBy Exploitatie). Dit lijkt me net heel waardevol voor OSLO implementaties.

Werd voor het traject Waterkwaliteit buiten scope gezet. Leek het voorwerp van een apart traject want relatief complex.

[gezever]

Voor het vervolgtraject zou ik Emissiebron als "abstracte" klasse laten staan, en uitbreiden met activiteiten en exploitaties (cfr. TechnicalUnits + Activities). Daarbij prov relaties toevoegen zoals prov:wasInfluencedBy (Emissie prov:wasInfluencedBy Exploitatie). Dit lijkt me net heel waardevol voor OSLO implementaties.

Ooit komt er een mooie use-case waar de herkomst van vervuiling de hoofdvraag zal zijn. Dan wordt het puur prov-o.

[gezever]

@brechtvdv Je hebt helemaal gelijk. De imjv data worden nu via ldes ontsloten volgens sosa:Observations en via subject pages volgens cube:Observations. In grote lijnen is dat gelijkaardig, de observatie is subject en al de rest is gereificeerd. In de brondata zit echter ook veel proces-informatie, activiteiten, installaties, derivaten etc., provenance informatie die (nog) niet gepubliceerd wordt.