Related, but not the same.
http://def.isotc211.org/iso19156/2011/Observation#OM_Observation identifies the UML class from the 2011 ISO standard.
http://www.w3.org/ns/sosa/Observation identifies the OWL Class from the 2017 W3C/OGC ontology.

They are intended to both be implementations of the same notion, but there are some differences in detail.

On the ISO side, https://isotc211.geolexica.org/concepts/1442/ identifies the concept of which http://def.isotc211.org/iso19156/2011/Observation#OM_Observation is the UML realization.

I'm not sure of the relationship between the SOSA & ISO 19156 concepts, whether anyone authoritative would consider them equivalent.

@dr-shorthair and @PeterParslow thanks for the feedback.

This clarifies it for me.

I think this is somewhat more complicated - depending on what you mean by "equivalent" and "realize" - I would say SOSA is a realisation of ISO 19156, but extends it in some ways on the other hand. OGC's Observations and Measurements version 3 is explictly semantically aligned with these extensions - so this is "more true". I wouldnt call the UML for 19156 a realization on the other hand - its the normative model - the OWL equivalent is a realization perhaps. Both SOSA and ISO1956 -as-owl could be seen as logical models derived from the same conceptual model - what relation you would use to describe this is not obvious - we model this explicitly in the OGC's knowledge graph....

I would say rather that https://isotc211.geolexica.org/concepts/1442/ identifies the concept which is the (would be SKOS in a perfect world) realisation of the http://def.isotc211.org/iso19156/2011/Observation#OM_Observation identifier for the UML object.

For OGC we are using content-negotiation-by profile to have the same URI for model elements resolve to both SKOS and OWL (and other forms) of the model - but we are looking at how to add explicit relations to these alternatives. Its not owl:sameAS - and rdfs:seeAlso is a bit weak - prov:wasDerivedFrom might be better.

(of course SOSA being a joint OGC/W3C specification in a W3C namespace its harder to make it behave the way we want to ... but nevertheless understanding the most useful and explicit approach is something we can put into a knowledge graph that does link these different components and alternatives.)

I get the point that ISO 19156 is the normative thing. My understanding of what we are trying to achieve in ISO/TC 211, as one of the candidate "ISO SMART" projects is to abstract normative concepts from existing standards and make those normative - with the UML class then being one realization (or whatever you want to call it) of the concept. A SKOS serialisation would be another. I'm not actually certain that that is how Kathie sees it in her ongoing revision of ISO 19156 - one for discussion.

Then there's the question of what the relationship is between the concepts at OGC/W3C and ISO, and the various representations of those concepts. I agree that the existing owl:sameAs and rdfs:seeAlso don't seem to capture them.

@PeterParslow - having a register of concepts as normative is good - we should explore optimising the behaviour of the URIs in terms of support for content negotiation (effective functionality) and interoperability - whilst we have focussed on this at OGC there is no wider consensus for interoperability across any coherent Web architecture. We should have a joint ISO/W3C/OGC meeting and progress this IMHO if you want to establish this as "normative".

Two other points on this, Rob. TC 211's Geolexica is already authoritative as a terminology register. What we (well, some of us) are trying to achieve is the inversion from having the document / words / terms as normative, to having the concept as the core matter, with terms, UML classes, OWL classes as representations of the concepts. In my view, this can work at may levels - conceptual, logical, physical (to adopt for now that terminology).

It would be good to work with W3C & OGC on this, but we are also working with others in ISO (through the "ISO SMART" project) in this direction. In this case, "SMART" stands for something like "standards (that are) machine-readable/interpretable, accessible, reusable, translatable" - i.e. not PDF files with pictures in :). The TC211 Multi-lingual glossary published at GeoLexica has been accepted as a good exemplar of the direction they want to go.

While my original question has been addressed, I am reading this interaction with great interest.

@PeterParslow, I think the challenges discussed here are also part of a wider concern.

