See also: IRC log
<kerry> look at this! https://www.w3.org/TR/2016/WD-vocab-ssn-20160531/
<kerry> scribe: Armin
<kerry> scribenick: ahaller2
+1
<KJanowic> +1
<SimonCox> +1
<ClausStadler> +1
<ByronCinNZ> +1
<robin> +1
RESOLUTION: approve last week's minutes
<DanhLePhuoc> +1
<kerry> patent call: https://www.w3.org/2015/spatial/wiki/Patent_Call
<roba> +1
+1
<KJanowic> congrats!
<kerry> https://www.w3.org/2015/spatial/wiki/Patent_Call
<kerry> http://www.w3.org/2016/05/31-sdwssn-irc
https://github.com/w3c/sdw/blob/armins-branch/ssn/images/modular_ontology.png
<kerry> ahaller2: postsl link and mentiones actions commited to his branch
<kerry> some examples around graph and new version of graph (diagram)
<kerry> ahaller2: was thinking the core should be our sensor core in rdfs semantics like schema.org
<kerry> ...maybe some informal local restrictions
<kerry> ...Kerry and I spoke yesterday -- not sure what goes in core yet
<KJanowic> See here for a proposal: https://www.w3.org/2015/spatial/wiki/SSN_core_modules
<kerry> ... needs to be sensor, measurement calues, device class
<kerry> ...then 2 outer core modules that introduces rich semantics from ssn
<kerry> ...and imports sensing and sensing device
<kerry> ..o&m modu,e woiuld import core
<kerry> ..those 2 modules are independent. If they use a concept from the other module it will use the namespace of the other but does not import
<kerry> ...in order to align we have this alignment thin layer on top
<kerry> ... which would import both ssn and oml module
<KJanowic> Does the O&M module include sampling?
<kerry> ... no longer relies on dolce but this is on lhhs and imports ssn but not oml
<kerry> ...core might have some annotation properties to point to other modules where they are defined
<kerry> ... reusing terms
<kerry> ...questions?
<kerry> KJanowic: where would sensing a feature go?
<kerry> ahaller2: i beleive in oml part but other people will think otherwise
<kerry> KJanowic: i think we can tick this in -- email discussion coming
<kerry> ... now old www work and core and oml
<kerry> ... could we instead have an observation module and a sensor module instead/
<SimonCox> I think Jano was asking about 'SamplingFeatures' which is part of O&M and om-lite
<kerry> ahaller2: wanted to show ssn has all the rich semantics plus deployment etc
<kerry> KJanowic: but should not show who invented it but theme based
+1 for the naming, we need to change them!
<KJanowic> @SimonCox: Yes, SamplingFeature will go into the observation module.
<kerry> roba: a couple of thinks relating to KJanowic
<kerry> ...regarding horizontal and vertical...
<kerry> ,,,does this show both aspects combined?
<SimonCox> WOuld be helpful to see SamplingFeatures explicitly in the diagram ...
<kerry> roba: core menas citable concepts ned to be defined
<kerry> ..need to clarify the role of each of thinks a bit better
<KJanowic> Personally, I would have favoured a core, a sensor, an observation, and a deployment module and it is this deployment module where platforms, sampling, networks and so would go in.
<kerry> ahaller2: good point .. the owl:import indicates vertical, others are horizontal but not well shown here
<kerry> ...there are als osme examples to explain this in my doc
<kerry> ... om is not the canonical
<kerry> ...is this a naming clarification.
<kerry> ...where would imports appear?
<kerry> ...important that alignment modules are importing the 2 independent
<KJanowic> Agreed on the horizontal vs vertical layering issue. I have some examples with axioms here: https://www.w3.org/2015/spatial/wiki/SSN_core_modules . I think these details will evolve when we work on the modules. this first draft from ahaller2 and kerry looks really good to me.
<SimonCox> Sampling features are closely linked to sensor deployment semantics - but can probably be decoupled from Observation module
<kerry> ahaller2: dolce is only on outer layer of ssn, does not realte to o&m
<kerry> ...simon's proposla is layered under prov
<KJanowic> I still think DUL should be entirely removed from any official language in the standard.
<kerry> roba: shouldn't dulce alignment import dulce
<kerry> ... want some satellites around the outside
<kerry> ahaller2: yes could show imports of external ontologies
<kerry> DanhLePhuoc: coment on wiki page of ssn core module
<kerry> ...talking about rdfs
<kerry> worried about rdfs interpretation
<kerry> ...if only using rdfs how doe we know whther to use rdfs reasoner
<KJanowic> IMHO, Core should be as simple as schema.org. No OWL, no global domains and ranges.
<kerry> ahaller2: was a bbit sloppy here ... prbably want rdfs 1.1 ... doo we want owl:class
<KJanowic> +1 to ahaller2
<kerry> ...there just should be no rich semantics there, can use it as it is
<DanhLePhuoc> https://www.w3.org/TR/rdf11-mt/#rdfs-interpretations
<kerry> DanhLePhuoc: for me ehen you talk about rdfs i think rdfs interpretation
<kerry> ...eg for a sparql enpoint with sparql entailment
<kerry> e.g assuming implicit triples
<DanhLePhuoc> https://www.w3.org/TR/sparql11-entailment/
kerry: not much reasoning in the
core, class hierarchy
... would be nice if they are OWL classes
... you could use rdfs entailment, but you would be in the
owl/rdfs intersection
<KJanowic> I do not see the problem, what am I missing?
<kerry> danh: see rdfs semantics 101, you can see the more expressive one covers the less expressive one so you can do rdfs and it will work with owl
DanhLePhuoc: you define stuff in rdfs and OWL
<kerry> ...if you have less powerful qurey processor you can do rdfs
<kerry> ...on server you can do owl 2 but rdfs on gateway which still does some job for you
<kerry> ...can then put data in server to get owl2 semantics
<kerry> ...the good part we can put in best practice too -- when you can use what kind of reasoning
<kerry> ...WoT talks about only the xsd datatypes for interpretation
<kerry> ...eg.g 5 is that same as 5.0
<kerry> ..can still work for that
s/eg/g 5/e.g. 5
<kerry> SimonCox: suggestion that diagram misses undelying alignment with OGC model
<kerry> ...something in the core that realtes to features e.g .sampling features
<KJanowic> featureOfInterest would be in core
<kerry> ...about assignment of properties to features
<kerry> ...sampling features does this.
<kerry> ...that side of observation model was not addressed in original ssn ans reamins invisible here
<kerry> ... needed for linking over to best practices
<kerry> ...want to suggest to look how midlle of diagram has asplit in 2
<roba> Pushing to BP is good - but is Spatial data BP best place? Or only place in short term?
<kerry> KJanowic: suggest we do not goo too far into what goes where
<kerry> but are close to vertical and horizontal layering..
<kerry> suggest vote on this
+1 on voting
<DanhLePhuoc> +1
<KJanowic> +1
<kerry> joshli: wants to see moreon how expressiveness works.. can see central core and adding outside
<KJanowic> My suggestion: the details will be worked out when we do the actual axioms. It looks like we finally all agree on the vertical and horizonal layering so maybe vote on this and move on?
<roba> Also assignment feature properties is perhaps an entailment regime?
<KJanowic> joshli: see example in the wiki
<kerry> ... want to see how the vertical works but wants to see how
<kerry> ...one other issue it puzzles me which is how ssn ontology does not cover netwrok realtionships
<KJanowic> :observation \circ :featureOfInterest \sqsubseteq :observed // Assuming we have guarded domain and range restrictions in place.
<kerry> e.g betewrrn platforms and sampling features and features of interest
<kerry> kerry: ack KJanowic
<kerry> ... see wiki link with propertychain example
<SimonCox> link?
<kerry> ... and agree about missing netowrk part
<roba> +1
<SimonCox> What is the motion?
<KJanowic> the motion is to agree on the idea of vertical and horizontal layering (not yet on any details or count of modules)
<SimonCox> +1
+1
<DanhLePhuoc> +1
<roba> +1
<ClausStadler> +1
<KJanowic> +1
<ByronCinNZ> +1
<JRamsay> +1
<kerry> +1
<KJanowic> jay!
yes
<joshli> My understanding is that the horizontal modular relationships add new types of concepts, vertical m-relationships add more expressive predicates.
<joshli> +1
<KJanowic> IMHO, this is a very good first diagram that you did there and we can discuss and revisit the details as we go along
RESOLUTION: agree on the idea of vertical and horizontal layering (not yet on any details or count of modules)
<KJanowic> @joshli: yes
<KJanowic> If Simon is willing to give me a hand, I would hammer out a first draft of CORE and how to add the sampling feature hook to that
kerry: we may need to include
better explanations of the layering, referring to KJanowic wiki
and the discussion we had in the meeting today
... bug with LODE that causes a lot of typos
<SimonCox> @KJanowic must wait until July :-(
kerry: happy to do it myself and freeze the document
<KJanowic> NP, I can rework what is in the wikiand wait for your input.
SimonCox: the ontology is still unstable, you may do a lot of extra work
kerry: annotations will not
change too much, as we probably won't take away much
classes/properties
... annotations will appear mostly in rdfs:comment
... it is around foreign characters etc. that screwed up the
first public draft
... not changing meaning, just fixing typos and characters that
cause problems with LODE
<KJanowic> +1
<SimonCox> om-lite is heavily annotated!
+1
<roba> +1
<SimonCox> +1
<JRamsay> +1
<DanhLePhuoc> +1
<ByronCinNZ> +1
<ClausStadler> +1
<KJanowic> @ahaller2: can you upload an svg version of https://github.com/w3c/sdw/blob/armins-branch/ssn/images/modular_ontology.png so that it can be edited?
yes, KJanowic I can upload an svg version
<KJanowic> thx
kerry: what are our next
steps?
... we could start working on what goes where
... proposals for what goes where and even naming
agree that they should go in there, personally not in the core
actuators are also important
<KJanowic> not in the core but it should go somewhere and there is an existing axiomatization out there so it should be easy to do
<KJanowic> +1, I get this question many times. We had to do our own version in the GeoLink project
<joshli> The critical connection to all things IoT is FeatureOfInterest.
<KJanowic> i agree with all this Kerry but IMHO we need to address those issues for which we have manpower. We have the sampling feature manpower right in the team. I agree that we need more on devices and so forth. All I am trying to get us agree on is that we need more on sampling.
ahaller2: I can include samplingfeatures in the graph if that is important for the group
kerry: my objections is that we have many other things and we have not voted on them
roba: it is worthwhile to find
this bridge between sensors and samplingfeatures
... in favour to include samplingfeatures, and it is a good use
case for the modularisation
... it should be visible to the outside that this is something
we consider
kerry: ssn proposes sampling, but can not be used on its own
<joshli> One approach would be to define the "interfaces" to proposed modules in advance of working on the modules, e.g. a stub representing a default sampling feature.
<KJanowic> Agreed! work on adding sampling feature and more on devices at the same time.
roba: we don't need to worry about details yet, but we should get the design right
<KJanowic> see also here about the second part: http://schema.geolink.org/patterns/core/physicalsample.html
<KJanowic> +1 to kerry's suggestion
<roba> +1
kerry: proposal to work next on samplingfeatures and small devices modularity
<KJanowic> +1
+1
<SimonCox> I have to go.
<DanhLePhuoc> +1
kerry: please put proposals on the wiki
<joshli> bye bye
kerry: we may not have a meeting in two weeks time, because it may become a time meeting
<KJanowic> Thanks everybody and bye bye
kerry: we will have a meeting, but it will be about time
<roba> cheers all
bye
<ClausStadler> bye
