See also: IRC log
<KJanowic> +1
<ahaller2> 0
<ChrisLittle> +0 not there
<mlefranc> +1
<ahaller2> scribe: KJanowic
<ahaller2> scribenick: KJanowic
<mlefranc> https://www.w3.org/2017/05/09-sdwssn-minutes.html#ActionSummary
<ahaller2> https://www.w3.org/2017/05/09-sdwssn-minutes
<ahaller2> +1
<ahaller2> 0
ahaller also votes +1 on moving the capabilities to a horizontal module.
<mlefranc> +1
+!
<SimonCox> SOrry guys - a few things going on here this morning. Will have to duck out twice to take my wife and daughter to trains.
+1
<SimonCox> +1
[I also can only make the fist hour today]
Markus Stocker and others emailed feedback for wide review
also another comment on actuation
Simon: some more feedback directly on the ontology
we should ask Nick (?) to send an email
mlefranc: also some more feedback from colleagues
<SimonCox> I will mute while I procure some breakfast ...
feedback about relation to QUDT
ahaller: the question we need to figure out is how much longer the review period is
<mlefranc> got some review here: https://github.com/w3c/sdw/issues/892
no, we decided not to discuss it
Yes,first decide what a property is
ahaller: maybe these are two issues. One is a modelling issue, the other a change to the ontology
ahaller, maybe discuss examples first?
I had to leave after 90min, yes
mlefranc: maybe we can avoid subclassing nontheless
SimonCox,technically possible to include those properties. The issue however is the conception of what the role of sosa is. Is it a collection of lightweight concepts/properties or is it a complete or consistent ontology core.
SimonCox: adding more and more (and very late) is not required if you see sosa as a lightweight vocab
... worried about lateness
<ahaller2> KJanowic: same concern as SimonCox, we are not supposed to make changes to the ontologies at this stage. ObservableProperties should become type of Properties, but I would need to think about this.
ahaller: is there strong support from use cases that require SOSA compared to SSN
<SimonCox> Unfortunately content/technical discussions should have taken place 6 months ago.
ahaller: the change may be problematic in terms of timing
mlefranc should come from outside the group
mlefranc the two issues are difficult to untangle
<ahaller2> KJanowic: moving both ontologies close together is diminishing the advantage of having a lightweight ontology
mlefranc: agree with kj that we need clearly distinguishable solutions BUT sosa is also part of ssn so they can’t be told apart so easily
... some decisions about instances versus collections need to be distinguished
utilize owl-punning
<SimonCox> Ah - the subjunctive!
<SimonCox> 'it would have been good'
sosa is fully part in ssn, valid sosa data is valid ssn data
are we facing a paradox here?
YES!
ahaller: a schema.org user will only create instances
... you would not create collections
<ahaller2> KJanowic: our DULCE alignment makes punning difficult, because a sensor is an entity and not an abstract thing.
<ahaller2> KJanowic: it is more important for the properties
in short, we take a more O&M view on sensors, not a sensorML view
we can use typecasting to get around that problems
http://cgi.csc.liv.ac.uk/~valli/OWLED2015/OWLED_2015_paper_15.pdf
mlefranc, we need to please both sides. in our case we dont want to take some important decisions to constraint users
ahaller: I agree
we should not constraint modelling
we are fine as long as we are axiomatically ok
we need to make sure that if we have an alignment, it makes sense in both cases (collections versus individuals)
<SimonCox> We can't keep it unresolved ...
should we vote on the property issue or discuss examples first
mlefranc would vote 0
<ahaller2> PROPOSED: move isPropertyOf and hasProperty from SSN to SOSA
<SimonCox> -1
<mlefranc> 0
-0.5
<ClausStadler_> 0
<ahaller2> -0
RESOLUTION: NOT move isPropertyOf and hasProperty from SSN to SOSA
Let us leave enough space for SSN
<mlefranc> online version here: http://ci.emse.fr/ssn/
<mlefranc> see appendix A
Move examples to non-normative section
also change the function of the buttons
and it DOES! thanks!
the examples are my way to understand sosa/ssn and we need to align this understanding to the rest of the group
The quest is whether we can discuss the family of DHT22 as such
maxime alsoimplemented moving the conditions etc to the horizontal module
mlefranc agree with 1:1 AND 1:n property use
mlefranc accept pull request and then add more examples
ahaller: do we need a 5th level toc?
kj: agree with ahaller
ahaller: right now it looks unbalanced
maxime: yes to only having 4 levels
<SimonCox> I have to leave for 10 minutes
lets accept and then augment
<ahaller2> KJanowic: we need to change the language, i.e. MUST BE
<ahaller2> KJanowic: we need to make decision on the modelling for the respective ontology
ducking the decision is not good. We can introduce both but we need to explain why they are possible and which one we believe is the best (without restricting modelling)
maxime: I agree but it is not doable
for property and sensor it woould be good to have both examples
ahaller: doing it for a subset may be okay
<ahaller2> KJanowic: we don't want to force users of SOSA and SSN in one direction, but we can make a decision on how we show it in the document
<ahaller2> KJanowic: give a canonical way and then show punning example, or express it differently and introduce subclasses
<SimonCox> SImon back
<ahaller2> KJanowic: examples are important for the SOSA people, the SSN users may just use the ttl files directly
<mlefranc> http://www.heppnetz.de/ontologies/goodrelations/goodrelations-UML.png
somebody else to scribe?
<SimonCox> Sorry - I won't be here the whole hour
<ahaller2> scribe: ClausStadler_
<ahaller2> scribenick: ClausStadler_
<ahaller2> +1 to the example mlefranc just presented, goodrelations is not restricting the users, we should do the same!
good relations does not constrain the user what the instance of product or service should be - could be category of galaxy S4, on other sites its _my_ S4
"let ssn leave the room for more research", and carry that proposal over to sosa
<KJanowic> They have no clue what this means
<ahaller2> +1 for a default usage for SOSA users
<ahaller2> SOSA users need guidance
kjanowic: lets show intended use, then show alternatives. Especially for the sosa audience, show what the core idea is, and explain why. Don't say: "everything go" right away. For SSN: explain you can use punning, subclassing, one final paragraph for alternative modeling approaches.
<KJanowic> imho, if we end up with a linked data cloud in which half the users do one and the others do it the other way, we failed
<KJanowic> they are possible anyway
<KJanowic> and they are and shared across all of the geo sciences and other domains
SimonCox: presented 4 options for modeling properties (unfortunately i didn't get all): 1 subclasses of rdf:property, 2 instances of rdf:property, 3 subclasses sosa observable property, 4 ?
<SimonCox> 4 possibilities for defining 'properties': 1. subclass rdf:Property; 2. individual rdf:Property; 3. subclass ssn:Property; 4. individual ssn:Property or sosa:ObservableProperty.
<KJanowic> btw we are confusing the classes vs individuals discussion with the underlying modeling problem
<SimonCox> Punning can be used to equivalence. Nothing is disallowed in applications. But re-use is likely to be easiest if modelled as individuals from the class ssn:Property or sosa:ObservableProperty
<ahaller2> PROPOSED: canonical use of examples for SOSA and then use this canonical example in the SSN extension and then have alternative patterns for punning or for modelling subclasses of Sensors and Properties
<SimonCox> SO that is the one we shoudl show in examples
<KJanowic> + 0.5
<mlefranc> 1 to n then is very important ---> remove some of the existing axioms, starting from ssn:isPropertyOf rdf:type owl:FunctionalProperty
KJanowic: presents an example: DBpedia: classes for cities, populated place - but appartement does not exist. please use punning, we only have the individual. It works for Semantic Web folks, but writing a SPARQL query for "show me all man-made features" requires enumerating all different models. Two user groups: schema.org and the Industry 4.0 - more reasoning is happening on the sensor and needs automatically inferred and guaranteed results.
<ahaller2> https://www.w3.org/TR/microdata/
ahaller2: you can't even create types in microdata, you can only create instances
so it could / should be similar to the naive sosa user
<KJanowic> Btw,I agree with Maxime
<KJanowic> IMHO, the observation part is where this all breaks down
mlefranc: as proposed, have a canonical example. Observations right now are made by exactly one sensor. But there may be instances of sosa:Sensor or users that use punning [...] the point of the example: we may end up with an obsersvation: (1) with that specific galaxy s4 sensor or (2) the class of galaxy S4 temperature sensors linked to the observation. the cardinalities would have to be changed to minCardinality.
<SimonCox> For example: http://environment.data.gov.au/def/property
<SimonCox> these are individual SKOS Concepts and also qudt:QuantityKinds
<ahaller2> PROPOSED: canonical use of examples for SOSA and then use this canonical example in the SSN extension and then have two alternative patterns for punning and for modelling subclasses of Sensors and Properties and outline consequences
<SimonCox> This is the kind of list the earth science community expects to share
<KJanowic> +1 to Simon
<KJanowic> +1
<KJanowic> Can do
<KJanowic> see Simon's link
<mlefranc> +1
<KJanowic> Simon can confirm that this is how it works in earth science
<SimonCox> +1
+1
<KJanowic> +1
<ahaller2> +1
RESOLUTION: canonical use of examples for SOSA and then use this canonical example in the SSN extension and then have two alternative patterns for punning and for modelling subclasses of Sensors and Properties and outline consequences
mlefranc: offered to do the punning and subclassing examples
<KJanowic> ok
<KJanowic> Can do
<KJanowic> +1
<KJanowic> I would make a template, not all examples
<ahaller2> ACTION: KJanowic to extend canonical examples with coastal water body example using rdfs:Subclassing and punning [recorded in http://www.w3.org/2017/05/16-sdwssn-irc]
<trackbot> Created ACTION-362 - Extend canonical examples with coastal water body example using rdfs:subclassing and punning [on Krzysztof Janowicz - due 2017-05-23].
<ahaller2> ACTION: mlefranc to fix hierarchy in PULL request around measurement capabilities [recorded in http://www.w3.org/2017/05/16-sdwssn-irc]
<trackbot> Created ACTION-363 - Fix hierarchy in pull request around measurement capabilities [on Maxime Lefrançois - due 2017-05-23].
<KJanowic> Btw, can somebody turn down the background music
<SimonCox> [Sorry - that's my daughter practising violin]
<KJanowic> "6.1 System capabilities, operating ranges, and survival ranges The terms defined in this section are marked at risk."
<SimonCox> [but now I have to take her to school]
mlefranc: not sure if there are other terms that should be marked as risk
ahaller2: use div class="note" on the html to make features at risk more visible
<KJanowic> Park it
mlefranc: all terms are moved to a separate document and namespace, although cumbersome to developers its consistent
<SimonCox> bye
<KJanowic> imho that was pretty productive
<KJanowic> park it
<KJanowic> yes
<KJanowic> bye bye
<ahaller2> bye
bye
<mlefranc> bye
<ChrisLittle> bye