I am part of the Open Standards For Linked Organisations ( OSLO ) data interoperability program of the Flemish region in Belgium. In there we cocreate with the Flemish community (public administration, businesses, academics and citizens) data standards to be used by the Flemish administration. We have adopted the semantic web as technological backbone to make our standards SMART. Today the program has adopted 1000's of terms (see https://data.vlaanderen.be and more specifically for a list of data standards https://data.vlaanderen.be/standaarden). Our basis a simplified UML with annotations which is translated into the desired artefacts (html, RDF, SHACL, JSON-LD, ...). (See https://github.com/Informatievlaanderen/OSLO-publicationenvironment-template as entrypoint to the automation setup).
Maybe our experience can be helpful for the ISO SMART project.

And in particular I believe the challenge of reuse is of interest here. A foundational aspect of a new data standard design of an OSLO data standards is the investigation and thus possible reuse of existing standards. When possible an OSLO data standard is merely a Flemish/Belgian interpretation of an EU/International standard. And there it is not always so easy. One of the challenges OSLO encounters is that the OSLO approach assumes a/relies on a strong Semantic Web enabled representation of the international standard: namely persistent dereferenceable URIs. And since those are not always present the reuse is made more difficult.

This topic of reuse is actually the key question for me in such an activity. I am not sure if the data standard community is agreeing on the reuse patterns: is cherry picking allowed, does it implies the adoption of the associated constraints as domain, range and cardinality, does it imply the import of the whole vocabulary or not?

Btw, the same discussion happens throughout the EU data interoperability programs. I am supporting also SEMIC and exactly the same discussions pop up at the level and within the interaction with EU member states.

It is an interesting puzzle how to have the gears of the standards hook into eachother so that at the same time flexibility and correct interpretation are maintained.

Cool thread! Some thoughts:

@PeterParslow : On https://isotc211.geolexica.org/concepts/1442/, to my understanding, Geolexica is a vocabulary extracted from the Terminology sections of the various TC211 standards. When reworking 19156 I remember there initially being issues in having definitions aligned with classes, reached the agreement with Reese that we keep the text parallel between the definition in the Terminology section and the requirement defining the class, but as this was a point of discussion, assuming currently no clear practice on this. Also, not all classes defined in 19156 even have a definition, so not sure if this approach currently works

@rob-metalinkage : This is reminding me we really need to restart the work on generating OMS for the OGC Modspec encoding. I've been thinking on using this as the source reference for a JSON-LD version of the OMS encoding as each OMS class has a corresponding RequirementsClass (with the parallel text to the definition as described above)

Think the modspec approach would also be in line with the "SMART" idea mentioned by Peter

So - we need a meta-level ontology for how these things (that have identifiers) should be defined and have relationships. IMHO identity is tied up in a social contract around acceptance of the registration authority and procedures - so ideally we could map ISO 19135 roles to each of these. If SMART has some governance that spans SDO (standards development org) boundaries, and is able to publish such an ontology, and its governance domain can include ISO TC211, then its not a bad place to start - otherwise we should explore a W3C group to deal with the on-the-web expectations of how these things behave.

@KathiSchleidt wrote:

This is reminding me we really need to restart the work on generating OMS for the OGC Modspec encoding. I've been thinking on using this as the source reference for a JSON-LD version of the OMS encoding

Just a side-question as this is also of interest to the SOSA/SSN community: why create a JSON-LD version of OMS as an entirely new thing when SOSA/SSN is already there? Why not work on an updated version of SSN instead? The difference isn't that significant as I recall. Having a separate OMS-JSON-LD would create confusion IMO.

This is a role for a logical model - to support multiple encodings (e.g. owl/rdf and json-ld) with a complete round-trip interchangeability. I agree that it is also a good idea in the process to make any updates to SOSA/SSN needed to track the OMS conceptual/abstract model.

@lvdbrink : where possible, we plan on using concepts from SOSA/SSN. However, where we've added new concepts to OMS not covered by the current SOSA/SSN (e.g., ObservingCapability), we're looking for alternatives. Long-term goal is updating SOSA/SSN accordingly, but as we really need an updated JSON encoding ASAP, we'd prefer to start this work now, update the @context once SOSA/SSN has evolved.

