Spatial Data on the Web SSN Sub Group Teleconference

<scribe> agenda: patent call

<scribe> agenda: Import/Non-import of modules in the onion layers of the SSN ontology

http://w3c.github.io/sdw/ssn/#modularisation

<SimonCox> If modules that import (SOSA-)core demonstrate implementation, wouldn't that suit?

<SimonCox> ahaller2: notes difficulty with having reliance on SOSA-core because of lack of evidence of implementation (can't be normative)

KJanowic: still believe that SOSA should be in the core and in the normative part
... I think the alignment would break the axioms

<SimonCox> KJanowic: difficulty with simultaneously aligning to old SSN and DOLCE and O&M - will break axioms in DOLCE

<SimonCox> ahaller2: new SSN would not import alignment graph

<KJanowic> but we will still switch back and forth on the meaning of those classes, right?

kerry: this gymnastics is all about getting implementations

<SimonCox> kerry: alignment is all about re-using the old implementations as evidence

<KJanowic> +1 on getting new implementations

kerry: convince ourselves that we get new implementation
... we can get implementations for the SOSA core

<KJanowic> I can provide implementation on sosa-core. I am just totally scared of having the same class, e.g., observation, with 3 different meanings no matter whether the alignment is optional.

kerry: proposed the alignment about 6 months ago already
... implement at least a fraction of what we are trying to do

<SimonCox> kerry: keep DOLCE alignment out of normative rec-track

kerry: alignment to DOLCE in a seperate document

<KJanowic> +1

<KJanowic> +1 to sosa-core being normative and essential

<SimonCox> kerry: SOSA-core is absolutely essential, needs to be normative

<SimonCox> +1

<KJanowic> +1 on that!

<SimonCox> ahaller2: would prefer to keep alignments out of normative docs

<SimonCox> ahaller2: alignment with old SSN is desirable to document changes

<SimonCox> ... but in non-normative part for now?

KJanowic: lot of work gone into the SOSA core. Let's start talking about implementations now.

<SimonCox> Needed in SOSA-core: decision on whether sub-classing is included ...

<scribe> ... new observation concept can not link to the old one

UNKNOWN_SPEAKER: if the axiom is there it will make some unwanted asssertions

<Zakim> kerry, you wanted to ask if we are seriously going to look for implmentations of the non-core parts of new ssn and to disagree that sosa-core is ready to go

<SimonCox> KJanowic: if there is any axiom anywhere that aligns new sosa:Observation with old ssn:Observation then sosa:Observation cannot be an Event, because of OWL inconsistency with DOLCE ...

<KJanowic> but for me there is no difference between ssn and sosa-core. These are just names. We can call sosa-core ssn-core if this fixes the issue.

<KJanowic> @kerry: but we can work on that

<SimonCox> kerry: SOSA-core definitely not ready to go - would vote -1 right now, suspect many other would too

<KJanowic> but will there be a relation between newssn:observation and oldssn:observation?

<KJanowic> Agreed

<SimonCox> ahaller2: SOSA-core has not been discussed in wider SDWWG-SSN group

<KJanowic> +1 on what ahaller2 just said, namely having sosa-core (ssn-core) in the normative part, as core of ssn, aligned with the new SSN and not having the DUL alignment in the normative part

<SimonCox> KJanowic: asked - "will there be a relation between newssn:observation and oldssn:observation?" - ahaller2 says "non-normative"

<SimonCox> is that good enough KJanowic ?

kerry: agree with, Raul has offered to look into doing a survey of old implementations. By the end of the year.

<KJanowic> @simonCox: it is not clear of what non-normative means for the formal semantics of OWL

<KJanowic> axioms don't care about whether they are normative or not, they either imply something or they don't

ahaller2: in terms of relation between newssn:observation and oldssn:observation, there is none! therefore no alignment there

<KJanowic> +1 to no relation

<scribe> agenda: Current SOSA core, scope of terms

https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl

<SimonCox> kerry: alignment axioms (equivalence) will constrain SOSA-core

<SimonCox> Suggest avoiding 'Process' because in BFO Process is an occurrent

<KJanowic> this is about magnitude not information vs. non-information resource

<SimonCox> (though Process used in this way would be aligned with SensorML)

<Zakim> kerry, you wanted to ask krystof about how much he can live with inconsistent normative or not alignments

<KJanowic> kerry: not because I want to be mean but because there may be disjointness axioms hidden there

<SimonCox> KJanowic: normative vs non-normative OK for humans, but will trip up m2m usage

KJanowic: if the file sits somewhere our ontology becomes inconsistent

<SimonCox> ahaller2: propose no alignment for concepts where there is a conflict - only have alignment axioms where there is real equivalence

KJanowic: Procedure vs Process. There is one thing that is the cooking recipe how to make the sensor work and then each observation done using the same procedure is comparable.

<SimonCox> Does "procedure" include either the sensor type, or even sensor instance KJanowic ?

KJanowic: every time you follow the procedure, instantiation. It is a workflow.

<Zakim> SimonCox, you wanted to discuss use of word "Process" vs "Procedure"

SimonCox: naming is less important than to agree what it is

<SimonCox> ... Procedure is a re-usable thing

http://www.aiai.ed.ac.uk/project/wfmc/ARCHIVE/DOCS/glossary/gloss2.gif

<KJanowic> This is what we had as text "A workflow, protocol, plan, algorithm, or computational method specifying how to set up an Observation, take a Sample, or make a change to the state of the world (via an Actuator). A Procedure is re-usable, and might be involved in many observations, samplings, or actuations. It explains the steps to be carried out to arrive at reproducible results. Put differently, millions of observations may be created via the same Proced[CUT]

<KJanowic> My problem with 'process' is its meaning wrt event, action, and so forth. Process is a perdurant.

<KJanowic> Do we agree that an observation is the carrying out of the procedure/process?

+1

<KJanowic> great

<DanhLePhuoc> +q

<Zakim> kerry, you wanted to note something important procedurally

<SimonCox> ... or 'an observation is an event that utilises or executes the procedure/process'

<SimonCox> (that was in response to KJanowic)

DanhLePhuoc: I asked before, are we using RDF(S) or are we using some OWL in here, inverse, meta

<KJanowic> super difficult discussion, would be better to open this up to the group

<KJanowic> I would leave it as it is

<KJanowic> e.g., sosa-core:Observation rdf:type owl:Class ;

DanhLePhuoc: make the formal semantics clear

<kerry> +1 to open it up

<kerry> +1 make sure the agenda is clear for each meeting

<DanhLePhuoc> +1

<KJanowic> fine with me

<DanhLePhuoc> +Q

<SimonCox> Weekly meetings from now on ok from me +1

<DanhLePhuoc> http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/01.01.01_60/ts_103264v010101p.pdf

<DanhLePhuoc> https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology

DanhLePhuoc: reached out to them already

kerry: happy to get involved with her
... contact monica and have a chat about the status of the ETSI smart appliances ontology

DanhLePhuoc: also potentially an evidence of implementation

<SimonCox> THanks folks - useful meeting

<KJanowic> Thanks a lot for the productive meeting today. Bye, Bye