Re: [sdw] iso 19156 URIs vs SSN/SOSA URIs (#1372)

- 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](https://github.com/ISO-TC211/ontologies/blob/main/iso19156/2011/Observation.rdf).
- In Flanders we happily [combined ](https://data.vlaanderen.be/doc/applicatieprofiel/sensoren-en-bemonstering/kandidaatstandaard/2022-04-28) elements from both [ISO19156](https://www.iso.org/standard/32574.html) and [SSN/SOSA](https://www.w3.org/TR/vocab-ssn/) in domains like soil and geology , [water and air quality](https://purl.eu/ns#Applicationprofile) 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](https://www.w3.org/TR/vocab-ssn/#OM_Alignment) 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](https://www.slideshare.net/TriviumRLG/from-taxonomies-to-ontologies?next_slideshow=1) 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](https://www.w3.org/TR/rdf-schema/#ch_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](https://www.w3.org/TR/skos-primer/#secskosowl) in the skos specification).
- Now rdf:type is in my opinion all what linked data is about: we want to type objects. By typing ex:Person as a Class rather than a Concept and org1:Person123 and org2:Person4546 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](https://w3c.github.io/dpv/dpv/). 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](https://purl.eu/doc/applicationprofile/consent/kandidaatstandaard/2022-11-01/index_en.html) 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](https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html). 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 as well 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 no need to degrade expressivity.         

-- 
GitHub Notification of comment by GeertThijs
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1372#issuecomment-1309390732 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 9 November 2022 21:23:16 UTC