@lieberjosh : as you mention logical model, a question on where you see this level between conceptual and physical. Background is a discussion we have under OGC OMS based on experiences by the WMO in integrating OMS (the diagrams get really ugly as one must include both the conceptual and abstract levels of OMS), our idea is to create a [profile|logical model] where we leave out the interfaces from the conceptual model, provide the associations between abstract classes. I'd been seeing this as a logical version of the OMS conceptual model, but was told that it's a profile. Any insights from your side?

This is complex of course.. it would be good to have it as a focus for testbed activities to get a criticsl mass of experiences and perspectives. All in all we need to be clear what "work" different levels of abstraction are intended to do. Personally I think making progress via a sosa update proposal rather than a separately governed domain introduces less complexity downstream. We rarely acheive faster progress by confusing the landscape unless there is a significant block to work around. Is there?

@rob-metalinkage counter-question - what would be the time scale on updating SOSA/SSN with the new topics that evolved under 19156?

I'm definitely against creating yet-another-standard, but worry what waiting on SOSA/SSN updates will imply for our time-schedule creating an OMS encoding (we had planned on commencing this work once we've finalized the ISO text end of this month). Alternatively, we're also considering mapping OMS to the schema.org concepts CreateAction and/or Observation.

Ideally it wouldn't matter which of these concepts we align to if they're all aligned with each other - brings me back to my old question if there's any way of aligning SOSA/SSN with schema.org in a machine actionable manner? From what I've picked up, SEO focuses on schema.org, so worry if we nicely align to SOSA/SSN, we'll never be found again! ;)

Simon Cox already started this: https://www.w3.org/TR/vocab-ssn-ext/

I dont see why am updated draft couldn't be submitted anytime for consideration.

I'd like to see updates of examples and some better testing of the examples against the normative model :-)

We definitely could. The SDWWG has another year on it's charter, so we could host the work in this group / publish the result through this group, same as before. This could be either part of the extension @rob-metalinkage referenced, or of the main SSN standard which we are chartered to maintain. As long as we can consider this work to be 'maintenance'... And as long as people show up to do the work!

My point is, if people from the OMS group would commit to contributing to the work of updating SSN the work could be hosted in the SDWWG.

if people from the OMS group would commit to contributing to the work of updating SSN the work could be hosted in the SDWWG

+1 for doing this, we'll definitely touch the topic during the WaterQuality IE (https://github.com/opengeospatial/WaterQualityIE) and I now have colleagues + projects here to support the effort.

It does seem that WGIE is all OMS all the time ;>) so it would likely be worthwhile and perhaps help to more clearly delineate different (meta-) levels of OMS (e.g. conceptual-logical-physical) and their corresponding contributions to interoperability.

Successful submission of SSN-ext will depend on evidence-of-implementation.

We are developing that for ObservationCollections in TERN and BDR.
Not sure if we have enough for Ultimate-feature-of-interest yet.

And I would like to round it out with

• SampleCollection (a complex of samples)
• ActivityCollection (composite pattern on superclass of Observation, Sampling and Actuation).

The latter is particularly useful for things like SiteVisit or Project.

See alignment module in de SSN/SOSA spec: https://www.w3.org/TR/vocab-ssn/#OM_Alignment. There both classes are considered equivalent:

(Sorry to backtrack a few days - for some reason, I was blocked from parts of GitHub for three days!)

@bertvannuffelen: you are meeting an issue of re-using something in an environment "technically ahead of" the one it was designed for. We (TC 211) are aware that we need to catch up with contemporary web approaches to publishing reusable artefacts. Fortunately, Nick Car and Ivana Ivanovitch are working on that for us (Nick is also working with @rob-metalinkage , I think?)

@KathiSchleidt : we (TC 211) are tentatively transitioning & learning on the way. The terms vs classes discussion is a symptom of that. Current ISO practice understands terms, but doesn't really understand classes. ISO's "SMART" project will (hopefully) change this; IMHO, TC 211 is a bit ahead of ISO thinking on this - but not moving as fast as at least parts of OGC!

