System types and individuals #107
Comments
|
@alexrobin @KathiSchleidt do you have an opinion on this? |
|
@maximelefrancois86 At the moment, we are using @KathiSchleidt @dr-shorthair Can you comment on this usage of If |
|
@alexrobin at first sight at least that is a reasonable approach. |
|
@alexrobin I'm not convinced at all. The spec itself mentions that ssn:System can be used to generically refer to a type/kind of system. So it shouldn't be an option to suggest an completely alternative way to model is. What's more, If I model the DHT22 temperature and humidity sensor type as a kind of |
|
@maximelefrancois86 I actually agree with you. I have never really liked the idea of using You're right that the link between |
|
While discussing for the new version of ETSI SAREF with @rgcmme , it was agreed to keep only two classes. In particular, to avoid having a common super-class that we hope nobody will use. As For the class that models device types/kinds , different proposals were made: DeviceKind / Type / Model / Category /Specification / Prototype / ... After some discussion with @dr-shorthair , only
|
|
@maximelefrancois86 is I liked your idea of having Thanks, |
|
Please read: Indeed we could also differentiate In SOSA |
|
@maximelefrancois86 Ok, that makes sense to me. @dr-shorthair what are your thoughts on this? Is using |
|
Device characteristics are not part of a procedure. I saw recently a case where the identical open source sensor was used to measure ostensibly the same feature type (air quality in a room) but significant differences in procedure resulted in incompatible data. One aspect of the difference was standardisation of siting - arguably this is nuanced sampling etc, but the point is differences in level of abstraction in one dimension tend to result in shifting the specialisation to another, finer grained semantics between instance and kind seems to be a pattern that helps. I also wonder about FoIKind . If a referenced feature is polymorphic is it important to understand the context and which view of that feature has the relevant properties if you want to make an observation on the state of it... |
|
@rob-metalinkage Yes, as I said I tend to agree with this (it actually solves some of my problems), but be aware that the OMS v3 conceptual model kind of hints at using the From https://docs.ogc.org/as/20-082r4/20-082r4.html#_observingprocedure
From https://docs.ogc.org/as/20-082r4/20-082r4.html#_observer
And I clearly remember discussions with the OMS folks where they recommended using the |
|
@alexrobin : indeed, the underlying rationale in OMS was
to try and desambiguate what people were doing with |
|
Thanks for the confirmation @sgrellet. That's what I understood from our conversations and I thought having two separate classes However, apparently there is still ambiguity between The way I have solved this in Connected Systems is by attaching one I like the new proposal for new |
|
Could we just allow more than one |
|
I would rather retain the [1..1] cardinality, but I would still see the "Procedure container" option as less than optimal. The case that @alexrobin described makes me wonder if instead we are missing something such as a |
|
This is the same pattern we see for every dimension of the problem. IMHO symmetry will reduce complexity, so what we do for observed property should also apply to procedure, sensor, and perhaps metadata such as result, foi type etc. IMHO we should describe the requirements, the pattern, and then the places it is applied in a separate section. Let's do this first before risking different solutions and naming. There are at least three layers... The semantics of kind, with relationships between levels of generalisation The implementation metadata the user needs.. I.e. the schema and data model used to describe the description The instance It's analogous to Web links, where we are inheriting rather adhoc mixtures of solutions to these when we come to schemas, generalised links, feature Type, features Schema properties etc. |
|
@dr-shorthair I think the [1..1] cardinality on The datasheet is something that is mostly associated to the system itself because it is usually provided by the manufacturer and assumed to be valid no matter how the system is deployed or used (although some elements in the datasheet can be specified for different deployment conditions). So I don't think there is a real need to associate the datasheet to the Perhaps we just need to clarify that the This would handle the use case where the In the case where the I still like the |
|
Thanks @alexrobin As I don't work in this part of the space much, I'm finding it a bit hard to follow. Would it be possible to generate (or point to) some examples to support the approach(es) that you are describing? TBH I'm very happy to be guided by you and @maximelefrancois86 who I think have the most experience in this space. If it involves new terms, then that's OK providing we have evidence of implementation for any normative terms. However, also note that I won't be able to generate either the sections in ssn/index.html or the definitions in ssn/integrated/sosa.ttl, ssn.ttl, ssn-system.ttl etc, so resolving this will depend on you guys doing the work and preparing the PR(s). |
|
@dr-shorthair Sorry I think trying to explain things in plain English makes things confusing :-) Or maybe I don´t speak English correctly ! It boils down to the following. Is there a requirement that If not, then this could be a way of specifying the methodology used separately from the sensor specs (datasheet), by pointing to 2 different
The same applies to |
|
Maybe that's how it was always intended to be used but I don't think it clearly says this anywhere... |
|
Thanks @alexrobin - I'm cogitating on it. |
|
@dr-shorthair Yes, there is some kind of relationship for sure. I would say that
I think we can do all this with the current model, so perhaps initially, simple clarifications in the documentation could suffice. But creating subclasses of @ldesousa @maximelefrancois86 @sgrellet Does it make sense to you guys? |
|
+1 on relationship between Procedure (1) and Procedure (2) I think Overall, I feel that we are entangled in that discussion in
I've seen above the mention of
What do we want here ?
=> Could we discuss this during a webconf with an example (and drawings to help abstraction) ? |
|
@sgrellet All good points. I know OMS does not go as far as describing datasheets but SSN kinda does already by defining System Capabilities. To me, the idea of a "SensorKind" is just to factor out some of these capabilities so they can be reused by many instances of the same sensor model, instead of repeating them in each instance. It's different from sensor type that is usually just a classifier. That said, I don't necessarily expect SOSA/SSN to provide everything to specify datasheet level info, but what I would like is that the SOSA/SSN model clearly identifies the place where this information should be provided (i.e. in what class and via which association), and how it works when a procedure/methodology is also provided. As mentionned by @maximelefrancois86 at the beginning of this thread, there is clearly some confusion right now since the My understanding was that this issue was solved in OMS by separating out the |
|
In OMS, we skirted by the datasheet issue by ignoring it, letting users provide a reference in the Observer if they wish. But I've always worried a bit about this omission, do think we need all 3 levels of:
What's still unclear to me from the discussion above are the relations to/between these concepts. I've done a quick sketch from some existing diagrams to illustrate the various cases described above (e.g. a human observer not having a datasheet, a sensor implementing 2 different procedures) we can use to discuss this evening |
|
@KathiSchleidt I agree with you but now that we are talking about all this, I think I'm unclear about what "A sensor implements a procedure" even means. I always thought in the case of a sensor device, the It's clear to me that a "human sensor" can implement a procedure, but how can a piece of hardware implement a procedure that's not already specified in its datasheet? I'm also unfamiliar with the use case "a sensor implementing 2 different procedures". How can a sensor device implement two procedures at the same time? Are we talking about cases where a sensor has different modes? Where the sensor is highly programmable? Can you give a concrete example of this? I can clearly see cases where a human implements a procedure that may involve a sensor, but it's not the same as the sensor itself implementing a procedure. Just trying to connect the dots before I start drafting some ideas in the PR. Thanks, |
|
Can we find a compromise with a range Includes System,SystemKind. Personally I'd like an unambiguous predicate for each, and leave a deprecated ambiguous one for backwards compatibility |
|
@kjano wrote
Could you spell out some small examples please? |
|
For instance, you could have subclasses of sensors with certain properties,
such as measurement accuracy, and then any instance of this class will
share the same accuracy, thereby making the class act more like the
datasheet we discussed. I sent you an example by email.
Jano
…On Sun, Jun 16, 2024 at 5:03 AM Simon Cox ***@***.***> wrote:
@kjano <https://github.com/kjano> wrote
I have not yet seen an example where this cannot be done via patterns,
CGI, metamodeling, etc.
We have known how to deal with most of these cases since Noy's work 20
years ago.
Could you spell out some small examples please?
—
Reply to this email directly, view it on GitHub
<#107 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANMP5ULLITKD6C7OWMZDVLZHT6ARAVCNFSM6AAAAAA6PIEVEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRGAZDKMZXGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
If the couple <*>Kind and <*>Instance are created, I would try to avoid making them subclass of the <*> class. <*>Kinds are abstract entities (e.g., datasheets) and <*>Instances are physical ones. The class <*> would be something that represents both abstract and physical entities:
Also, creating this structure for FeaturesOfInterest, Systems, Sensors, Actuators, etc. would make SOSA not so straightforward as already mentioned. I would move all the <*>Kinds to some existing module. For example, for me this information about <*>Kinds fits well in the "System Capabilities" module (at least for SystemKinds). For the rest of kinds, maybe we have to ask ourselves is SOSA/SSN is the ontology to be used to represent (for example) kinds of features of interest. In other words, is it in our requirements to cover this? |
|
I'm writing this after an extra-ordinary Sosa session that @rob-metalinkage and myself had last night over a few drinks. I think we were on our way to solving all the world's problems before I had to run and catch a train. My understanding of the System + SystemKind or Sensor + SensorKind is this: However, it seems to me we are not using the RDF/OWL tools already available. Sub-classing would make things a lot easier using established type / subclass patterns (PR #196 works like this).
As @kjano noted, the addition of OWL restrictions by implementers can force all sensors to share the same characteristics or can allow for local properties to document the idiosyncrasies of individual sensors. To my mind, a data sheet is a human oriented document that Sosa should reference without specifying a format. I'd suggest using As an implementer, I really want a normative property to link I don't think we are all far apart; it's the linkages between the things that is tricky. |
|
How about using |
|
Apologies for letting this sit a week. I believe I now understand what @kjano is proposing, and broadly how it relates to the sketch by @oldskeptic immediately above. Pattern A. Here is an InkBird example done using sub-classing: <https://example.org/sensor/IBS-TH2> rdf:type owl:Class ;
rdfs:subClassOf sosa:Sensor ;
gs1:pip <https://inkbird.com/products/hygrometer-ibs-th2> ;
rdfs:label "Bluetooth Temperature and Humidity Sensor IBS-TH2" ;
skos:notation "IBS-TH2" ; skos:note "using skos:notation for the model number " ;
sosa:observes <http://qudt.org/vocab/quantitykind/Temperature> ;
system:hasSystemCapability [ ... details omitted ... ] ;
.
<https://example.org/sensorInstance/IBS-TH2-56> rdf:type <https://example.org/sensor/IBS-TH2> ;
skos:notation "12gth456a-23190" ; skos:note "using skos:notation for the serial number " ;
.
<https://example.org/observation/O-3451> rdf:type sosa:Observation ;
sosa:observedProperty <http://qudt.org/vocab/quantitykind/Temperature> ;
sosa:madeBySensor <https://example.org/sensorInstance/IBS-TH2-56> ;
sosa:resultTime "2024-06-21T15:33:00.00+10:00" ;
sosa:hasSimpleResult "19.4"^^unit:DEG_C ;
. Here's a visual representation (@oldskeptic I think you have some arrows the wrong way round.) Pattern B. Compare this with the same example done using the proposed <https://example.org/sensorKind/IBS-TH2> rdf:type sosa:SensorKind ;
gs1:pip <https://inkbird.com/products/hygrometer-ibs-th2> ;
rdfs:label "Bluetooth Temperature and Humidity Sensor IBS-TH2" ;
skos:notation "IBS-TH2" ; skos:note "using skos:notation for the model number " ;
sosa:observes <http://qudt.org/vocab/quantitykind/Temperature> ;
system:hasSystemCapability [ ... details omitted ... ] ;
.
<https://example.org/sensorInstance/IBS-TH2-56> rdf:type sosa:SensorInstance ;
sosa:ofSystemKind <https://example.org/sensorKind/IBS-TH2> ;
skos:notation "12gth456a-23190" ; skos:note "using skos:notation for the serial number " ;
.
<https://example.org/observation/O-3451> rdf:type sosa:Observation ;
sosa:observedProperty <http://qudt.org/vocab/quantitykind/Temperature> ;
sosa:madeBySensor <https://example.org/sensorInstance/IBS-TH2-56> ;
sosa:resultTime "2024-06-21T15:33:00.00+10:00" ;
sosa:hasSimpleResult "19.4"^^unit:DEG_C ;
.
The a-box in the bottom half of the diagrams are essentially isomorphic. Since there is no actual benefit from introducing the However, some thought is required over the domains and ranges of some of the predicates, in particular:
Finally, it means that a register of Sensor kinds would be populated by OWL classes not OWL individuals. |
|
@dr-shorthair Thanks Simon for the detailed example. I think using individuals for instances and classes for types makes a lot of sense, as it follows general OWL practices. I don't mind dropping the If we do stick with pattern A, is there still a need for clarification about property ranges in this case? For example, will Also I think some of the issues come up in the |
|
For datasheets modeled as classes, the capabilities would be expressed as owl:Restrictions. (Note: a simplified version in #107 (comment) was subsequently developed, which improves on the first part of this code) <https://example.org/sensor/IBS-TH2-Plus>
a owl:Class ;
dcterms:isVersionOf <https://inkbird.com/products/ibs-th2-plus> ;
rdfs:comment """
An InkBird IBS-TH2-Plus is a combined Temperature/RH sensor.
Here I have modeled the whole thing as a System with a SubSystem for each of temperature and RH
""" ;
rdfs:label "IBS-TH2 PLUS Temperature and Humidity Sensor System" ;
rdfs:subClassOf sosa:System ;
rdfs:subClassOf [
a owl:Restriction ;
rdfs:comment """
In this Restriction I'm trying to say that every instance of IBS-TH2-Plus
- must have two sub-systems
- the value of one sub-system must be an instance of IBS-TH2-Plus-T - a temperature Sensor
- the value of the other sub-system must be an instance of IBS-TH2-Plus-H - a relative-humidity sensor
I don't think I've got there yet
""" ;
owl:allValuesFrom [
a owl:Class ;
owl:unionOf (
[
a owl:Restriction ;
owl:hasValue [
a owl:Class ;
owl:oneOf (
<https://example.org/sensor/IBS-TH2-Plus-T>
) ;
] ;
owl:onProperty sosa:hasSubSystem ;
]
[
a owl:Restriction ;
owl:hasValue [
a owl:Class ;
owl:oneOf (
<https://example.org/sensor/IBS-TH2-Plus-H>
) ;
] ;
owl:onProperty sosa:hasSubSystem ;
]
) ;
] ;
owl:cardinality "2"^^xsd:nonNegativeInteger ;
owl:onProperty sosa:hasSubSystem ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
rdfs:comment """
This Restriction says that every instance of IBS-TH2-Plus has the same overall system capability,
relating to sampling frequency
""" ;
owl:hasValue <https://example.org/sensor/IBS-TH2-Plus/systemCapability> ;
owl:onProperty system:hasSystemCapability ;
] ;
prov:wasDerivedFrom <https://inkbird.com/products/ibs-th2-plus> ;
.
<https://example.org/sensor/IBS-TH2-Plus-H>
a owl:Class ;
rdfs:label "IBS-TH2 PLUS Humidity Sensor type" ;
rdfs:subClassOf sosa:Sensor ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue <http://qudt.org/vocab/quantitykind/RelativeHumidity> ;
owl:onProperty sosa:observes ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue <https://example.org/sensor/IBS-TH2-H/systemCapability> ;
owl:onProperty system:hasSystemCapability ;
] ;
.
<https://example.org/sensor/IBS-TH2-Plus-T>
a owl:Class ;
rdfs:label "IBS-TH2 PLUS Temperature Sensor type" ;
rdfs:subClassOf sosa:Sensor ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue <http://qudt.org/vocab/quantitykind/Temperature> ;
owl:onProperty sosa:observes ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue <https://example.org/sensor/IBS-TH2-T/systemCapability> ;
owl:onProperty system:hasSystemCapability ;
] ;
.
<https://example.org/sensor/IBS-TH2-Plus/systemCapability>
a system:SystemCapability ;
system:hasSystemProperty [
a system:Frequency ;
schema:maxValue "0.1"^^unit:HZ ;
schema:minValue "5.556e-4"^^unit:HZ ;
rdfs:comment """
This SystemCapability describes the range of sampling frequencies available.
It could also be modelled as an enumeration of specific values
""" ;
] ;
.
<https://example.org/sensor/IBS-TH2-H/systemCapability>
a system:SystemCapability ;
system:hasSystemProperty [
a system:Accuracy ;
schema:value "4.5"^^unit:PERCENT_RH ;
] ;
system:hasSystemProperty [
a system:MeasurementRange ;
schema:maxValue "99.0"^^unit:PERCENT_RH ;
schema:minValue "0.0"^^unit:PERCENT_RH ;
] ;
.
<https://example.org/sensor/IBS-TH2-T/systemCapability>
a system:SystemCapability ;
system:hasSystemProperty [
a system:Accuracy ;
schema:value "0.5"^^unit:DEG_C ;
] ;
system:hasSystemProperty [
a system:MeasurementRange ;
schema:maxValue "60.0"^^unit:DEG_C ;
schema:minValue "-40.0"^^unit:DEG_C ;
] ;
. |
|
Consensus of 2024-06-26 telecon (+ @alexrobin asynchronously) is to proceed with Pattern A. - i.e. system-types (data-sheets) are subclasses of
|
|
@kjano could you confirm that I got it right in #107 (comment) |
|
and is there something better than |
|
The version above is possibly overcomplicating. <https://example.org/sensor/IBS-TH2-Plus>
a owl:Class ;
rdfs:label "IBS-TH2 PLUS Temperature and Humidity Sensor System" ;
rdfs:subClassOf sosa:System ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue <https://example.org/sensor/IBS-TH2-Plus/systemCapability> ;
owl:onProperty system:hasSystemCapability ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:cardinality "2"^^xsd:nonNegativeInteger ;
owl:onProperty sosa:hasSubSystem ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty sosa:hasSubSystem ;
owl:someValuesFrom <https://example.org/sensor/IBS-TH2-Plus-H> ;
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty sosa:hasSubSystem ;
owl:someValuesFrom <https://example.org/sensor/IBS-TH2-Plus-T> ;
] ;
prov:wasDerivedFrom <https://inkbird.com/products/ibs-th2-plus> ;
.This says:
I think this is pretty close to what we want. Cross-references are to the same things shown above. @oldskeptic I went with https://inkbird.com/products/ibs-th2-plus because the spec-sheet is more explicit |
|
I've had a go at documenting this, with some examples. See previews at |
dr-shorthair
changed the title
sosa:SystemKind and sosa:SystemOfInterest
|
Using rdf:type will not allow systems that use rdf:subClassOf reasoning to forward chain/entail to determine which value of rdf:type references the specific objectType. Agree we dont need a SystemKind class. |
|
I'm unhappy with the result. Recommending to use OWL for simple descriptions seems to me like pushing out of the way a lot of interesting use cases for SOSA. The description in #107 (comment) is not something I feel comfortable to recommend to anyone. The one in #107 (comment) is OWL full because of cardinality=2 Note that if we apply the same decision to properties, this would mean taxonomies of properties should be rewritten as hierarchies of property classes... This seems like a double standards policy Plus, datasheets describe archetypes of sensors. We cannot be sure that a specific instance of a sensor will conserve over time the characteristics specified in its datasheet. |
|
Maxime, I think that you are misinterpreting it. We're designing it to allow OWL for complex descriptions; the problem with SystemKind was that it was fundamentally re-creating For properties, we have the following use cases:
The example shows how case 2 can be documented by OWL, through other implementers will enumerate this using rdfs only. The examples aren't normative but they communicate how Sosa can leverage OWL/RDFS to deal with and document operating conditions that are usually buried in a report narrative. We have not addressed this in the current version of Sosa and this is a pattern that applies to #221 also. Some implementations assume that accuracy and precision properties apply to all results evenly. Obviously, this isn't so for use cases such as GPS readings where both vary across results. The example demonstrate owl-full, the rule could just as well be encoded in the software generating the rdf. |
I have updated the Mums-clinical-thermometer example so that the individual refers to all the classes up the hierarchy - simulating the closure I think you were concerned about. Then this relatively simple SPARQL query can find the 'most specialized type' for the thermometer: SELECT *
WHERE
{
ex:Mums-clinical-thermometer rdf:type ?c .
FILTER NOT EXISTS {
?s rdfs:subClassOf ?c .
}
}The result is Is that OK @rob-metalinkage ? |
Indeed. However, the description of the individual can add system capabilities to the ones specified for the class. If these are within the ranges specified on the class (archetype), then that's fine. If they conflict with the class, then the individual is no longer a member of the class (i.e. does not conform to the archetype) so should not make that claim. |
In practice we could drop the cardinality restriction with only minor loss of detail for this example. Many variations in the dialects of OWL and even SHACL will be used for the description of system-types. I can imagine that some users would just drop some text into a comment or description. The degree of support for reasoning within the graph will vary similarly. The intention of the examples here is merely to illustrate the general principle, for those OWL-ish users who want to approach it that way, that specialized sensors types can be represented as subclasses of |
|
This is a fair bit of work to find the most specific type, compared to a simple non-transitive property. There is no need for SPARQL in many applications, where graph traversal can be done in other ways. This is introducing a significant implementation burden compared to accessing a known property IMHO. Also I don't think you can assume there are no subclasses of the specific type - even more specific types. So the SPARQL would need to be more like SELECT *
WHERE
{
ex:Mums-clinical-thermometer rdf:type ?c .
FILTER NOT EXISTS {
ex:Mums-clinical-thermometer rdf:type ?s .
?s rdfs:subClassOf ?c .
}
}```
|
|
A corollary would be an entailment rule for a node ($this) CONSTRUCT $this sosa:systemKind ?c
WHERE
{
$this rdf:type ?c .
FILTER NOT EXISTS {
?s rdf:type ?s .
?s rdfs:subClassOf ?c .
}
}```
|
|
Thanks for that correction @rob-metalinkage - indeed, my version would find additional sub-classes below the ones associated with $this. Your correction fixes that. Thinking about the proposed sosa:hasSystemKind
rdf:type rdf:Property ;
rdfs:subPropertyOf rdf:type ;
.
sosa:System
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:hasValue sosa:System ;
owl:onProperty sosa:hasSystemKind ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
owl:onProperty sosa:hasSystemKind ;
] ;
.The prototype So how do we fix the behaviour of
Any other suggestions? |
I can see people trying to use multiple hierarchies of SystemTypes which would recreate the same problem. |
|
I'd like to progress this issue please. |
It is still unclear when one wants to model a generic kind of system (aka, model, category, class, ...), whether they should model it as an instance of
ssn:System, or a subclass ofssn:System.As
ssn:Systemis a superclass ofsosa:Sensor,sosa:Actuator,sosa:Sampler, this confusion also applies to these class.This ambiguity is reported in https://www.w3.org/TR/vocab-ssn/#SSNSystem-instances
In the SOSA/SSN examples, systems/sensors/actuators sometimes model generic sensor kinds, and sometimes a unique actual instance of sensor:
<sensor/35-207306-844818-0/BMP282>as the actual instance of a BMP282 high-precision barometric pressure sensor hosted on the iphone with IMEI 35-207306-844818-0.<HUMICAP-H>which is a kind of Vaisala HUMICAP H-chip, a model of accurate temperature and relative humidity probe<http://www.csiro.au/people/ps205.html>,<http://www.example.org/register/process/scales34.xml>,<http://www.example.org/party/individual/abc123>,<urn:ogc:object:feature:Sensor:NASA:xyz345>It would help a lot to be able to identify kinds of systems generically, the same way we do with property kinds. One advantage would be that we could reuse existing code lists, vocabularies, and taxonomies. Identifiers could be for example:
urn:epc:class:lgtin:061414.0100000.987654321GFEDCBAurn:epc:id:sgtin:061414.0100000.ABCDE12345Another advantage is that it would encourage manufacturers and vendors to define permanent URIs for their devices, and to expose structured data at the page that describes a device in a catalogue. Some examples of product IDs from manufacturer and vendor catalogues:
My proposal to disambiguate the concept while maintaining backward compatibility with previous usages would be to split
ssn:Systemin two classes:sosa:SystemOfInterestSystem is a unit of abstraction for real-world pieces of infrastructure that implement Procedures. A System may have components, its subsystems, which are other Systems.
By the way, we should extend this definition to account for use cases when one wants to identify the digital twin of a system using that same class in SOSA (the digital model of a system of interest is also a system of interest).
sosa:SystemKindAn instance of
sosa:SystemKinddescribes a datasheet, vendor specification, or normative specification, of a sensor (in the sense of a prototypical description).EXAMPLE: system with European Union energy label A++ , Energy Star labeled appliance, BMP282, DHT22, Adafruit 5187, ...
NOTE: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of
sosa:SystemKind.NOTE: alternative names could be:
sosa:SystemModel,sosa:SystemType, ...The text was updated successfully, but these errors were encountered: