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

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