Re: Proposed features at risk: Commands. Was: SSN - term-by-term integration is finished

Sorry guys, I am still catching up with some emails. Let us please avoid 
changes to the ontologies and introducing any new features (at risk or 
not). We have spent 1.5 years discussing everything in detail, we cannot 
do any changes right now that have not been agreed on by a substantial 
part of the group.

Jano

On 04/16/2017 04:34 AM, Maxime Lefrançois wrote:
> Hi,
>
> Pull request https://github.com/w3c/sdw/pull/706 proposes a "feature 
> at risk module" in SOSA and  SSN that mimics Result and defines:
>
> sosa:Command, sosa:hasCommand, sosa:isCommandOf, 
> sosa:hasSimpleCommand, sosa:commandTime
>
> marking them as "feature at risk" should be safe because we can simply 
> delete  them if no sufficient implementation evidence is found.
>
> Best,
> Maxime
>
> Le dim. 16 avr. 2017 à 13:10, Maxime Lefrançois 
> <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>> a écrit :
>
>     Hi Armin,
>
>         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.
>
>
>     New pull request https://github.com/w3c/sdw/pull/705 does not
>     contain any domain or range. Only local universal property
>     restrictions.
>
>
>         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!
>
>
>     Now pull request shows no such conflict with index.html
>
>         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.
>
>
>     It is now deprecated
>
>
>         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
>
>
>     ok done.
>
>         Let’s remove the alignment: ObservationResultTime is
>         equivalent to resultTime and include a seeAlso annotation
>         property.
>
>
>     ok done.
>
>         We can deprecate “ofFeature”, I wanted to do the same already
>         yesterday.
>
>
>     ok done.
>
>
>     Will issue another one for the Commands.
>
>     Best,
>     Maxime
>
>
>         Cheers,
>         Armin
>
>         *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr
>         <mailto: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 <mailto:armin.haller@anu.edu.au>>,
>         "janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>"
>         <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>
>         *Cc: *"public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>         <public-sdw-wg@w3.org <mailto: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
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net

Received on Tuesday, 18 April 2017 03:09:49 UTC