Thread moved from #3

dr-shorthair commented 41 minutes ago
@rgcmme you have a point. I guess hasProperty domainIncludes both Sample and FeatureOfInterest?
Maybe open a separate issue ...

kjano commented 38 minutes ago
Keep in mind that this would force us to include sub-property axioms
which may or may not be a good idea, but last time we decided not to do so.

dr-shorthair commented 33 minutes ago
@kjano Which sub-properties?

kjano commented 28 minutes ago
If we have hasProperty, we would need to relate it to observedProperty
and so on. If I can /observe/ a property of a FOI, it /has/ said property.

dr-shorthair commented 20 minutes ago
I can see that there may be some rules involving property-chains, but they are non-trivial - not sure they can be expressed in OWL.

kjano commented 17 minutes ago
I would simply state that observedProperty is a sub-property of hasProperty.

dr-shorthair commented 13 minutes ago
DIfferent domains. Unless you are suggesting there is a subsumption relationship involving FOI and Observation?

If we move the hasProperty to SOSA we can still keep the sub-property definition in the SSN ontology. So we narrow the semantics of the property in SSN, as we do with some other classes/properties.

True, but we could express it with an annotation property (SubAnnotationPropertyOf) or just in the textual description? What are the complexity implications in terms of DL variant if we introduce a subproperty? Shouldn't change?

@kjano - in the discussion above you suggest that observedProperty is a sub-property of hasProperty.
I generated the diagram above to clarify that I don't think this is the case. Can you explain your argument?

It seems to me that the observedProperty is not a sub-property of hasProperty. They share the same range, and there are some implications that follow in a logically consistent sample and observation graph:
informally, something like--
If Observation(x).observedProperty.ObservableProperty(y) then
there exists Sample(z) such that Observation(x).hasFeatureOfInterest.Sample(z).hasProperty.ObservableProperty(y)
And
If Observation(x).hasUltimateFeatureOfInterest.FeatureOfInterest(a) then [FeatureOfInterest(a).hasProperty.ObservableProperty(y) And Sample(z).isSampleOf.FeatureOfInterest(a)]

To add my two cents:

If this is what we want to express:

If I can /observe/ a property of a FOI, it /has/ said property.

then this is how the inference may look like using SPARQL:

CONSTRUCT {
  ?foi ssn:hasProperty ?prop .
} WHERE {
  ?obs sosa:hasFeatureOfInterest ?foi .
  ?obs sosa:observedProperty ?prop .
}

In pseudo DL:

inverseOf( sosa:hasFeatureOfInterest ) o sosa:observedProperty ⊑ ssn:hasProperty

This can be expressed with a OWL subPropertyChainOf axiom:

ssn:hasProperty
  owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty ) .

This axiom doesn't change the complexity of the SSN ontology.

Proposed resolution as discussed in SDWIG f2f at Lyon TPAC - 2018-10-23:

RESOLUTION: After checking with other SSN editors, add an hasProperty property to the SOSA namespace, with an "ssn:hasProperty owl:equivalentProperty sosa:hasProperty" axiom, and "ssn:hasProperty owl:propertyChainAxiom ( [ owl:inverseOf sosa:hasFeatureOfInterest ] sosa:observedProperty )" as errata change

https://www.w3.org/2018/10/23-sdw-minutes.html#x05

Simon and I voted +1, along with 8 other IG members.

@arminhaller @kjano @danhlephuoc @KerryLea @rob-metalinkage @rgcmme @lieberjosh

If you are strongly against this proposal, please speak now or forever hold your peace :-)

I understand that all the changes mentioned in the resolution will be included in the errata.

Sounds good for me.

@maximelefrancois86
I would be against this change as discussed before as it leaves the other SOSA properties in the limbo. Also, the name is really misleading wrt rdf:hasProperty. A hasProperty property seems like the most generic term one could use and would, thus, not be considered good modeling practice. I am also unsure about the motivation for the propertyChainAxiom and particularly combined with the symmetric "ssn:hasProperty owl:equivalentProperty sosa:hasProperty" axiom. Is all we are trying to say that if an FOI has an observed property (via an observation) then this property is a property of the FOI?

I would be against this change as discussed before as it leaves the other SOSA properties in the limbo.

In what way?

Also, the name is really misleading wrt rdf:hasProperty.

I can't find rdf:hasProperty anywhere (or in RDFS either).

I agree that the name is very generic, but I think that is intentional. This really is intended to indicate that a FeatureOfInterest is characterized at least in part by this property. The definition is the same as ssn:hasProperty - hence the equivalence axiom - it is just that it is a bit of an outlier that this is not available to users of the core part of the vocabulary - i.e. SOSA.

Is all we are trying to say that if an FOI has an observed property (via an observation) then this property is a property of the FOI?

Yes. If an observation makes an estimate of an observed property, concerning a feature of interest, then that property must be an observable characteristic of the feature of interest.

The title of this issue should probably be changed to 'add hasProperty to SOSA namespace' - there is no suggestion that it should be removed from SSN.

The title of this issue should probably be changed to 'add hasProperty to SOSA namespace' - there is no suggestion that it should be removed from SSN.

I edited the title accordingly.

@kjano could you clarify your objections?

@KathiSchleidt @sgrellet is 'hasProperty' in OMS?
(I'm trying to streamline the tagging)

Or maybe it is (implied) in ISO 19109?

Sub-issue of #48
Resolved by #97