@PeterParslow

@bertvannuffelen: you are meeting an issue of re-using something in an environment "technically ahead of" the one it was designed for. We (TC 211) are aware that we need to catch up with contemporary web approaches to publishing reusable artefacts. Fortunately, Nick Car and Ivana Ivanovitch are working on that for us (Nick is also working with @rob-metalinkage , I think?)

Then I reach out at the right moment. I mentioned this thread to our team as a topic worth spending effort into. If we can assists in assessing publishing options, evaluating possibilities or even aid in brainstorming... As our data standards refer to ISO (and others too) a good reuse pattern makes our publishing stronger.

@nicholascar could you engage @bertvannuffelen in your TC 211 SKOS publication work?

Good morning/afternoon/evening folks. Great to see in depth discussion on this thread. I note comments about about pushing on with updates to SOSA/SSN. As @lvdbrink says, we could do this through SDWWG.

Would it help to have a (video) call to accelerate the discussion?

Our next plenary session is scheduled for 10-Nov. We're out-of-phase with UK/Europe and Australian time zones. Looking at time-and-date 7AM UTC looks the least offensive (8.00 CET, 18.00 AEDT).

If you'd like to use this time slot I can re-schedule for that time. (or you suggest to me another time). What do you think?

Hi all (@PeterParslow in particular). Yes, I see this post, so I'll reach out and inform of the work.

Any more takers for the offer to hold a plenary conversation at 7AM UTC, 10-Nov, on this subject? Particularly, to look at options for moving forward. I see a thumbs up from Rob A and Sylvain so far. Thanks. Jeremy

While its a painful time of the morning for me, I'll do my best to assure that at least my body attends! ;)

I’ll be dreaming about it @ 2am so spirit perhaps but no body.

I scheduled the meeting. See https://www.w3.org/events/meetings/54fb3c39-8826-418b-bcac-46e112f08535/20221110T090000

The meeting details are restricted to members, but in this case we want anyone who is interested in the topic to join. Drop me an email if you need the meeting details.

