"of interest" is only a role of features --- introduce `sosa:Feature` and `sosa:FeatureType` ?

maximelefrancois86 commented 11 months ago

Just for the record, and related to https://github.com/w3c/sdw-sosa-ssn/issues/29#issuecomment-1779470219

The OMS definition of Feature of Interest is: "subject of the observation". This is more a role name, than a class name. And there could be more than just one observation:

You aren't of interest until there is an observation about you.

Therefore, "feature of interest" would be fine in the name of an Object Property such as sosa:hasFeatureOfInterest, but not fine in the name of a class. It would be more canonical to stick to "sosa:Feature".

Now it's clear that sosa:FeatureOfInterest exists for a long time now, and everyone is used to use it as a class.

I take the opportunity to propose to include in SOSA/SSN the distinction that OMS makes about features, feature type, and feature of interest

This is related to #106 and #107

`sosa:Feature`

abstraction of real-world phenomena. NOTE: A feature can occur as a type or an instance.

`sosa:FeatureOfInterest`

~subject of the observation~ -> Actual real-world phenomena that can be the subject of an observation

`sosa:FeatureKind` (or `sosa:FeatureType`)

class of features having common characteristics

NOTE: Concepts from existing catalogues, code lists, vocabularies, and taxonomies, could be used as instances of sosa:FeatureKind.

sgrellet commented 10 months ago

"This is more a role name, than a class name."

Exactly

Now it's clear that sosa:FeatureOfInterest exists for a long time now, and everyone is used to use it as a class.

There is the same discussion in OGC SensorThings API SWG in the work targeting V2

To some extent this could make sense to have a placeholder class 'sosa:Feature' to which you could point to and express that it is 'ofInterest' (ex : sosa:hasFeatureOfInterest) in the context of an observation. This could help implementers start using SOSA without any other domain ontology (river, aquifer, soil etc...) to describe their own domain feature.

Another option (maybe more OWA), could be to model that any Thing (owl:Thing) could be 'ofInterest' to an observation. That's what we did in OMS; having the featureOfInterest role pointing to Any Feature (ISO 19103 most abstract element at hand to describe "abstraction of real-world phenomena")

dr-shorthair commented 10 months ago

There was a discussion of this back in 2015.

I think it was @kjano who argued that the FeatureOfInterest class had some utility in indicating that the entity/object/feature had participated in an act of Observation/Sampling/Actuation.

Since sosa:FeatureOfInterest has no properties unrelated to observations or sampling, it can be harmlessly added to an instance in an additional rdf:type triple to indicate that the thing in question is a member of both its 'natural' class and of FeatureOfInterest.

sgrellet commented 10 months ago

ok, I get it. but wouldn't that make more sense to have it named sosa:Feature ?

FYI : that's exactly what SensorThings API SWG decided recently for V2; then it will be for the associations to precise the role of that feature (uFoI, etc...)

dr-shorthair commented 9 months ago

wouldn't that make more sense to have it named sosa:Feature ?

Maybe, but in order to preserve backward compatibility, we don't change existing class or predicate names

maximelefrancois86 commented 9 months ago

I agree it's important to keep FeatureOfInterest as a class.

In SAREF, we chose to introduce saref:FeatureKind , and we did not introduce an upper class ~saref:Feature~

dr-shorthair commented 8 months ago

Is there a concrete proposal for this, or have we decided not to change?

hylkevds commented 8 months ago

If it's only for backwards compatibility we could deprecate its use? The same Feature can be an ultimateFeatureOfInterest, proximateFeatureOfInterest, SampledFeature and Sample all at the same time.

dr-shorthair commented 8 months ago

Sample is a useful class I think. It carries the defining property isSampleOf.

FeatureOfInterest has hasProperty axiomatized in the SSN graph. The more interesting property is isFeatureOfInterestOf but that does not appear in any axioms.

It could be deprecated I suppose, but I don't think it does any harm and could be perceptionally disruptive to suppress it now.

dr-shorthair commented 5 months ago

Is this issue still live? @maximelefrancois86 @sgrellet

dr-shorthair commented 3 months ago

Related #232

Furthermore, the issue of whether SSN/SOSA should have classes for types or kinds was discussed at length in #107. The conclusion there was that types or kinds should be implemented as OWL Classes (sub-classes of SOSA classes where appropriate) and individuals are linked to these using the standard rdf:type predicate.

I will close this issue if no objection by 2024-07-10.

kjano commented 3 months ago

I also favor closing this and following the suggestion of using OWL restrictions instead.

On Thu, Jul 4, 2024 at 9:46 AM Simon Cox @.***> wrote:

Related #232 https://github.com/w3c/sdw-sosa-ssn/issues/232

Furthermore, the issue of whether SSN/SOSA should have classes for types or kinds was discussed at length in #107 https://github.com/w3c/sdw-sosa-ssn/issues/107. The conclusion there was that types or kinds should be implemented as OWL Classes (sub-classes of SOSA classes where appropriate) and individuals are linked to these using the standard rdf:type predicate.

I will close this issue if no objection by 2024-07-10.

— Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/114#issuecomment-2208328335, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANMP5TGPFTQ3B3C3QFPZXDZKT4WPAVCNFSM6AAAAAA6PRWYM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBYGMZDQMZTGU . You are receiving this because you were mentioned.Message ID: @.***>

w3c / sdw-sosa-ssn