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

RFC: SurvivalRange / OperatingRange / Range simplification? #239

Open
oldskeptic opened this issue Aug 7, 2024 · 3 comments
Open

RFC: SurvivalRange / OperatingRange / Range simplification? #239

oldskeptic opened this issue Aug 7, 2024 · 3 comments
Assignees
Labels
modularization question Further information is requested

Comments

@oldskeptic
Copy link
Contributor

(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.

untitled

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:
untitled

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.

@oldskeptic
Copy link
Contributor Author

@dr-shorthair I'm still working on my arrow directions ;)

@oldskeptic oldskeptic added question Further information is requested modularization labels Aug 7, 2024
@oldskeptic oldskeptic self-assigned this Aug 7, 2024
@ldesousa
Copy link
Contributor

@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.

@oldskeptic
Copy link
Contributor Author

From Oct/9/2024 telecom, move to PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
modularization question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants