<ahaller2> scribe: roba

patent call

<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

Plan (Scope) for next WD before EOY

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

SOSA core formal language https://www.w3.org/2015/spatial/track/issues/72

<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

inverse properties

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