SSN integration: comments on options,

Its very useful IMHO to have reasons for votes provided - but i dont want
to keep nesting so have reverted back to email for now - but happy to put
these comments back inline

re votes on option 8:

Armin: 0. I would prefer this Option if SOSA:OWL-DL imports SOSA and SSN
SOSA:OWL-DL. That would void Point 7, but avoids users that don't really
understand OWL, but want a simple ontology, but still using an ontology
editors, getting all the complex OWL axioms when they just want to see a
simple SOSA ontology.

> tend to disagree - it is reasonable IMHO that only an OWL tool will
follow owl:imports, hence people only get the simple defs if they just want
a simple vocabulary.


Kerry: -1. I agree with Armin's comment but I am giving -1 because I really
don't think this separation is realistically possible. While it sounds
conceptually elegant, it will not work in our current situation. For
example, in the Platform case (https://www.w3.org/2015/spatial/wiki/Platform),
we have "sosa:hosts" refined by the axiom sosa:Platform rdfs:subClassOf [
owl:onProperty sosa:attachedSystem ; owl:allValuesFrom ssn:System]which is
both typing constraints and uses non-core terms at the same time. Accepting
such a separation would, perhaps, imply splitting this statement below into
multiple modules? Not nice.


> not at all - you simply put this SSN specific interpretation into SSN,
 because this cannot be a direct axiomitisation of SOSA semantics because
it mentions SSN.  AFAICT your objection just goes away. The underlying
question is whether SSN does need to define and name a genuine subclass for
restricted semantics.