Re: SSN - term-by-term integration is finished

Dear all,

Pull request x implements the changes proposed by Simon below, and more.
This is a proposal, no more. Please comment and tell me what to keep and
what not to keep.

The bottom of this mail lists some of the last important issues to be
discussed.

> 1. In O&M resultTime is required. Since observation/actuation/sampling is
now conceived of as an act or event,
> then it has a finish (and start time) by definition. I suggest that the
cardinality constraint on sosa:resultTime should be ‘exactly 1’.
> (OWA means that it may be missing in a particular representation, but
semantically it is known to exist.)

done for observation, actuation, sampling.

> 2. Similar for phenomenonTime for Observations at least.

Done for observation.

> 3. Similar for hasResult – each of these acts is pointless without a
result – I think we should indicate this with a ‘min 1’ restriction.

Done

> 4. Entailment of ‘min 0’ is a little unclear anyway, since that is the
default cardinality.

Removed.

> 5. Sampler needs to also be a subclass of
> a. ssn:System
> b. ssn:implements some sosa:Procedure

The pull request contains those.

> 6. Only one of these two restrictions on sosa:Procedure should be
present:
> ssn:hasOutput only ssn:Output
> ssn:hasOutput some ssn:Output
> Which one?

The pull request contains only the first one, to be consistent with Input.

> 7. Some combination of the following is required to bring sosa:Sampling
into consistency:
> a. sosa:hasResultingSample rdfs:subPropertyOf sosa:hasResult
> b. sosa:hasResultingSample rdfs:range sosa:Sample
> c. sosa:Sample rdfs:subClassOf sosa:Result

done, and also proposed:   sosa:Sample rdfs:subClassOf [ a owl:Restriction
; owl:onProperty sosa:isResultOf ; owl:someValuesFrom sosa:Sampling ] ;


> 8. I’m generally pretty comfortable with global rdfs:range constraints on
properties.
> Did we decide to not use them at all? It would halve the number of local
> restrictions/constraints on the classes.

I agree. I think this has been heavily debated. Yet again:
 - if a property is named sosa:hasProperty, I expect  the object to be a
Property
 - if a property has for definition: "Relation between a Procedure and an
Input to it.", then I expect the subject to be a Procedure and the object
to be an Input.

The pull request contains any domain and range axioms that can be suggested
by these situations. This can be discussed.


### other changes:

Considering the previous definition of forProperty, I made forProperty a
super property of observes.

As positive corollaries:
 - forProperty and ofFeature can be used to link instances of Actuation to
the Property that it acted on and its FeatureOfInterest.
 -  ofFeature can be used to link instances of Observation to the
FeatureOfInteret whose Property it observed
- ofFeature can be used to link instances of Sampling to the
FeatureOfInterest it sampled

### other changes:

I simplified and exemplified the descriptions for the Deployment module:

DeploymentRelatedProcess is deprecated (not used)
deploymentProcessPart is renamed deploymentPart

Definition of Deployment: Describes the Deployment of one or more Systems
for a particular purpose. Deployment may be done on a Platform, and consist
of sub-Deployment. For example, a temperature Sensor deployed on a wall, or
a whole network of Sensors deployed for an Observation campaign. The
Deployment may have deployment parts that describe on which platform
individual Systems are deployed.

### other changes:

I simplified, exemplified, and checked for the consistence of the
descriptions for the SystemCapability, OperatingRange, and SurvivalRange
modules. For example definition of OperatingRange is:

Describes normal OperatingProperties of a System under some specified
Conditions. For example, to the power requirement or maintenance schedule
of a System under a specified temperature range.
    In the absence of OperatingProperties, simply describes the Conditions
in which a System is expected to operate.
    The System continues to operate as defined using SystemCapability. If,
however, the SurvivalRange is violated, the System is 'damaged' and
SystemCapability specifications may no longer hold.


### one of the last issues to be discussed:

The following choices must be made for the ontology to be in OWL 2 DL:

1. Choose between (a) or (b):

>  (a) madeBySensor o implements sub-prop-of usedProcedure
       actuationMadeBy o implements sub-prop-of usedProcedure
       madeBySampler o implements sub-prop-of usedProcedure
 (b) Observation sub-cl-of =1.procedure
      Observation sub-cl-of =1.procedure
      Observation sub-cl-of =1.procedure

### one of the last issues to be discussed:

ObservationResultTime is equivalent to resultTime.
The former is an ObjectProperty, the latter is a DatatypeProperty.

This makes SSNX + SSN not a legal OWL ontology. We need to solve this.

### one of the last issues to be discussed:

We have Input, Output, Result, but no Command.
Command is quite important for Actuation, I propose to mimic the "Result"
module to create a "Command" one.

### Comment 1

I would have liked to add axiom:

InverseOf(forProperty) o ofFeature ) sub-prop-of isPropertyOf

but this axiom triggers 4 violations to OWL 2 DL. The best would have been
to not define the ofFeature property, which is already reachable through
the Property.


### Comment 2

The SSN ontology is not in OWL 2 EL, QL, nor RL. The following java snippet
that uses OWL API output the reasons why.

File root = new File("path-to-ssn-folder");*
OWLOntologyManager m = OWLManager.createOWLOntologyManager() ;
m.getIRIMappers().add(new SimpleIRIMapper(sosa, IRI.create(new File(root,
"integrated/sosa.ttl"))));
m.getIRIMappers().add(new SimpleIRIMapper(ssn, IRI.create(new File(root,
"integrated/ssn.ttl"))));
OWLOntology o = m.loadOntology(ssn);

OWL2ELProfile profile = new OWL2ELProfile();
OWL2QLProfile profile = new OWL2QLProfile();
OWL2RLProfile profile = new OWL2RLProfile();
OWL2DLProfile profile = new OWL2DLProfile();

OWLProfileReport report = profile.checkOntology(o);
for (OWLProfileViolation v : report.getViolations()) {
     System.out.println(v);
}



Kind regards,
Maxime