See also: IRC log
<ahaller2> scribe: roba
<kerry> scribenick: roba
<ahaller2> approve minutes: http://www.w3.org/2016/10/25-sdwssn-minutes
<kerry> +1
<SimonCox> (has the right incantation been made to start recording the IRC log?)
<ahaller2> +1
<ClausStadler> +0
<SimonCox> +1
<DanhLePhuoc> +1
+0
<ahaller2> approve: http://www.w3.org/2016/11/01-sdwssn-minutes
<SimonCox> +1
<ClausStadler> +1
<kerry> +1
ahaller2: new agenda item -
Working Draft plans and timing
... December draft needs to define final scope
kerry: asks Phil about timing
<kerry> phil: f2f th & fri 15 & 16 December
<kerry> ...too late for publishig before eoy
phila: F2F 15-16 Dec - its too late to publish before christmas - last date before w3C is 15th Dec
<kerry> needs to be approved on 14 December to meet the end of year
<kerry> ...propose we intend to vote to publish at f2f, which would then publish 1st week of Jan
phila: practical difference between publishing immediatelt bfore, vs after is "zero" - so F2F could be used to vote to release.
<kerry> ...could struggle to get before then but not a lot of point
<kerry> ...so Th15&16 December should be dates for voting by WG as a whole
<kerry> armin: work on it during f2f?
kerry - i had my hand up to scribe - you'll need to chair later anyway :-0
<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
<kerry> https://www.w3.org/2015/spatial/wiki/Attending_F2F5
<kerry> kerrry: please record planned attendance at that link on wiki
ahaller2: decision to be made re inverseproperties = what the core should be
<kerry> danh: core only in rdfs is what we need: taxonomy plus properties
<ahaller2> +1
<kerry> ...anything else more complex should go in the alignment or elsewhere
DanhLePhuoc: hierarchy of properites as description only - more in other modules
<ahaller2> roba: the key issue is what entailment each module should support
<ahaller2> ... tend to agree with danh, no entailment, some RDFS entailment
<Kjanowic> IMHO, this is not our responsibility and easy of KR is not only the used KL
<Kjanowic> we do not have domain and range in sosa-core
<ahaller2> kerry: tend to agree with RDF(S), inverse properties are out of RDFS semantics, no domain and range
<ahaller2> ... break that for inverse properties
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
kerry: uncomfortalbe about rdfs domain and range
Kjanowic: we dont have rdfs domain and range...
<joshlieberman> Domain and range are meta properties, not concrete axioms.
kerry: scribing not right:
objecting to schema.org flavour
... hope i got that right?
Kjanowic: schema.org properties documentation only
<kerry> rdfq+
<SimonCox> +1 Kjanowic
Kjanowic: should not restrict ourselves to RDFS - dont confuse knowledge representation with use of the KR language
<kerry> +1 use documentation alone
ahaller: agrees with Kjanowic -
can introduce our own properties to document intent
... torn about inverse properties - means leaving RDFS
entailment
<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.)
Why cant we use a documentation flavour of inverse, like we want to for domain and range - abd push it to the OWL layer?
<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
kerry: recaps scope - lets handle issues one at a time
<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
ahaller: anyone disagree we use RDFS classes in core?
<Kjanowic> Yes, I would disagree
<SimonCox> no (double negative)
DanhLePhuoc: about entailment:
every vocab has its own semantics
... need to make sure we know what the implications are for
standardised interpretations (? have i got that right)
<kerry> I think we are talking about the intended entailment regime that is exepcted to be used for success
<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.
Kjanowic: we don't control entailment by user - want to use best tools to express concepts
<kerry> e.g. using owl:annotationproperties within an rdfs entailment intention is absolutley ok
<Kjanowic> I agree with that Danh
DanhLePhuoc: implications should be documented
<kerry> +1 to support Danh
+1 - thats what I was saying - its important to keep it simple
<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
scribe: in terms of what the expectations are
<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
<ahaller2> Proposal: Agreeing on using RDFS classes in core
<DanhLePhuoc> +1
<ahaller2> +1
<kerry> +1
<Kjanowic> currently we use owl:class and there is IMHO no reason to change this (other tahnsaying we only do RDFS)
+1
<Kjanowic> -1
<SimonCox> +1 (as the very base layer)
<ClausStadler> +1 (as danh pointed out, i agree this design decision shouldn't be handed back to the devs)
<joshlieberman> owl:class is subclass of (also a) rdfs:class
kerry: if RDFS some tools trun into OWL auto - is that reasonable
<SimonCox> owl:Class rdfs:subClassOf owl:Class . so :foo a owl:Class entails :foo a rdfs:Class
DanhLePhuoc: OWL declares owl:Class is equivalent to rdfs:Class
<Kjanowic> what is the reason to change this?
SimonCox: doesn't see an inconsistency
<SimonCox> Correction - owl:Class rdfs:subClassOf rdfs:Class . so :foo a owl:Class entails :foo a rdfs:Class
<Kjanowic> so why would we want rdfs:class instead owl:class?
<ClausStadler> afaik owl classes are more restrictive than rdfs classes
<Kjanowic> yes!
SimonCox: confirms its rdfs:subClassOf
<kerry> chair: kerry
Kjanowic: the only reason to have broader RDFS class instead of more strict is if we are only interested on RDFS
kerry: we are discussing
that
... we can use owl:properties anyway
phila: normal to define both owl and rdfs :Class
<Kjanowic> the only reason whould be if we go rdfs-only
<kerry> +1 to rob's statement
<SimonCox> ssn-new:Procedure rdf:type rdfs:Class , owl:Class . etc.
<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.
<Kjanowic> Can we first discuss whether we really want to restrict ourself to rdfs?
<Kjanowic> no
joshlieberman: if owl do we introduce unnecessary restrictions? no harm I believe
<Kjanowic> +1
DanhLePhuoc: supports using both - RDFS reasoning can ignore OWL - so safe to co-exist
<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
<Kjanowic> as an example --> http://dbpedia.org/ontology/City --> rdf:type owl:Class
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
<Kjanowic> can we postpone the vote and discuss this over the list?
<SimonCox> The problem is around whether voting *for* rdfs:Class implies !owl:Class
<Kjanowic> so we do not know why we want to change what we have but we want to change it?
<joshlieberman> Only the inverse. owl:class implies rdfs:class, not the other way.
<ClausStadler> i think i got the initial question wrong; i think i agree with Kjanowic - if we vote for owl:Class, we get rdfs:Class implied; but not vice versa
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
<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]
<Kjanowic> frokm: https://www.w3.org/TR/owl-ref/
simoncox: confusion seems to be interpreting as a "retreat from owl"
<Kjanowic> "not all RDFS classes are legal OWL DL classes"
roba: are we just talking about entailing all RDFS in the core, even though we start with OWL?
Kjanowic: we are making a big decision here
<ClausStadler> the statement owl:Class subClassOf rdfs:Class is in rdfs ;)
<DanhLePhuoc> +q
<ClausStadler> i mean in its entailment regime
<joshlieberman> Can we use owl:class and assert in documentation that we mean the core to be usable with rdfs semantics?
kerry: disagrees - but agrees to hold off...
<Kjanowic> +1
<DanhLePhuoc> -q
kerry: lets talk about inverse properties
<kerry> https://www.w3.org/2015/spatial/track/issues/72
<kerry> issue-72?
<trackbot> issue-72 -- What reasoning language should the core use? -- open
<trackbot> http://www.w3.org/2015/spatial/track/issues/72
Kjanowic: useful and do no harm
kerry: issue documents additional concerns
simoncox: pros are web developer centric
<Kjanowic> +1 on that
<Kjanowic> very true
ClausStadler: may specify that tools "may support" and effectively reserve the keywords?
kerry: likes telling people to materialise them if they want to use them
DanhLePhuoc: sees no harm to put
property there
... core should be lightweight in terms of processing - not
just developers
<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?!
DanhLePhuoc: wasnt rationale to be lightweight in terms of reasoning burden?
<Kjanowic> +1 to Aidan (and this was one of our reasons)
<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.
<Kjanowic> sosa-core is not just IoT (but includes IoT)
kerry: though core was about IoT - KJ has pointed out its not - so cant make that assumption
<SimonCox> +1 to joshlieberman - "an RDFS reasoner would ignore the owl:inverseOf statements"
<joshlieberman> or we could use meta:inverseOf ...
kerry: happy to have properties there.
Kjanowic: could declare a documentation property - and then put formal OWL in other module?
<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
<joshlieberman> must depart and cast my useless Massachusetts vote. bye
<Kjanowic> in short i would vote for using owl inverse properties directly in sosa-core
<SimonCox> +1 Kjanowic
kerry: sounds like we can declare properties
<kerry> can you live with owl:inverseproerty in the core
<SimonCox> +1
yes - provided the use is not expected to use OWL reasoning to interpret the core
<kerry> +1
<Kjanowic> +1
+1
<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
<DanhLePhuoc> +0
<ClausStadler> +1
<Kjanowic> @ClausStadler: exactly!
<SimonCox> ClausStadler: nails it!
<kerry> can u live with inverse preperties named but not declares as inverses in the core?
<kerry> +1
+0
<Kjanowic> 0 (meaning I voted +1 for inverse properties but could survive this version as well)
<DanhLePhuoc> +0
<Kjanowic> we have more + votes for owl inverse properties (6 versus 1)
<SimonCox> I have to go to prep for next meeting
<SimonCox> +1 kj
<Kjanowic> sure, I understand that
kerry: put to vote in next meeting
<Kjanowic> bye
<kerry> bye!
bye
<kerry> thank you scribe!
RESOLUTION: to put the inverse question to formal vote at next meeting without further discussion.
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Working Group/SSN Task Force/ Succeeded: s/opic/topic/ Succeeded: s/waht/what/ Succeeded: s/wanrt/want/ Succeeded: s/dont/don't/ Succeeded: s/doenst/doesn't/ Succeeded: s/oshlieberman/joshlieberman/ Succeeded: s/initial wrong/initial question wrong/ Found Scribe: roba Found ScribeNick: roba Present: ahaller2 Phila SimonCox kerry ClausStadler scribe joshlieberman DanhLePhuoc Kjanowic Regrets: Scott Dimitri Found Date: 08 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/08-sdwssn-minutes.html People with action items:[End of scribe.perl diagnostic output]