Move System Capabilities module into a separate document

[dr-shorthair]

After looking at the System Capabilities module a bit, I am coming to the conclusion that it is rather immature and potentially misleading. @oldskeptic has had an honest attempt at using it which I have now reviewed in some detail, and this has led to confusion.

@maximelefrancois86 has noted that the provenance of this module is sketchy. Various issues are struggling with the relationship between sensor-instances and types, and how to express or link to datasheets.

I fear that resolving this set of issues could really bog down our efforts to complete the update of SSN/SOSA.

IMAO the primary focus of SSN/SOSA is to model the 'executions' - i.e. the acts of actuation/observation/sampling.
'Content models' for procedures, systems, platforms etc are a big field with a lot of domain specific craft to accommodate. It is central to @alexrobin's Connected Systems initiative so we don't want to accidentally come up with something inconsistent with that. I'd prefer to leave these as empty, 'abstract' classes in SSN/SOSA with the fleshing out documented externally.

So I propose that we spin this out into a separate document, where it can receive proper attention and can perhaps mature a bit. @oldskeptic @maximelefrancois86 @alexrobin could perhaps take the lead in taking this on? I'm just finding that for now this set of issues is impeding progress in finalizing the core efforts in SSN/SOSA.

[dr-shorthair]

Related:
#196 #107 #108 #208 #211 #220

[alexrobin]

@dr-shorthair What I liked about SOSA/SSN is that it also started tackling the systems/procedures descriptions, etc. It was a big plus compared to OMS alone so I really don't want to let this go and I would like to keep it in the main document.

I don't mind spending some time reviewing/improving the existing definitions.

What's your timeline?

[dr-shorthair]

Currently @oldskeptic and @dr-shorthair have been the only participants looking at it in any detail.
As @maximelefrancois86 noted, it really has not been adjusted since the Incubator work over 10 years ago, and the documentation and patterns are clearly confusing, as @oldskeptic has found.

But I'm out of my depth really on this, and it is pulling me away from what I think are more core issues, so I need to delegate or defer it.
In practice deferral means moving it out of the main document.

[dr-shorthair]

@oldskeptic to propose a stripped-down version to retain in this document

Remaining question: which namespace?

• sosa: - core ontology
• ssn-system: - system capabilities extension module

[dr-shorthair]

Important question: is sosa:Sensor (specialization of sosa:System)

• a thing with a model number (a sensor-type or SensorKind) or
• a thing with a serial-number (a sensor instance) ?

(summarizing question from @kjano )

related to #107

[alexrobin]

@dr-shorthair as I told you offline, I'd really like to keep at least SystemKind and its subclasses and PlatformKind in the main ontology.

I don't mind moving the system capabilities themselves somewhere else as long as the existing URIs still resolve.

[alexrobin]

I can finalize the PR for the kind classes themselves if that helps ( I think what remained to be done was separating the system and platform hierarchies better)

[dr-shorthair]

In telecon 2024-06-12 @oldskeptic agreed to propose a minimal capabilities schema for SSN/SOSA (e.g. just Accuracy, Resolution, Frequency, MeasurementRange).

The fate of the current System Capabilities module can then be considered in that light.