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

Hi Maxime,

Thanks for the extensive pull request. I agree with all your changes below, but the domain and range restrictions. We cannot add them at this stage, as there was strong opposition against using them. As mentioned earlier, I think we should have existential property restrictions to reflect the domain and rangeIncludes annotation properties from SOSA, but we cannot use domain and range. Domain and Range axioms would also violate our equivalence class relationships in the alignment file.

I cannot accept your PULL request either as there is a huge conflict on the index.html file. Basically, the whole file is different according to the Github diff tool, and I can’t tell if you made any changes to the index.html. If you made changes, please do send them through to me section by section. Preferably, don’t make any changes on the index.html at the moment, as it is extremely hard to coordinate at this stage. You can make changes to all the ontology files, of course and big thanks for doing that!

Although I agree with your changes to deploymentProcessPart as mentioned earlier, I think we better deprecate it rather than introducing a new property for which we have no implementation evidence and we probably won’t get one either.

My choice would be on a).
madeBySensor o implements sub-prop-of usedProcedure
actuationMadeBy o implements sub-prop-of usedProcedure
madeBySampler o implements sub-prop-of usedProcedure


Let’s remove the alignment: ObservationResultTime is equivalent to resultTime and include a seeAlso annotation property.

We can deprecate “ofFeature”, I wanted to do the same already yesterday.

Cheers,
Armin

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Sunday, 16 April 2017 at 11:00 am
To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Armin Haller <armin.haller@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>
Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Subject: 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

Received on Sunday, 16 April 2017 07:21:09 UTC