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

[maximelefrancois86]

Just for the record, and related to #29 (comment)

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]

"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]

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]

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]

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]

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]

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

[hylkevds]

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]

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]

Is this issue still live?
@maximelefrancois86 @sgrellet

[dr-shorthair]

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]

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 <#232> Furthermore, the issue of whether SSN/SOSA should have classes for types or kinds was discussed at length in #107 <#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 <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANMP5TGPFTQ3B3C3QFPZXDZKT4WPAVCNFSM6AAAAAA6PRWYM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBYGMZDQMZTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>