INSPIRE Community Forum

EnvironmentalMonitoringFacility hasObservation Attribute

10 Views
  • Public

EnvironmentalMonitoringFacility hasObservation Attribute

Started by Florian Hoedt Replies (3)

Hello together,

According to the EnvironmentalMonitoringFacilities.xsd an EnvironmentalMonitoringFacility (EMF) hosts a list (0..n) of OM_Observation objects. To publish EF (or in this particular case OF) observations (ProfileObservations) in an INSPIRE conformant datamodel you could use this list to bind the observations to the EMF. To have a viable ressource to discuss, I created a simplified diagram of a OF survey datamodel as diagram:

public draw.io link

At first glance this seems reasonable, but what about this:

If you start with a observation and you would like to query the corrosponding OperationalActivityPeriod aka 'survey' (OAP) you would have to datetime query the observations resultTime with any of the EMFs OAPs to find a matching pair to get an valid answer*. For me this seems unreasonable.

Why is the hasObservation list bound to EMF and not OAP? Are there good reasons for this approach?

* I am aware that you could do some ID matching, or href-fing as by convention to match those. IMHO those approaches are dirty as they tend to be prone to errors.

Whats your oppinion?

yours,

Florian

Replies

    • Public

    By Katharina SCHLEIDT

    Hi Florian,

    a few bits:

    On your datamodel diagram - be aware of the fact that you're only displaying attributes from the final derivation level (so only the attributes specified for EnvironmentalMonitoringFacility, but none of those already specified for AbstractMonitoringFeature or AbstractMonitoringObject, i.e. inspireId, geometry, ...)

    Also, one of the discussions we've been having in the last years is the OperationalActivityPeriod vs. the EnvironmentalMonitoringActivity. These 2 evolved a bit in parallel, once we were done we realized the semantic similarity. However, the OperationalActivityPeriod has been formalized as required in the IRs, whereas EnvironmentalMonitoringActivity is optional, and nobody has had the time or energy to rectify this :(

    If you check D2.9, you'll see that Observations should also reference their EMF via the Observation Parameter; described in 7.1.6 Linking to monitoring facility / network. Here we have a requirement and a recommendation:

    /req/inspire-om-core/relatedMonitoringFeature-parameter: To make a reference to an Environmental Monitoring Facility or an Environmental Monitoring Network from an OM_Observation, a ‘parameter’ attribute SHALL be provided, whose ‘name’ attribute is 'relatedMonitoringFeature' and whose ‘value’ attribute is the external object identifier of the referenced spatial object.

    /rec/inspire-om-core/relatedMonitoringFeature-URI: In case the observation ‘parameter’ is used, its ‘value’ attribute SHOULD be a resolvable HTTP URI

    To my view, all required temporal information is available, I don't see the added benefit of the link to OAP. If you want all observations from an EMF for a given time period, query the observations linked to this EMF as described above and specify the phenomenonTime

    As to the linking via xlink:href - this is essential for the model to work (you can't do a linked model without links ;) ). What's a bit tricky is providing resolvable links in the xlink; as this is a general problem in INSPIRE we provided information in the Workshop on Practical INSPIRE, see: https://inspire.ec.europa.eu/sites/default/files/presentations/mp18_pdf_final.pdf

    Does this help, or did I miss something?

    :?

    Kathi

    • Public

    By Florian Hoedt

    Hi Kathi

    First things first: Thank you for your great feedback by pointing me to the Dx.x paragraphs ironing out some of my concerns. It is a pleasure to dive deep into this and more and more painting an inspiring picture.


    Also, one of the discussions we've been having in the last years is the OperationalActivityPeriod vs. the EnvironmentalMonitoringActivity. These 2 evolved a bit in parallel, once we were done we realized the semantic similarity. However, the OperationalActivityPeriod has been formalized as required in the IRs, whereas EnvironmentalMonitoringActivity is optional, and nobody has had the time or energy to rectify this :(

    As far as I understood those two, they should be read as:

    EnvironmentalMonitoringActivity (EMA): A specific survey of the vessel.

    OperationalActivityPeriod (OPA): The timespan the vessel is in active duty.

    Therefore the OPA should allways cover all EMA.

    >> Are you with me?


    To my view, all required temporal information is available, I don't see the added benefit of the link to OAP. If you want all observations from an EMF for a given time period, query the observations linked to this EMF as described above and specify the phenomenonTime

    I elaborate a bit more about this:

    I have discovered a EMA I am interested in, eg. a crangon survey at greenland. To fetch all data for this specific survey I would need to query like this:

    1. get EMF (myEMF) from myEMA.uses
    2. get Observations from myEMF.hasObservation (myObservations)
    3. query myObservations where myObservation.phenomenonTime is BETWEEN myEMA.activityTime.TimePeriod.begin AND myEMA.activityTime.TimePeriod.end

    just to get all Obersvations carried out at this particular EMA. This is something I see as cumbersome for later usage of EF data. Nonetheless you totally could find the data you search for.


    As to the linking via xlink:href - this is essential for the model to work (you can't do a linked model without links ;) ). What's a bit tricky is providing resolvable links in the xlink; as this is a general problem in INSPIRE we provided information in the Workshop on Practical INSPIRE, see: https://inspire.ec.europa.eu/sites/default/files/presentations/mp18_pdf_final.pdf

    Great ressource! Thank you for sharing this. I now do understand the purpose and need for xlinks and see the application possibilites (as demoed) much clearer.


    On your datamodel diagram - be aware of the fact that you're only displaying attributes from the final derivation level (so only the attributes specified for EnvironmentalMonitoringFacility, but none of those already specified for AbstractMonitoringFeature or AbstractMonitoringObject, i.e. inspireId, geometry, ...)

    Thats what I meant by 'simplified'. Most of those where not needed for me to understand the top level view of the datamodel. My diagram is neither comprehensive nor valid UML or ER. It just helped me a lot to understand the general structure of the different featureTypes and how those are bound (or not) together.

    • Public

    By Katharina SCHLEIDT

    Hi Florian,

    to return the complement - thanks for asking real questions here! To my experience too many folks are scared of asking; as you have shown, many of these questions are very relevant and have not been clarified in a satisfactory manner, but until folks start asking the right questions here, we don't even have a mandate to clarify!

    A bit more background to the discrepancy between OAP and EMA - this also has to do with the evolution of the model. At first we only had the OAP, then EMA and EMP were added to cover administrative aspects; at the same time we were under pressure not to overload the models with non-spatial stuff (EMA doesn't even have a geometry). And, while we did have a few use cases to work with (very few :( ), the focus was on defining a conceptual model; in normal IT this would then be further refined to an implementation model, but this step was ignored or delegated to the MS (but nobody ever really told them! ;) )

    I've done a reworked UML diagram showing all relevant EF featureTypes (so leaving out the abstract hierarchy) whereby all attributes and associations inherited from these abstract ancestors are displayed. I've put it in our resource pages, fairly close to the top: https://themes.jrc.ec.europa.eu/pages/view/30607/efom-resources

    I very much like your use case, as it nicely highlights real-world usability. It also shows one of the missing bits with the URI-rewriting bit for the creation of resolvable URI based GUIDs - while you have access to the specific feature referenced, you don't have a nice way of accessing the service URI for further interogation (i.e. give me ALL your observations pertaining to XXX). My current work-around is providing a link to the INSPIRE Metadata document in the gml metadata, as this would allow for automated discovery of the service URI, but this has yet to be prototyped and tested (maybe you'd like to try this?)

    Finally, after the practial INSPIRE WS you so liked the presentation for (as well as similar ones we did on O&M and Coverage data models) we came to the conclusion that what would really be helpful for implementers would be 2-3 day hands-on-clinics (bring your own data, models, mapping and configuration problems (and ideally (remote) access to your infrastructure), and we'll help to sort things interactively. Would you see such events as useful? Would you consider attending?

    :)

    Kathi

Environmental Monitoring and Observations Cluster

Environmental Monitoring and Observations Cluster

Environmental Monitoring Facilities, Observations and Measurements