-
Notifications
You must be signed in to change notification settings - Fork 81
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
SOSA-OMS Alignment #1402
SOSA-OMS Alignment #1402
Conversation
Discussion Itemsnumbered for easier reference in such a lumped issue 1 Observer and Host are kept more abstract (they are not Systems). Is everybody OK with this? Not really, as they're a core part of the OMS model 2 More specific procedure types are introduced by OMS. I made the choice to reinforce the constraints on the existing properties to reflect this, but this is a breaking changes compared to the existing version. So we may prefer to keep the existing looser constraint, or create a separate sub-property with a stricter constraint (e.g. have both usedProcedure and usedObservingProcedure on Observation) Don't understand the issue in adding a more abstract Procedure, then specializing as done in OMS. How does this break the existing version? 3 Should we also add observableProperty association between ObservingProcedure and ObservableProperty? (requested by Sylvain Grellet). If we do, then we should also add the actuableProperty association between ActuationProcedure and ActuableProperty. This makes sense to me so we can discover procedures by property. Makes sense, in OMS you can only discover this link via the OMS:Observer. In addition, I'm all for keeping the core patterns between Observation, Actuation, Sampling aligned 4 SampleCollection could get common properties like ObservationCollection (e.g. same Sampler or same SamplingProcedure used for all samples in the collection). OMS doesn't define this, but should we do it here? Agreed. SampleCollection was not discussed enough in OMS. Creating SamplingCharacteristics parallel to the OMS:ObservationCharacteristics to describe the nature of the SampleCollection would be valuable. In addition, I find the decision to on |
Point 1 If you look at my changes to the ontology, you'll see that However, SOSA also had That said, I don't really mind making them Point 2 The Point 3 and 4 OK, we can discuss next time if we should do that at the same time as bringing OMS in or wait for the next revision. Regarding keeping URIs stable, I think it is an essential component of any ontology. Cf my previous comments about avoiding breaking changes for existing users. |
Point 1 To our view, Sensor is a subtype of Observer (this was based on long discussions we'd have over the years convincing people that O&M or SOSA can be used without a Sensor. The term Observer is more neutral) Why can't we slip the Observer concept between Sensor and System in the derivation hierarchy? I fail to see how Platform is a System in the current model, only associated to System
Where are these documented? Point 2 without access to your modified version of SOSA, it's difficult to judge if the inclusion of the specialized procedures would actually break existing applications. While I can see some reasoning issues ensuing, as the specialized procedures are all subtypes of Procedure, this should be alignable, I don't see the blocking point. Points 3&4 As O&M and SOSA have always been leapfrogging each other as they progress, I believe we should definitely investigate the proposed refinements that came up at the end of the OMS work Both the link between ObservingProcedure and ObservedProperty as well as the enriched SampleCollection would be most valuable. Point 5 While I appreciate aiming for backwards compatibility, even ontologies can evolve to new versions. |
@KathiSchleidt My modified version of SOSA/SSN is this PR |
Very pleased to see this discussion. |
Another set of concerns, SOSA was deliberately designed to stand-alone from SSN without the axioms and the non-OMS elements. With the extension of OMS scope, this line is now shifted. I dont think its safe or reasonable to make OMS dependent on SSN axioms and the necessary (and unspecified) reasoning profile to use any dependencies on SSN so I would propose we extend SOSA to include all the OMS classes we need - and make these subclasses of SSN equivalents, updating the alignment axioms in SSN. This should not affect anyone already committing to SSN and the level of reasoning required, but preserves the SOSA design philosophy. it may be necessary to have a telecon with myself and @dr-shorthair and others from the original SOSA design teams |
I think that SOSA used the following modeling predicates in axioms
while SSN also used
There were just a few classes in the SSN namespace
IMAO these should all be brought into the SOSA namespace, for simplicity. (Note that I minted all the SSN-extensions in the SOSA namespace for this reason - T-box ontologies have few enough classes that it really isn't necessary to segment by namespace and generally leads to unnecessary confusion.) Its fine for the SSN graph to hold all the higher-order axioms, but not necessary for any classes and properties to be in the SSN namespace. AFACT the classes that @alexrobin has added are all in the SOSA namespace anyway. It would only be subClass/subProperty relations with SSN classes and properties that may cause confusion ... |
Hi,
IMHO, we should start working on the next version anyways. I would
assume that SSN can be slowly phased out and SOSA can remain the minimal
core with EXT and other parts being added as modules as originally
envisioned. If I am not mistaken OMS was designed with knowledge of SOSA
anyways; so OMS could depend on SOSA but should not depend on SSN.
I am certainly game.
Jano
…On 4/18/23 01:34, Rob Atkinson wrote:
Another set of concerns,
SOSA was deliberately designed to stand-alone from SSN without the
axioms and the non-OMS elements.
With the extension of OMS scope, this line is now shifted. I dont
think its safe or reasonable to make OMS dependent on SSN axioms and
the necessary (and unspecified) reasoning profile to use any
dependencies on SSN
so I would propose we extend SOSA to include all the OMS classes we
need - and make these subclasses of SSN equivalents, updating the
alignment axioms in SSN. This should not affect anyone already
committing to SSN and the level of reasoning required, but preserves
the SOSA design philosophy.
it may be necessary to have a telecon with myself and @dr-shorthair
<https://github.com/dr-shorthair> and others from the original SOSA
design teams
—
Reply to this email directly, view it on GitHub
<#1402 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANMP5REVEJQ2ZCWXPE6QILXBXHRZANCNFSM6AAAAAAW5GBSFI>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
--
Krzysztof Janowicz
Professor for Geoinformatics, Director Center for Spatial Studies
Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060
***@***.***
Webpage:http://geog.ucsb.edu/~jano/
Semantic Web Journal:http://www.semantic-web-journal.net
|
@rob-metalinkage @dr-shorthair I don't know if you looked at the changes in the PR but I tried to follow the exact same patterns as the ones that were already employed in SOSA and SSN. This means the SOSA file defines classes and properties with loose constraints using Personally I like keeping the two namespaces separate. SOSA is a good abstract core while SSN brings more implementation level details. I think the only class that is in OMS and not in SOSA is Deployment. And so some relationships from SOSA namespace to Deployment may be an issue. Happy to have a telecon with the initial SOSA team to discuss design patterns. |
@kjano - OMS will be "expressed as" rather than "depend on" SOSA SOSA will be what I would call a "canonical logical model" for the OMS Conceptual Model - i.e. a lossless machine readable form that can be directly instantiated with instance data. As discussed will also define encoding bindings for SOSA as JSON, using JSON schema linked to JSON-LD. There may be multiple such schema bindings depending on the meta-model for encoding. https://github.com/opengeospatial/ogcapi-sosa has been setup to define an "OGC Building Block" form of an encoding - based on the GeoJSON (and FG-JSON extensions proposed) meta-model. Note that other meta-models could be implemented as well - such as the ODATA model used by SensorThingsAPI - but these may require formalism of equivalent logical models (e.g. ODATA) Note that this could become part of OMS - so we could rebrand SOSA and the SOSA-bb as sub-parts of OMS |
Hi folks. Glad to see we have this conversation going - and public too :-) ... Thankyou @alexrobin I don't have practical experience of using the SOSA, SSN, or OMS vocabs so I can't comment with authority on the discussion points above. But I do see that the experts are in the (virtual) room. What I do want to talk about is backward compatibility and examples ... Here are a few salient points from the SDW-WG plenary call back in Nov 2022:
The observed (observable?) property discussion was also picked up by @rob-metalinkage in the Joint Geosemantics DWG / SDW-WG session at the OGC Members meeting in Feb 2023. He was talking about establishing an "ObservableProperty register" to mitigate issues around "massive duplication and lack of federation in the wild". So. From my perspective, I think there are 3 pieces of work on the table:
I think point (1) is (at least partially) covered by this PR ( #1402 ) ... does it fix the examples? (should it?). Point (2) relates to the broader sematic uplift work being progressed within OGC. And point (3) is the subject of a OGC Discussion Paper that @rob-metalinkage is drafting ahead of the June OGC Members meeting. TL;DR ... we need to assess backward compatibility, we should fix examples, and there's some other work that's in the mix but out of scope. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes all look well aligned with OMS, and appropriately located in the two namespaces.
However, there may be challenges relating to 'evidence of implementation'.
We are doing large-scale SOSA-based Knowledge Graph data integration for the Geological Survey of Western Australia. This work will continue for the next 2 years and could provide implementation evidence for OMS. We are using ConnegP in at least one of the public APIs to the KG data, so OMS data could be delivered as a profile of the SOSA-based KG data, alongside pure SOSA. |
Since @alexrobin changed the base to |
(We may have preferred that the changes were factored into multiple PRs, so they could be evaluated separately. |
I wanted to point out that although all changes are in a single PR, I did create separate commits for each. Also, I don't know if you are aware that you can insert comments in the changed files of each commit to provide feedback on the proposed changes, directly in context. (to add a comment, just hover above the left margin when looking at the diff, and click on the + sign that appears) |
This is my initial attempt to merge SSN Extensions and OMS concepts into the SOSA/SSN Ontology.
Only Turtle files have been modified so far. RDF files are still the original version so they don't match. We can regenerate them automatically when ready.
The changes are recorded in readme.md.
Design Choices
Discussion Items
Observer
andHost
are kept more abstract (they are notSystems
). Is everybody OK with this?More specific procedure types are introduced by OMS. I made the choice to reinforce the constraints on the existing properties to reflect this, but this is a breaking changes compared to the existing version. So we may prefer to keep the existing looser constraint, or create a separate sub-property with a stricter constraint (e.g. have both
usedProcedure
andusedObservingProcedure
onObservation
)Should we also add
observableProperty
association betweenObservingProcedure
andObservableProperty
? (requested by Sylvain Grellet). If we do, then we should also add theactuableProperty
association betweenActuationProcedure
andActuableProperty
. This makes sense to me so we can discover procedures by property.SampleCollection
could get common properties likeObservationCollection
(e.g. sameSampler
or sameSamplingProcedure
used for all samples in the collection). OMS doesn't define this, but should we do it here?