20:48:10 <RRSAgent> RRSAgent has joined #sdwssn
20:48:10 <RRSAgent> logging to http://www.w3.org/2016/11/08-sdwssn-irc
20:48:12 <trackbot> RRSAgent, make logs world
20:48:12 <Zakim> Zakim has joined #sdwssn
20:48:14 <trackbot> Zakim, this will be SDW
20:48:14 <Zakim> ok, trackbot
20:48:15 <trackbot> Meeting: Spatial Data on the Web Working Group Teleconference
20:48:15 <trackbot> Date: 08 November 2016
20:53:34 <Phila> Phila has joined #sdwssn
20:54:17 <Phila> s/Working Group/SSN Task Force/
20:54:44 <ahaller2> present+ ahaller2
20:55:15 <Phila> Present+
20:55:43 <Phila> Chair: Armin
20:56:02 <Phila> Rrsagent, draft minutes
20:56:02 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/08-sdwssn-minutes.html Phila
20:56:20 <roba> roba has joined #sdwssn
20:57:21 <ClausStadler> ClausStadler has joined #sdwssn
20:57:35 <Phila> Regrets+ Scott, Dimitri
20:59:16 <SimonCox> SimonCox has joined #sdwssn
20:59:47 <joshlieberman> joshlieberman has joined #sdwssn
21:00:21 <kerry> kerry has joined #sdwssn
21:00:34 <SimonCox> present+ SimonCox
21:00:39 <DanhLePhuoc> DanhLePhuoc has joined #sdwssn
21:01:00 <kerry> present+ kerry
21:01:12 <ClausStadler> present+ ClausStadler
21:01:29 <roba> present+
21:01:47 <joshlieberman> present+
21:01:48 <DanhLePhuoc> present+ DanhLePhuoc
21:02:25 <ahaller2> scribe: roba
21:03:16 <ahaller2> topic: patent call
21:03:31 <kerry> scribenick: roba
21:04:07 <ahaller2> approve minutes: http://www.w3.org/2016/10/25-sdwssn-minutes
21:04:17 <kerry> +1
21:04:19 <SimonCox> (has the right incantation been made to start recording the IRC log?)
21:04:21 <ahaller2> +1
21:04:23 <ClausStadler> +0
21:04:27 <SimonCox> +1
21:04:40 <DanhLePhuoc> +1
21:04:41 <roba> +0
21:04:52 <ahaller2> approve: http://www.w3.org/2016/11/01-sdwssn-minutes
21:04:59 <SimonCox> +1
21:04:59 <ClausStadler> +1
21:05:04 <kerry> +1
21:05:37 <ahaller2> opic: Plan (Scope) for next WD before EOY
21:06:03 <roba> ahaller2: new agenda item - Working Draft plans and timing
21:06:33 <roba> ...December draft needs to define final scope
21:07:35 <ahaller2> q?
21:07:57 <ahaller2> s/opic/topic
21:08:01 <roba> kerry: asks Phil about timing
21:08:31 <kerry> phil: f2f th & fri 15 & 16 December
21:08:44 <kerry> ...too late for publishig before eoy
21:08:51 <roba> phila: F2F 15-16 Dec - its too late to publish before christmas - last date before w3C is 15th Dec
21:09:08 <kerry> needs to be approved on 14 December to meet the end of year
21:09:29 <kerry> ...propose we intend to vote to publish at f2f, which would then publish 1st week of Jan
21:09:40 <roba> ...practical difference between publishing immediatelt bfore, vs after is "zero" - so F2F could be used to vote to release.
21:09:43 <kerry> ...could struggle to get before then but not a lot of point
21:10:01 <kerry> ...so Th15&16 December should be dates for voting by WG as a whole
21:10:30 <kerry> armin: work on it during f2f?
21:10:37 <roba> kerry - i had my hand up to scribe - you'll need to chair later anyway :-0
21:10:39 <Kjanowic> Kjanowic has joined #sdwssn
21:11:00 <kerry> phil: what you end up with during the wekend could be very clear instructions about changes so taht vote at the meeting is conditional on those changes
21:11:04 <Kjanowic> present+ Kjanowic
21:11:44 <ahaller2> q?
21:11:50 <kerry> q+
21:11:59 <kerry> https://www.w3.org/2015/spatial/wiki/Attending_F2F5
21:12:04 <ahaller2> ack kerry
21:13:26 <ahaller2> topic: SOSA core formal language  https://www.w3.org/2015/spatial/track/issues/72
21:13:40 <kerry> kerrry: please record planned attendance at that link on wiki
21:14:37 <roba> ahaller2: decision to be made re inverseproperties = waht the core should be
21:14:44 <ahaller2> q?
21:14:49 <roba> q+
21:14:52 <kerry> q+
21:14:55 <Kjanowic> q+
21:15:29 <kerry> danh: core only in rdfs is what we need: taxonomy plus properties
21:15:34 <ahaller2> +1
21:15:49 <ahaller2> ack roba
21:15:50 <kerry> ...anything else more complex should go in the alignment or elsewhere
21:15:51 <roba> DanhLePhuoc: hierarchy of properites as description only - more in other modules
21:16:26 <ahaller2> roba: the key issue is what entailment each module should support
21:16:48 <ahaller2> ... tend to agree with danh, no entailment, some RDFS entailment
21:16:57 <ahaller2> ack kerry
21:17:32 <Kjanowic> IMHO, this is not our responsibility and easy of KR is not only the used KL
21:17:36 <ahaller2> s/waht/what
21:18:12 <Kjanowic> we do not have domain and range in sosa-core
21:18:17 <ahaller2> kerry: tend to agree with RDF(S), inverse properties are out of RDFS semantics, no domain and range
21:18:24 <ahaller2> ... break that for inverse properties
21:18:31 <roba> roba: modules need to be clear about exactly what entailment is expected to make it useful - what the implied contract is between publisher and user - who is respeonsible for what entailment
21:18:39 <ahaller2> ack Kjanowic
21:19:00 <roba> kerry: uncomfortalbe about rdfs domain and range
21:19:24 <roba> Kjanowic: we dont have rdfs domain and range...
21:19:27 <joshlieberman> Domain and range are meta properties, not concrete axioms.
21:19:38 <Kjanowic> q+
21:19:59 <ahaller2> ack Kjanowic
21:20:06 <roba> kerry: scribing not right: objecting to schema.org flavour
21:20:17 <roba> ... hope i got that right?
21:20:31 <ahaller2> q+
21:21:16 <roba> Kjanowic: schema.org properties documentation only
21:21:38 <kerry> rdfq+
21:21:39 <SimonCox> +1 Kjanowic
21:21:41 <kerry> q+
21:21:44 <ahaller2> ack ahaller2
21:21:51 <roba> ...should not restrict ourselves to RDFS - dont confuse knowledge representation with use of the KR language
21:22:24 <kerry> +1 use documentation alone
21:22:27 <DanhLePhuoc> q+
21:22:30 <roba> ahaller: agrees with Kjanowic - can introduce our own properties to document intent
21:22:53 <roba> ... torn about inverse properties - means leaving RDFS entailment
21:23:04 <ahaller2> q?
21:23:09 <ahaller2> ack ahaller
21:23:12 <ahaller2> ack kerry
21:23:15 <joshlieberman> It would be useful to have a practical description of the language profile being proposed (e.g. RDFS classes, annotations, owl properties / inverseProperties, etc.)
21:23:36 <roba> Why cant we use a documentation flavour of inverse, like we wanrt to for domain and range - abd push it to the OWL layer?
21:23:47 <Kjanowic> If we are very strict about this we would have to give up on tons of very useful aspects such as  dc:title rdf:type owl:AnnotationProperty ; owl:inverseProperty but also all the versioning aspects that OWL allows us to do
21:23:50 <ahaller2> s/wanrt/want
21:24:03 <roba> kerry: recaps scope - lets handle issues one at a time
21:25:06 <Kjanowic> also, lets not confuse the idea of lightweight axiomatization with the used knowledge representation language. I can make insanely complicated ontologies full of ontological commitments using RDFS and very simple ontologies using OWL2
21:25:11 <roba> ahaller : anyone disagree we use RDFS classes in core?
21:25:23 <Kjanowic> Yes, I would disagree
21:25:26 <SimonCox> no (double negative)
21:25:36 <ahaller2> q?
21:25:40 <ahaller2> ack DanhLePhuoc
21:26:33 <Kjanowic> q+ (I have to disagree with Danh here)
21:26:54 <roba> DanhLePhuoc: about entailment: every vocab has its own semantics
21:27:48 <ahaller2> ack Kjanowic
21:28:10 <roba> ... need to make sure we know what the implications are for standardised interpretations (? have i got that right)
21:28:53 <kerry> I think we are talking about the intended entailment regime that is exepcted to be used for success
21:29:08 <DanhLePhuoc> q+
21:29:16 <ahaller2> ack DanhLePhuoc
21:29:22 <joshlieberman> Is there a principle here of using the minimum expressiveness to support correct usage of the core vocabulary? Then we just need the approach described, and which parts of which language to use.
21:29:24 <roba> Kjanowic: we dont control entailment by user - want to use best tools to express concepts
21:29:36 <kerry> e.g. using owl:annotationproperties within an rdfs entailment intention is absolutley ok
21:29:42 <ahaller2> s/dont/don't
21:29:44 <Kjanowic> I agree with that Danh
21:29:51 <roba> DanhLePhuoc: implications should be documented
21:30:10 <kerry> +1 to support Danh
21:30:14 <roba> +1 - thats what I was saying - its important to keep it simple
21:30:28 <SimonCox> Kjanowic: proposing to use 'fragments' of knowledge representation language, and that we should separate this concern from the entailment regime applied by the user
21:30:31 <roba> ...in terms of what the expectations are
21:31:42 <Kjanowic> My point was that we should use the language that allows us to create a useful model and announce with KL fragments we used. The entailments are largely up to the triple store
21:32:04 <ahaller2> Proposal: Agreeing on using RDFS classes in core
21:32:14 <DanhLePhuoc> +1
21:32:15 <ahaller2> +1
21:32:15 <kerry> +1
21:32:17 <Kjanowic> currently we use owl:class and there is IMHO no reason to change this (other tahnsaying we only do RDFS)
21:32:18 <roba> +1
21:32:19 <Kjanowic> -1
21:32:27 <SimonCox> +1 (as the very base layer)
21:32:38 <kerry> q+
21:32:49 <ahaller2> ack kerry
21:32:59 <ClausStadler> +1 (as danh pointed out, i agree this design decision shouldn't be handed back to the devs)
21:33:27 <joshlieberman> owl:class is subclass of (also a) rdfs:class
21:33:43 <roba> kerry: if RDFS some tools trun into OWL auto - is that reasonable
21:33:52 <SimonCox> owl:Class rdfs:subClassOf owl:Class . so :foo a owl:Class entails :foo a rdfs:Class
21:34:07 <ahaller2> q?
21:34:14 <roba> DanhLePhuoc: OWL declares owl:Class is equivalent to rdfs:Class
21:34:35 <Kjanowic>  what is the reason to change this?
21:35:07 <roba> SimonCox: doenst see an inconsistency
21:35:16 <SimonCox> Correction - owl:Class rdfs:subClassOf rdfs:Class . so :foo a owl:Class entails :foo a rdfs:Class
21:35:23 <ahaller2> s/doenst/doesn't
21:35:23 <Kjanowic> so why would we want rdfs:class instead owl:class?
21:35:24 <ClausStadler> afaik owl classes are more restrictive than rdfs classes
21:35:29 <Kjanowic> yes!
21:35:49 <roba> SimonCox: confirms its rdfs:subClassOf
21:35:54 <roba> q+
21:35:59 <kerry> chair: kerry
21:36:02 <Kjanowic> q+
21:36:13 <kerry> ack Kjanowic
21:36:43 <roba> Kjanowic: the only reason to have broader RDFS class instead of more strict is if we are only interested on RDFS
21:36:57 <roba> kerry: we are discussing that
21:37:45 <kerry> q?
21:37:45 <roba> ... we can use owl:properties anyway
21:38:12 <roba> phila: normal to define both owl and rdfs :Class
21:38:19 <joshlieberman> q+
21:38:38 <kerry> ack roba
21:38:48 <Kjanowic> the only reason whould be if we go rdfs-only
21:39:16 <kerry> +1 to rob's statement
21:39:28 <SimonCox> ssn-new:Procedure rdf:type rdfs:Class , owl:Class .           etc.
21:39:36 <joshlieberman> In principle, there may be rdfs:classes that are not owl:classes, but we intend these terms to be legal owl:classes, so let's make them owl:classes. Shouldn't change the behavior until we add axioms in another module.
21:39:44 <Kjanowic> Can we first discuss whether we really want to restrict ourself to rdfs?
21:39:57 <DanhLePhuoc> q+
21:40:11 <kerry> ack joshlieberman
21:40:23 <Kjanowic> no
21:41:01 <roba> oshlieberman: if owl do we introduce unnecessary restrictions? no harm I believe
21:41:02 <Kjanowic> +1
21:41:12 <kerry> ack DanhLePhuoc
21:41:31 <roba> s/oshlieberman/joshlieberman/
21:41:51 <kerry> q+
21:42:14 <roba> DanhLePhuoc: supports using both - RDFS reasoning can ignore OWL - so safe to co-exist
21:42:29 <kerry> ack kerry
21:42:31 <ClausStadler> if i am not mistaken, a great difference is, that in rdfs its valid to have classes of classes - that's not possible in owl
21:43:26 <Kjanowic> as an example --> http://dbpedia.org/ontology/City  --> rdf:type 	      owl:Class
21:43:29 <roba> kerry: assert in core as RDFS classes does not prevent OWL reasoning and makes strong implication that we can use SSN with only RDFS reasoning
21:43:39 <kerry> q?
21:44:10 <Kjanowic> can we postpone the vote and discuss this over the list?
21:44:32 <kerry> q?
21:44:46 <SimonCox> The problem is around whether voting *for* rdfs:Class implies !owl:Class
21:44:58 <Kjanowic> so we do not know why we want to change what we have but we want to change it?
21:45:17 <joshlieberman> Only the inverse. owl:class implies rdfs:class, not the other way.
21:45:20 <ClausStadler> i think i got the initial wrong; i think i agree with Kjanowic - if we vote for owl:Class, we get rdfs:Class implied; but not vice versa
21:45:25 <roba>  Core should include RDFS definitions explicitly and not require OWL reasoning to get RDFS - but does not stop us using owl:Class to be specific about semantics
21:45:56 <ClausStadler> s/initial wrong/initial question wrong
21:46:02 <Kjanowic> A type 1 class description is syntactically represented as an named instance of owl:Class, a subclass of rdfs:Class:  <owl:Class rdf:ID="Human"/>  This will assert the triple "ex:Human rdf:type owl:Class .", where ex: is the namespace of the relevant ontology .  NOTE: In OWL Lite and OWL DL, owl:Class (or owl:Restriction, see further) must be used for all class descriptions.  NOTE: owl:Class is defined as a subclass of rdfs:Class. The rationale for havi[CUT]
21:46:12 <Kjanowic> frokm: https://www.w3.org/TR/owl-ref/
21:46:15 <roba> simoncox: confusion seems to be interpreting as a "retreat from owl"
21:46:34 <roba> q+
21:46:46 <Kjanowic> "not all RDFS classes are legal OWL DL classes"
21:47:49 <roba> roba: are we just talking about entailing all RDFS in the core, even though we start with OWL?
21:48:07 <kerry> q?
21:48:16 <roba> Kjanowic: we are making a big decision here
21:48:17 <ClausStadler> the statement owl:Class subClassOf rdfs:Class is in rdfs ;)
21:48:25 <DanhLePhuoc> +q
21:48:29 <ClausStadler> i mean in its entailment regime
21:48:30 <joshlieberman> Can we use owl:class and assert in documentation that we mean the core to be usable with rdfs semantics?
21:48:33 <roba> kerry: disagrees - but agrees to hold off...
21:48:39 <Kjanowic> +1
21:49:11 <kerry> topic: inverse properties
21:49:20 <DanhLePhuoc> -q
21:49:20 <roba> ... lets talk about inverse properties
21:49:31 <kerry>  https://www.w3.org/2015/spatial/track/issues/72
21:49:41 <kerry> issue-72?
21:49:41 <trackbot> issue-72 -- What reasoning language should the core use? -- open
21:49:41 <trackbot> http://www.w3.org/2015/spatial/track/issues/72
21:50:05 <Kjanowic> q+
21:50:18 <roba> q-
21:50:21 <kerry> ack Kjanowic
21:50:54 <roba> Kjanowic: useful and do no harm
21:51:08 <roba> kerry: issue documents additional concerns
21:51:11 <SimonCox> q+
21:51:15 <kerry> ack roba
21:51:23 <kerry> ack SimonCox
21:52:15 <kerry> q?
21:52:19 <roba> simoncox: pros are web developer centric
21:52:19 <ClausStadler> q+
21:52:24 <DanhLePhuoc> q+
21:52:28 <kerry> ack ClausStadler
21:52:29 <roba> q+
21:53:03 <Kjanowic> +1 on that
21:53:08 <Kjanowic> very true
21:53:36 <kerry> q+
21:53:49 <roba> ClausStadler: may specify that tools "may support" and effectively reserve the keywords?
21:54:14 <kerry> ack DanhLePhuoc
21:54:29 <roba> kerry: likes telling people to materialise them if they want to use them
21:54:45 <roba> DanhLePhuoc: sees no harm to put property there
21:55:15 <roba> ... core should be lightweight in terms of processing - not just developers
21:55:24 <kerry> q+
21:55:31 <SimonCox> I liked Aidan Hogan's comment: if you've already said what it should be named, then what possible reason for not actually declaring the inverse property?!
21:55:42 <roba> ... wasnt rationale to be lightweight in terms of reasoning burden?
21:55:50 <Kjanowic> +1 to Aidan (and this was one of our reasons)
21:56:01 <roba> q-
21:56:33 <joshlieberman> we could have inverse properties in the core, but could leave off the owl:inverseOf. Alternately an RDFS reasoner would ignore the owl:inverseOf statements.
21:56:46 <Kjanowic> sosa-core is not just IoT (but includes IoT)
21:57:04 <roba> kerry: though core was about IoT - KJ has pointed out its not - so cant make that assumption
21:57:05 <SimonCox> +1 to joshlieberman - "an RDFS reasoner would ignore the owl:inverseOf statements"
21:57:30 <joshlieberman> or we could use meta:inverseOf ...
21:57:31 <roba> kerry: happy to have properties there.
21:57:36 <Kjanowic> q+
21:57:44 <roba> q+
21:57:52 <kerry> q?
21:58:00 <kerry> ack Kjanowic
21:58:09 <kerry> ack kerry
21:58:42 <kerry> q?
21:58:46 <roba> Kjanowic: could declare a documentation property - and then put formal OWL in other module?
21:58:58 <kerry> ack roba
21:59:16 <ahaller2> ahaller2 has joined #sdwssn
21:59:25 <kerry> q+
21:59:31 <Kjanowic> I am +1 on using owl:inverseof but I would also be okay with haveing it defined as annotationproperty and then add the owl:inverseOf in SSn but this may also create problems
21:59:36 <joshlieberman> must depart and cast my useless Massachusetts vote. bye
21:59:56 <kerry> q?
21:59:59 <Kjanowic> in short i would vote for using owl inverse properties directly in sosa-core
22:00:18 <SimonCox> +1 Kjanowic
22:00:26 <roba> kerry: sounds like we can declare properties
22:00:47 <kerry> can you live with owl:inverseproerty in the core
22:00:51 <SimonCox> +1
22:00:58 <roba> yes - provided the use is not expected to use OWL reasoning to interpret the core
22:00:59 <kerry> +1
22:01:00 <Kjanowic> +1
22:01:02 <roba> +1
22:01:14 <ClausStadler> I think there is no harm in using owl:inverseOf - if a reasoner understands it, the data gets interpreted in the way you want it to be - without a reasoner its effectively an annotation anyway
22:01:19 <DanhLePhuoc> +0
22:01:19 <ClausStadler> +1
22:01:30 <Kjanowic> @ClausStadler: exactly!
22:01:35 <SimonCox> ClausStadler: nails it!
22:01:37 <kerry> can u live with  inverse preperties named but not declares as inverses in the core?
22:01:51 <kerry> +1
22:01:59 <roba> +0
22:02:15 <Kjanowic> 0 (meaning I voted +1 for inverse properties but could survive this version as well)
22:02:38 <DanhLePhuoc> +0
22:03:22 <Kjanowic> we have more + votes for owl inverse properties (6 versus 1)
22:03:42 <SimonCox> I have to go to prep for next meeting
22:03:57 <SimonCox> +1 kj
22:04:11 <Kjanowic> sure, I understand that
22:04:20 <roba> kerry: put to vote in next meeting
22:04:27 <kerry> rrsagent, draft minutes
22:04:27 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/08-sdwssn-minutes.html kerry
22:04:30 <Kjanowic> bye
22:04:36 <kerry> bye!
22:04:41 <roba> bye
22:04:42 <kerry> thank you scribe!
22:05:31 <kerry> resolved: to put the inverse question to formal vote at next meeting without further discussion.
22:05:37 <kerry> rrsagent, draft minutes
22:05:37 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/08-sdwssn-minutes.html kerry
22:05:50 <Phila> Rrsagent, draft minutes
22:05:50 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/08-sdwssn-minutes.html Phila
23:38:20 <ahaller2> ahaller2 has joined #sdwssn