• If I understood correctly, it is being considered to define something like Observation as a skos:Concept rather than as a owl:Class? This is surprising because that would deviate from the definitions that can be found in the TC211 github right now, like for example this one.
• In Flanders we happily combined elements from both ISO19156 and SSN/SOSA in domains like soil and geology , water and air quality and others. For example ISO19156 for base elements like Observation, PropertyType, SamplingObject and SSN/SOSA for Sensors, Sampling. This could be done because both defined elements like classes with attributes, associations etc.
• Moreover: the important elements like Observation were declared owl:equivalentClass in an alignment module added to SSN/SOSA. There were some small differences indeed and utility classes to be able to better overlay both models. But I do not remember them to be prohibitive.
• If we talk about about what we can express with owl:Class vs skos:Concept, we assume that owl:Class is more expressive. In short: on the so called semantic continium classes are considered slightly superior in that respect. My interpretation was that skos:Concept is well suited for taxonomies and thesauri, while owl:Class is the real ontology thing.
• This is not because of the fact that they cannot represent the same thing, but rather that Classes offer extra features, they allow to use things things like rdfs:range and rdfs:domain, which if I am correct are inteded by rdf-schema to be used with Classes and not with Concepts.
• Same goes for rdf:type if I am not mistaken. Which means that you can say ex:Person rdf:type skos:Concept but not ex:Person123 rdf:type ex:Person. This is because skos:Concept is itself an owl:Class, so ex:Person is an owl:Individual (an instance of a Class), you cannot say that an Individual is an instance of an Individual (see paragraph on this in the skos specification).
• Now rdf:type is in my opinion all what linked data is about: we want to type objects. If we type ex:Person as a Class rather than a Concept and org1:Person123 and org2:Person456 are both typed as ex:Person, we can be sure that both objects are indeed Persons.
• If we typed ex:Person as a Concept, we could of course do something like: ex:Person123 rdf:type skos:Concept and ex:Person123 skos:broader ex:Person. But isn it much simpler then to be able to use owl:Class as a metaclass so that if ex:Person is defined as an owl:Class it can be instantiated just by saying ex:Person123 rdf:type ex:Person?
• That does not mean that defining certain terms as skos:Concept would not be useful. In Flanders we use the hybrid approach: skos:Concept for Enumeration values and classes etc for everything else. Of course it can be difficult sometimes to decide wether to define something as a Concept rather than as a Class.
• Another disadvantage of the hybrid approach is that in the long run you will end up with two sets of uri's for the same things. Maybe we need ex:Person as a Class for a population registry but would later like to define ex:Person as a Concept in an enumeration with types of Actors. In Flanders that kind of situations did not arise until now.
• There exists however an ontology that seems to take that possibility into account: the Data Privacy Vocabulary. There for the same things both a set of Concepts and a set of Classes is provided (each with their own uri's). We made an application profile on Consent that uses the Classes where needed and the Concepts for enumerations, so again the hybrid approach.
• Another possibility (with a caveat though) is explored in this article. There, apart from the hybrid approach explained earlier, a method to overlay SKOS with OWL is demonstrated by double typing, ie typing a term as a Concept and as a Class. Example: ex:Person rdf:type skos:Concept; ex:Person rdf:type owl:Class which would allow best of both worlds with one uri.
• In conclusion I would suggest that the ISO TC211 models remain with their first approach which is to define terms with owl:Class unless they are mere categorical values in which case skos:Concept is appropriate. So this is the hybrid approach. Moreover because the current models are already represented as Class diagrams so there is really no need to degrade expressivity.

The OGC uses the "double typing" - or polymorphic approach because every Concept is assumed to have one or more underlying descriptive models which may or may not be available. We choose to use owl:Class as the canonical model form for authoritative descriptive models (and avoid messy class equivalence) - so equivalent classes will need their own URIs and alignments.

So, at this stage I think the question is, as originally stated, what is the appropriate alignment predicate between these different artefacts?

The related question is how should these be cited (referenced) by external systems.

I think ISO concept register needs to be treated as metadata objects describing the normative objects - and the normative objects should support content-negotiation to provide machine readable artefacts, and hence be the correct things to cite in other machine readable contexts, however the concept register may be the correct thing to cite for human readable context... how to best describe this meta model and architectural assumption - or what alternatives make sense?

@GeertThijs's description seems in line with this https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

Similarly, https://isotc211.geolexica.org/concepts/1442/ provides TC 211's definition of the concept "Observation" (as SKOS, as well as in various natural languages). I think that's equivalent to one or more of the "Observation" concepts in the OGC Definitions server http://www.opengis.net/def/ogc-om/OM_Observation, http://www.opengis.net/def/ogc-om/om_observation, ... which are also available in SKOS & are tagged as exact matches for each other. I can see why we have OGC & TC211 definitions (less sure why there are so many OGC ones).

In https://github.com/ISO-TC211/ontologies/blob/main/iso19156/2011/Observation.rdf, we (TC 211) attempt a definition of Observation as a class. Nick Car is helping us redo that in a more web friendly way.

I think that is not unlike the "double typing" which Rob mentions as OGC's practice. We haven't yet agreed which to see as the canonical form - term, concept, OWL class, UML class,... I have my views, but need committee consensus.

SKOS is certainly useful for organizing "stuff" but it really does not carry any more meaning than that. skis:Concept does not have a deeper purpose than tagging things so that they can be arranged, so using this to somehow define the meaning of something like an observation does not do much to make it clearer to others. Using OWL classes is harder because something actually needs to be defined and in particular the logical predicates which do give them meaning, but the result will be more useful for both reasoning and communication.

To a certain extent this has been superceded by OMS decision to use the SOSA update as the canonical RDF representation vocabulary, and hence URIs.

Requirements for back-references to ISO and conformance classes in OMS as annotations supercede this. See #57

propose this can be closed and a specific ISO annotation task raised as an issue.

Agreed

Closed by #116 and #119 #136 #139