You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, we have OperatingProperty, SurvivalProperty, OperatingRange, SurvivalRange, hasSurvivalProperty, hasOperatingProperty, MeasurementRange.
Based on the above:
Question 1: Does it make sense to collapse hasSurvivalProperty / hasOperatingProperty to ssn:hasProperty since OperatingProperty and SurvivalProperty already exist?
Question 2: Does it make sense to subclass SurvivalProperty from OperatingProperty under the understanding that if the sensor is operating it has survived? @ldesousa made an interesting counter example of systems that go past their operating properties, like the Voyager Spacecraft. My thinking is that this is handled by the difference between the specification of the sensor and the instance of the sensor.
Question 3: Can we link SurvivalProperty and OperatingProperty to an sosa:ObservableProperty if only by documenting a design in the narrative, if not ontologically? The reason is that we don't provide a thing to measure in order to determine if the property has been violated. Common sense says that we should look at to the sosa:observes of the Sensor itself, but it is obvious that some sensors are affected by ancillary properties.
Furthermore:
Questions 4: Does it make sense to create a abstract class Range to do away with OperatingRange, SurvivalRange and MeasurementRange? This is a occurring pattern in the ontology.
The text was updated successfully, but these errors were encountered:
@oldskeptic These are my suggestions on these questions:
Q1: Makes sense if both OperatingProperty and SurvivalProperty are sub-classes of Property.
Q2: I would rather have both as sub-classes of the same (abstract) class, say Range.
Q3: I would say a "link" exists if all these are sub-classes of ssn:Property. As we live in the Semantic Web, it is fine to define an instance simultaneously of type SurvivalProperty and ObservableProperty. One or more examples could be furnished to make it clear.
Q4: Yes. However, such a generic class may already exist in one of the many ontologies specified by the W3C. Worth spending some time on this and re-use if possible.
Extra: Is there a circumstance where an instance of SurvivalProperty or OperatingProperty cannot be also an instance of ObservableProperty? If that can always be the case then consider making the former sub-classes of the later.
(This is part of #230 and comes out from this mornings meeting with @rob-metalinkage and @ldesousa )
Right now, we have OperatingProperty, SurvivalProperty, OperatingRange, SurvivalRange, hasSurvivalProperty, hasOperatingProperty, MeasurementRange.
Based on the above:
Question 1: Does it make sense to collapse hasSurvivalProperty / hasOperatingProperty to ssn:hasProperty since OperatingProperty and SurvivalProperty already exist?
Question 2: Does it make sense to subclass SurvivalProperty from OperatingProperty under the understanding that if the sensor is operating it has survived? @ldesousa made an interesting counter example of systems that go past their operating properties, like the Voyager Spacecraft. My thinking is that this is handled by the difference between the specification of the sensor and the instance of the sensor.
Question 3: Can we link SurvivalProperty and OperatingProperty to an sosa:ObservableProperty if only by documenting a design in the narrative, if not ontologically? The reason is that we don't provide a thing to measure in order to determine if the property has been violated. Common sense says that we should look at to the sosa:observes of the Sensor itself, but it is obvious that some sensors are affected by ancillary properties.
Furthermore:
Questions 4: Does it make sense to create a abstract class Range to do away with OperatingRange, SurvivalRange and MeasurementRange? This is a occurring pattern in the ontology.
The text was updated successfully, but these errors were encountered: