Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking Host and SpatialSample types of ""Station"" #34

Open
sgrellet opened this issue Apr 13, 2023 · 4 comments
Open

Linking Host and SpatialSample types of ""Station"" #34

sgrellet opened this issue Apr 13, 2023 · 4 comments

Comments

@sgrellet
Copy link
Member

How to link

  • Water Quality stations for fixed sensor network not taking sample (ex : temperature, pH etc... see notes from April 11th 2023): typed Host in our Object Diagrams
  • And WaterQualityStation where we do take MaterialSamples for further obs : typed SpatialSample

Use Case : Linking both ""stations"" to help domain colleagues acquire and process Water Quality Observations regardless of whether that ""station"" is a Host/SpatialSample from an OMS point of view

Figure6 from OMS is not helping here (see below).

  • In Observations & Measurements (OM) : we only had ""station"" related artefacts under the Sample package. We usually picked subtypes of SF_SpatialSamplingFeature which could be associated through "+relatedSamplingFeature"
  • Now in Observations, Measurements & Samples (OMS) we have ""station"" related artefacts both under
    • Observation:Host/Deployment/Observer -> good candidate for fixed in-situ sensors
    • AND Sample:SpatialSample -> good candidate for identifying/describing Features where Samples are taken
    • but those cannot be related

In ontologies we could try polymorphism but in pure UML seems we are stuck.
Did we miss something ?

image

@KathiSchleidt
Copy link
Collaborator

First off, polymorphism is possible in GML UML, just a bit tricky when it comes to serialization (it's XML that doesn't support polymorphism).

I see 2 different approaches here, first the polymorphic interface approach. Create a new WQ_SampleHost that realizes both Sample and Host interfaces.

Interface approach

@KathiSchleidt
Copy link
Collaborator

Second approach would be creating a specific WQ_Host (derived from Host), with an association to ObservingCapabilities. Then you can link the SpatialSample via the ObservingCapabilities.

This is a bit difficult to visualize due to the nature of the OMS model. Thus, first a simple view on this approach:

ObsCaps approach simple

Here the more complex view, showing all the intermediate classes and interfaces.

ObsCaps approach full

@sgrellet
Copy link
Member Author

sgrellet commented May 2, 2023

Thanks @KathiSchleidt : I like the second one, let's discuss this in the next WQ IE Webconf

@sgrellet
Copy link
Member Author

sgrellet commented May 2, 2023

extension is mandatory because the ObservingCapability --> Host association is not bidirectionnal .
Specialization to happen under OMS SWG -> @KathiSchleidt

Then @sgrellet to update the object Diagrams for WQ IE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants