Feature-of-Interest or just Feature

[KathiSchleidt]

Do we want to leave Feature-of-Interest as a class, or reduce this to Feature.

Under STA, we've done exactly this, as we realized that of interest is not an characteristic of the feature itself, it's the role taken in the context of the Observation applied to this Feature.

However, in the semantic context, multiple derivation is far more common. Thus, we could also leave Feature-of-Interest as it is, provide guidance that in implementation, dedicated domain Feature-of-Interest types should be created through derivation from both Feature-of-Interest and the relevant domain feature.

Question: does this mean that one can only apply Observations to a Feature if it's also derived from Feature-of-Interest, or can we utilize any domain Feature here?

[sgrellet]

context to that issue is https://github.com/w3c/sdw-sosa-ssn/pull/228#issuecomment-2205647390 and the follow-up discussion during 2024-07-03 webconf

extracting/adapting my initial commment from here

on sosa:featureSampledBy*/ sosa:isUltimateFeatureOfInterestOf I hope I don't re-open an already long discussed topic. Do we need to scope the Domain of those 2 properties here ? From the 'FoI is a role/property not a class' discussion I feel that in many implementations sosa:hasSampledFeature will point to an instance defined in a domain model (ex in water : river, lake, aquifer) not by sosa:FeatureOfInterest only Or is it that we expect that instance (ex : French Catchment 'foo1') to be both a https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment and a sosa:FeatureOfInterest ?

[sgrellet]

discussion during "2024-07-03 webconf" pointed that

• indeed class polymorphism is the rule
• also that some guidance (to be written) should be added to the sosa:FeatureOfInterest section as to apply OWA and look for pre-existing domain ontologies rather before rushing into specialising FoI into a domain feature (river, aquifer, ...)

=> what is the W3C practice here ? for OGC/ISO OMS we had definition / note / example

=> extra question : guidance only to sosa:FeatureOfInterest ? or to other places as well (the point that triggered the discussion was on sosa:featureSampledBy*/ sosa:isUltimateFeatureOfInterestOf)

[sgrellet]

Question: does this mean that one can only apply Observations to a Feature if it's also derived from Feature-of-Interest, or can we utilize any domain Feature here?

good point Range for sosa:hasFeatureOfInterest is sosa:FeatureOfInterest (includes sosa:Sample ) while in OMS we left it open to Any Feature

[kjano]

Hi Kathi,

Question: does this mean that one can only apply Observations to a Feature if it's also derived from Feature-of-Interest, or can we utilize any domain Feature here?

