Clarify 'SSN Ontology'

[dr-shorthair]

The section on modularization introduces the various graphs and namespaces comprising the SSN Ontology. This needs a bit more work and wordsmithing to clarify

• what the term 'SSN Ontology' means
• how this relates to 'SOSA Graph', 'SSN Graph', 'SSN-System Graph', 'SOSA-OMS Graph', 'SSN-OMS Graph' etc
• how these relate to OGC Conformance classes
• (possibly - how the latter relate to SHACL shapes graphs - TBD).

[dr-shorthair]

Re-writing the 'modularization' section at the top of the document, it occurs to me that further modularisation is possible.

This would involved more RDF graphs - e.g.

• SOSA-Core SOSA-Base - the superclasses and re-used properties
  • FoI, Property, PropertyOfInterest, Procedure, Execution, System, Platform, Deployment, hasProperty, hasResult, hasInput, hasOutput, hasInputValue, hasOutputValue, resultTime, startTime, phenomenonTime, hasMember
• SOSA-Actuation - imports SOSA-Core and adds actuation specializations
  • ActuatableProperty, Actuation, Actuator, ActuatingProcedure, ActuationCollection etc
• SOSA-Observation - imports SOSA-Core and adds observation specializations
  • ObservableProperty, Observation, Sensor, ObservingProcedure, ObservationCollection etc
• SOSA-Sampling - imports SOSA-Core and adds sampling specializations
  • Sampling, SamplingProcedure, PreparationProcedure, Sample, MaterialSample, SpatialSample, StatisticalSample, SampleCollection etc

The advantage of this would be that it might better match the 'conformance class' approach from OGC - i.e. so that applications could claim conformance to (i.e. that they implement) only those modules that they need.

The disadvantage is further packaging complexity. This might be mitigated somewhat by also providing a SOSA-All graph that imports all the above.

Similar modularization in the SSN (axiomatized version) too ...

Thoughts?

[ldesousa]

I like this proposal. It makes the overall ontology easier to understand and apply. And four modules is not at all excessive (Dublin Core and QUDT have about the same or more).

[dr-shorthair]

I started on a diagram of the modules.

Inside the packages on the RHS I've indicated which Classes belong to each module. The arrows indicate <imports> dependencies.

When finished this could/should replace Figure 1. (the horizontal/vertical modularization diagram) that we have at present.

[ldesousa]

I started on a diagram of the modules.

It looks good. Some (light) colouring can make it even more expressive.

[dr-shorthair]

Closed by aba2745