SSN - local restrictions instead of domain and range, Was: SSN - term-by-term integration is finished

Thanks Armin,

I'll close this pull request and prepare a new one with less conflicts on
files.

About those domain and  range, instead of having:

ssn:hasProperty rdfs:domain sosa:FeatureOfInterest .
ssn:hasProperty rdfs:range ssn:Property .

would it be ok to use local restrictions such as:

sosa:FeatureOfInterest owl:equivalentClass [ owl:onProperty ssn:hasProperty
; owl:someValuesFrom owl:Thing ] .
ssn:Property owl:equivalentClass [ owl:onProperty [ owl:inverseOf
ssn:hasProperty ] ; owl:someValuesFrom owl:Thing ] .

:-) ?

Best,
Maxime

Le dim. 16 avr. 2017 à 09:20, Armin Haller <armin.haller@anu.edu.au> a
écrit :

> 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
>