(At least for now) SOSA does not use formal domain and range restrictions (but informal domain/range includes notions from schema.org. Thus, you can relate your observation to basically anything. A feature-of-interest could be a geographic entity like a lake, but it could also be a sample or even another sensor. Given that the term feature has so many meanings in so many different communities, I actually like FOI a lot (as well as Ultimate FOI). E.g., in data engineering, a lake's PH value would be a feature of a feature.

Cheers, Jano

[dr-shorthair]

@KathiSchleidt @sgrellet there are subtly different implications depending on whether you are using SOSA or SSN.

SOSA:

In SOSA the domain and range indications use the Schema.org predicates schema:domainIncludes and schema:rangeIncludes. In the case in question

sosa:hasFeatureOfInterest 
  schema:domainIncludes sosa:Execution ;
  schema:rangeIncludes sosa:FeatureOfInterest ;
.

1. These have no formal entailments, they are just hints
2. 'Includes' means these types are non-exclusive, so any other type is acceptable, including types from application-domains.

So the 'domain and range' indications in SOSA are functionally harmless. The fact that sosa:hasFeatureOfInterest schema:rangeIncludes sosa:FeatureOfInterest . merely says that things of type FeatureOfInterest might be found as the object of hasFeatureOfInterest statements. No more, no less.

SSN:

In SSN we specify local (guarded) restrictions, i.e. the range of the property when it appears in the context of a member of a specific class.

sosa:Execution 
  rdfs:subClassOf [ a owl:Restriction ; 
             owl:onProperty sosa:hasFeatureOfInterest ; 
             owl:allValuesFrom sosa:FeatureOfInterest ] ;
  rdfs:subClassOf [ a owl:Restriction ; 
             owl:onProperty sosa:hasUltimateFeatureOfInterest ; 
             owl:allValuesFrom sosa:FeatureOfInterest ] ;
.

This says that, in the context of an individual sosa:Execution, the object of a sosa:hasFeatureOfInterest is always a sosa:FeatureOfInterest.

However, this does not mean that the object of the statement must be declared to have rdf:type sosa:FeatureOfInterest in advance, and it does not mean that this is its only type.

Rather, it means that

• when an individual appears as the object of a statement
• whose subject is a sosa:Execution
• and whose predicate is sosa:hasFeatureOfInterest
• then it is automatically inferred to be of rdf:type sosa:FeatureOfInterest in addition to any other information that was already available about it, including any preexisting type.

Critically, this constraint does not require you to derive all domain types as sub-classes of sosa:FeatureOfInterest. In fact it could be argued that would be an error. It merely says that when a domain individual participates in an Execution (e.g. an Observation) it becomes a member of the class FeatureOfInterest in addition to any pre-existing domain class.

It is really useful to think in terms of sets and set intersections. Domain ClassA has a non-empty intersection with FeatureOfInterest only when a member of ClassA participates in an Execution. Domain types are not features-of-interest unless they are involved in executions, and the additional typing happens 'automatically', by entailment.

[dr-shorthair]

So my conclusion is that

1. the class sosa:FeatureOfInterest does no harm, and actually does have some utility - it is the class (set) of things that have participated in an Execution (Observation, Actuation, Sampling)
2. we should categorically steer clear of venturing down the path of defining an ur-class Feature - that is is metamodel territory (MOF, ISO 19109 or 19103) and is well beyond the scope of SSN/SOSA or OMS. The semantic world has owl:Class owl:Thing etc for its metamodel
3. it might be beneficial to let people know that they don't need to refer to FeatureOfInterest in advance of any executions, either
   • as the type of any individual,
   • and definitely not as the superclass of any domain-model class

[dr-shorthair]

Related #114

See earlier discussion there.

[kjano]

Great summary. In addition, (due to the OWA) any of these can also be missing as SOSA does not use cardinality restrictions. For example, we can record an observation without knowing the FOI or the sensor. Jano

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

So my conclusion is that

1. the class sosa:FeatureOfInterest does no harm, and actually does have some utility - it is the class (set) of things that have participated in an Execution (Observation, Actuation, Sampling)
2. we should categorically steer clear of venturing down the path of defining an ur-class Feature - that is is metamodel territory (ISO 19109 or 19103) and is well beyond the scope of SSN/SOSA or OMS. The semantic world has owl:Class owl:Thing etc filling that role
3. it might be beneficial to let people know that they don't need to refer to FeatureOfInterest in advance of any executions, either
   • as the type of any individual,
   • and definitely not as the superclass of any domain-model class

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

[sgrellet]

thanks @dr-shorthair and @kjano

'Includes' means these types are non-exclusive, so any other type is acceptable, including types from application-domains.

I was not sure about this, thus my questions. Your answers are perfectly fine with me.

"we should categorically steer clear of venturing down the path of defining an ur-class Feature - that is is metamodel territory"

also +1

As I just said in the webconf yesterday. Maybe it's a matter of writing something to actually "let people know" how to use FoI. I know we could claim RTFM/Spec + OWA but I feel a non-normative 'note' (if possible in W3C process) about all this FoI class definition

[dr-shorthair]

1. Add explanation to spec doc explaining class=set interpretation - in Common Modeling Questions section - cross reference from hasFoI
2. emphasize that domain-models are complementary to FoI - do not need to derive domain models from FoI
3. fix up use of word 'property' in examples
4. clarify relation to PropertyOfInterest etc.

[sgrellet]

sorry, wrong click

[dr-shorthair]

I've adapted this discussion into section in the Common Modeling Questions chapter: see https://raw.githack.com/w3c/sdw-sosa-ssn/232-domain-models-vs-feature-of-interest/ssn/index.html#model-domain

Now I'll add some links from the other sections.

[dr-shorthair]

See NOTE here @sgrellet @KathiSchleidt is that enough?

[KathiSchleidt]

Perfect! :)