See also: IRC log
can
I can
<ahaller2> scribe: Kjanowic
<ahaller2> approve minutes: https://www.w3.org/2016/11/08-sdwssn-minutes
<SimonCox> +1
<kerry> +1
<ahaller2> +1
+1
<ahaller2> minutes approved
<ahaller2> patent call: https://www.w3.org/2015/spatial/wiki/Patent_Call
Last meeting we discussed inverseOf and owl:class versus rdfs:class. Currently we have inverseOf in SOSA-Core. We had detailed discussion of these issues and many people voiced their support for having inverseOf in SOSA-core. An alternative would be to use annotation properties.
<ahaller2> Vote: The pair are not to be axiomatically  related but documentation is to be used to make the  inverse intention clear
We will first vote on the weaker one, i.e., only using annotation property. then we will vote on using inverse of directly
<SimonCox> If you remove the 'not' clause
-1
<ahaller2> +1
<kerry> +1
<SimonCox> I object to the 'not' clause
<DanhLePhuoc> -
<DanhLePhuoc> -1
<ahaller2> (B)  The pair are related and documentation is to be used to make the  inverse intention clear
(assuming -1 means I am in favor of the owl:inverseOf axioms and not just using annotation property)
<SimonCox> Yes - that's better
ahaller2: can you restate the vote?
kerry: not exactly what we discussed last time. Lets restate this.
KJ: The 3 people on the mailing list voted for "I would support using owl:inverseOf".
<ahaller2> (C)Â Â Â The pair is to be related by an owl:InverseOf declaration;
ahaller2: I was addressing simon's 'not' concern
<SimonCox> (C) +1
+1 for C
<SimonCox> (B) 0
Ahaller: only consider (B) and (C)
... will post them again
Danh: inverseOf versus informally using annotation property
ahaller: yes, like a comment
... must not be an owl annotation property
danh: basically you do not use the formal semantics of owl for inverse of but just a documentation
ahaller2: yes
... two options: one uses the formal semantics of owl, the other simply being a human readable comments
danh: I support the formal inverseOf (also if you do not use owl semantics it will not harm anything)
<ahaller2> (1)  The pair are related but documentation (comment, annotation property) is to be used to make the inverse intention clear
kj: +1 to what danh said
<ahaller2> +1
[...]
<kerry> +1
<SimonCox> -1
_1
-1
<DanhLePhuoc> -1
<ahaller2> (2)Â Â The pair is to be related by an owl:InverseOf declaration
<ahaller2> +1
<DanhLePhuoc> +1
<kerry> 0
+1
<SimonCox> Annotation is OK, axiomatic relationship is better
ahaller: 3 people on the list voted already for formally using inverseOf
<SimonCox> +1
ahaller: okay, so we voted to use owl:inverseOf in SOSA-core
... we have had a detailed discussion so we can close this issue now
72
issue-72 resolved
ahaller: second issue is owl class but now this is easy because we already used owl:inverseOf now
RESOLUTION: issue-72 use owl:inverseOf to declare inverse object properties in SOSA-core
ahaller: we are already using a construct with owl formal semantics
... we had detailed discussions about this already
we will now vote on using owl:class or rdfs:class, or both
<ahaller2> (1) exclusively RDFS Classes or (2) exclusively use OWL:Classes (3) use both
<ahaller2> (1) exclusively RDFS Classes
kj: option one would conflict with our previous vote
-1
<DanhLePhuoc> -1
<kerry> 0
<SimonCox> (2) - OWL classes +1
<ahaller2> 0
<SimonCox> 0
<ahaller2> (2) exclusively use OWL:Classes
+1
<SimonCox> +1
<kerry> 0
<ahaller2> +1
<DanhLePhuoc> -1
kj: which includes rdfs:classes, see the mails
<ahaller2> (3) use both
<kerry> +1
<DanhLePhuoc> +1
-1
<ahaller2> 0
ahaller: using both does not hurt
kj: but AZ also showed that owl:class will imply rdfs:class anyway (or by direct usage)
[Danh, you are being cut of, I have trouble summarizing what you say]
<kerry> Danh is correct --- there are other ways of doing it too but it does not come for free
<ahaller2> Danh: if you don't use RDFS:class explicitly if you don't use a reasoner it causes overhead
<ahaller2> Kjanowic: rdf:type will assert rdfs:class
Danh: may still cause trouble, e.g., when combined with domain and range
vote result: (1) -2 votes (2) +2 votes (3) +1 votes
kerry: I do not see any harm in declaring both
<ahaller2> ex:myClass  a  rdfs:Class, owl:Class
ahaller: basically: kj are you the only one objecting both?
happy to change my vote if this helps us to move on
KJ: Our vote was for owl-only but it was close and we are missing people like rob that would have probably voted for (3). thus, I would be willing to change to 3 if this would make the rest happy and allow us to move on.
Danh: version 3 is better for future use
ahaller: I said 0 initially, but I can also change. My concern is adding axioms that do not really do anything
... happy to say +1
kj: okay, if this makes everybody happy
... can we do a new vote?
RESOLUTION: that classes in sosa-core are declared as both owl:Class and rdfs:Class issue-72
ahaller: lets move on to the documentation discussion
... any other tools that you would like to propose?
Kerry: have not used it but saw others use it
Danh: I would not vote for the previous one. We should try specgen.
<ahaller2> Kjanowic: I propose to make this an action
Kerry: I can do so.
<kerry> ACTION: kerry to try specgen on ssn and dulce alignment for WD [recorded in http://www.w3.org/2016/11/15-sdwssn-irc]
<trackbot> Created ACTION-219 - Try specgen on ssn and dulce alignment for wd [on Kerry Taylor - due 2016-11-22].
<kerry> ACTION: armin to try specgen on sosa-core [recorded in http://www.w3.org/2016/11/15-sdwssn-irc]
<trackbot> Created ACTION-220 - Try specgen on sosa-core [on Armin Haller - due 2016-11-22].
thanks kerry
Ahaller: moving on to next topic.
[ a lot of background noise]
kerry: ssn:System has both a someValues from and an AllValues from restriction on hasSubSystem.
<ahaller2> ahaller2: apologies, the first one is an SSN issue, not a SOSA issue
kerry: I think it is wrong
... I think technically it is wrong, also does not make sense as documentation
... I propose to remove the existential restriction
<ahaller2> Kjanowic: this is an axiom stating that the subsystem can also be a supersystem
kj: like the difference between part and propert part
... also we have to revisit the axiom. using for
... Also we have to revisit the axiom. Using forAll alone together with equivalentClass also will cause problems (I would have to revisit the axiom)
ahaller: should we postpone
kj: I would vote on postponing
yes
I can look into this
<DanhLePhuoc> +1 for posting it
<DanhLePhuoc> posting/postponing
ahaller2: we can change the level of detail of the documentation
kerry: I have a lot of problem with the featureofinterest property
... why are we reducing this to something that states less. why dont we use the annotation that we already have?
... cannot see why we need two different documentations
ahaller: there may be different documentations wherever ssn and sosa differ
... kj, simon?
<Zakim> kerry, you wanted to ask armin to repeat i could not understand that
<ahaller2> https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#FeatureOfInterest
the original is very short
kj: is this about the relationship or the class? I am confused?
ahaller: we have both
<ahaller2> https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#featureOfInterest
simon: in OGC land the object of a foi property would be a feature.
Kj: FOI is a subclass of F and this is very neat for querying
simon: I see. This is also a good response to kerry's question
... at last for the 'why is it different part'
kerry: I am not asking about the difference to OGC but SSN
ahaller: as we do not have domain and range we add a bit more in terms of comments, etc. in SSN full we can infer some of those things
kj: +1 , yes this is what I said
ahaller: do we need to split this into multiple comments?
<kerry> +1 to consistent examples
ahaller: we should have examples for all classes and properties
kerry: there is other parts in the SSN should be added. I like the idea of examples but they have to be systematic
but we have more?
I have a question to kerry before she leaves
<kerry> bye!!!
kerry: maybe make an example property
... or at least split it into multiple comments
kj: I can add examples to all classes and properties
(for SOSA)
ahaller: per class and property we need to explain why the sosa comment differs from the ssn comment
yes, me
<SimonCox> ACTION: on SimonCox to split out examples from comments in SOSA-Core, look over all the comments [recorded in http://www.w3.org/2016/11/15-sdwssn-irc]
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
simon will do
<DanhLePhuoc> +1 for adding examples to classes and properties
<SimonCox> ACTION: SimonCox to split out examples from comments in SOSA-Core, look over all the comments [recorded in http://www.w3.org/2016/11/15-sdwssn-irc]
<trackbot> Error finding 'SimonCox'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
<ahaller2> ACTION: Simon Cox to split out examples from comments in SOSA-Core, look over all the comments [recorded in http://www.w3.org/2016/11/15-sdwssn-irc]
<trackbot> Created ACTION-221 - Cox to split out examples from comments in sosa-core, look over all the comments [on Simon Cox - due 2016-11-22].
no
<ahaller2> Kjanowic: We need to write more because it is another audience
ahaller: I agree. compare with ssn and explain why we need more or something different
thanks !
<ahaller2> bye
bye bye
<ahaller2> type RRSAgent, draft minutes