Closed alexrobin closed 1 year ago
numbered 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 No change to URIs of existing SOSA/SSN classes and properties.
a bit premature. We can state this as a goal, but must be aware that the required modifications may shift the semantics of some classes to the point where a new URI may be necessary.
@KathiSchleidt
Point 1
If you look at my changes to the ontology, you'll see that Observer
and Host
are in there, very much at the core of SOSA, and they are connected to other classes just like in the OMS model.
However, SOSA also had Sensor
and Platform
which more or less correspond to Observer
and Host
, but their name and definition sound slightly less general to me and, more importantly, they are also subclasses of System
. So basically, in this new version, a Sensor
is both an Observer
and a System
, and a Platform
is both a Host
and a System
. I only said Observer
and Host
are more abstract because they are not Systems
in the current version, which is not a requirement of OMS either, so I thought it actually keeps things cleaner and better aligned with OMS.
That said, I don't really mind making them Systems
too and perhaps change things so that Observer
is equivalent to Sensor
and Host
equivalent to Platform
if you think it's a better choice. I just assumed that if you used different names in OMS, it's because you wanted to keep these concepts a little more general that they were in SOSA.
Point 2
The Procedure
class was already defined in SOSA so I only added the specializations. The additional classes themselves are not the issue, however many associations were to Procedure
and not the corresponding specializations. In this version I made the associations more specific, just like on OMS (e.g. Observation
to ObservingProcedure
instead of simple Procedure
, etc.). However, this would probably break existing uses of the ontology. During our last call, both Jeremy and Linda were in favor of not introducing breaking changes so we should discuss other alternatives.
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
If you look at my changes to the ontology,...
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. If we have them in SOSA, it would be far easier to cleanly add to various domain models.
Point 5
While I appreciate aiming for backwards compatibility, even ontologies can evolve to new versions. I'm not sure if we're doing the community a service by making total backwards compatibility our highest goal
@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
rdfs:subClassOf
owl:Restriction
rdfs:subPropertyOf
schema:domainIncludes
schema:rangeIncludes
while SSN also used
rdfs:domain
rdfs:range
owl:Restriction
There were just a few classes in the SSN namespace
ssn:Deployment
ssn:Input
ssn:Output
ssn:Property
ssn:Stimulus
ssn:System
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 https://github.com/w3c/sdw/pull/1402#issuecomment-1512236705, 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 schema:domainIncludes
and schema:rangeIncludes
axioms while the SSN file tightens things further with owl:Restriction
.
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.
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 sosa-oms-alignment
I see no impediment to merging this PR.
It will make Alex's work more easily visible to the team using this repo.
(We may have preferred that the changes were factored into multiple PRs, so they could be evaluated separately.
But pragmatically we need to get this material visible in the main repo, and then we can perhaps implement changes to the working copy incrementally, converging on the sosa-oms-alignment
version as and when we agree on these.)
I wanted to point out that although all changes are in a single PR, I did create separate commits for each. This actually makes it easy to review the changes one by one after clicking the "Commits" tab of this PR.
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?