Spatial Data on the Web SSN Sub Group Teleconference

Patent call https://www.w3.org/2015/spatial/wiki/Patent_Call

<SimonCox> approve last week's minutes?

<phila_car> Last week's minutes

approve last week's minutes

<KJanowic> +1

<DanhLePhuoc> +1

<ahaller2> +1

<SimonCox> +1

<RaulGarciaCastro> +1

<phila_car> +1

<mlefranc> +1

Alignment of SOSA/SSN with O&M shall denote classes and properties from the ISO 19156 O&M UML model using URIs which are defined in ISO 19150-2, and are currently visible in ontology files available from https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology/19156/2011

+1 - noting i was in fact present ..

simoncox reiterated the proposal

<SimonCox> RobA is the scribe!

<Zakim> phila_car, you wanted to talk URIs

kerry_: is this only as ref to the O&M model

<ahaller2> PROPOSAL: Alignment of SOSA/SSN with O&M shall denote classes and properties from the ISO 19156 O&M UML model using URIs which are defined in ISO 19150-2, and are currently visible in ontology files available from https://github.com/ISO-TC211/GOM/tree/master/istoc211_GOM_harmonizedOntology/19156/2011

phila: discussed with ISO, "good will" regarding intent here, dereferencing mechanics to be taken care of

<KJanowic> +1

<SimonCox> +1

<ahaller2> +1

<kerry_> +1

<mlefranc> +1

+1

<DanhLePhuoc> +1

<phila_car> +1

ahaller2: commit to git?

SimonCox: in wiki ready top drop in when appropriate

<SimonCox> https://www.w3.org/2015/spatial/wiki/Alignment_to_O%26M

KJanowic: multiple edits to wiki is hard to track - can we discuss on email and one person edit?
... specifically when options are being edited, email discussion can be made ambiguous

<KJanowic> fine with me

kerry_: lots of stuff on email - comments fragment and get lost - wiki capture is better - proposes comments wiki page if in-line comments a problem

<KJanowic> (I never suggested that)

agree with kerry - wiki style, email is too hard to folloow current state

@ahaller 2 do you want to propose a way or do i need to capture those rtecommendations?

<kerry_> +1

<SimonCox> roba: then you need to write "RESOLVED:" afterwards

PROPOSED: That options are not changed in substance on the wiki, and new options provided if needed

<ahaller2> +1

<KJanowic> +1

<mlefranc> +1

<kerry_> +1

+1

<SimonCox> +1

<DanhLePhuoc> +1

<ClausStadler> +1

kerry_: please link pages in so they can be found

<mlefranc> https://www.w3.org/2015/spatial/wiki/Main_Page -> https://www.w3.org/2015/spatial/wiki/Semantic_Sensor_Network_Ontology

SOSA pattern for Observation and Value: remove hasValue, keep class Result as of Option 3 on wiki: https://www.w3.org/2015/spatial/wiki/

<SimonCox> Its linked from here: https://www.w3.org/2015/spatial/wiki/Semantic_Sensor_Network_Ontology

<KJanowic> Can you post the link

<ahaller2> SOSA pattern for Observation and Value: remove hasValue, keep class Result as of Option 3 on wiki: https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_Value:_remove_hasValue.2C_keep_class_Result https://www.w3.org/2015/spatial/track/issues/90

kerry_: the discussion is not complete enough yet - e.g. how oldSSN can be transitioned to model
... deprecating classes without working out how the alignment would work is a "cop-out"

ahller2: so object to voting on this today?

kerry_: depends on the wording on the proposal

<KJanowic> other people would like to speak too

kerry_: have mentioned these issues on list

KJanowic: option 3 does not allow simple SOSA to refer to the value - would prefer a new(?) option 5

<KJanowic> I am fine with option 3 but 5 would allow sosa users to directly publish observation values without having to learn how to do this with the help of other ontologies (which is important for sosa users)

<KJanowic> @roba: it would be option 5 (as is)

mlefranc: preferes to vote today - find some common ground

@KJanowic thanks for clarifying

<KJanowic> +1 to voting today, we have been putting issues aside for months

<KJanowic> I agree with ahaller2 (on results)

<RaulGarciaCastro> Today we can vote on selecting one of the options, but we cannot decide on the concrete implementations because they are incomplete

<SimonCox> potential PROPOSAL: Actuation + Actuator shall be included in SOSA

<kerry_> I am proposing that in option 3 we change 'result" back to "observedvalue"

<phila_car> I wanted to say it sounds as if there is consensus on moving forward but that Kerry still has concerns

<phila_car> OK, so vote to move forward but invite kerry to come back with specific modifications after the vot

<KJanowic> +1 to simon (on keeping result)

SimonCox: result of actuation or sample not an "ObservationValue"

kerry_: notes SensorML uses ObservationValue terminology

<KJanowic> option 5 is option 3 + a direct way for sosa users to assign values to observations which is very important. We can also change the hasValue name if this is the only problem

<SimonCox> Yes - Kerry does have a point, superclass Result conflates several rather different concepts (including 'Sample' which is the outcome of a sampling activity)

<ahaller2> roba: Option 5 has a number of TODOs and question marks. If I do an actuation, I get a result back, which includes the observed value, for example, it is "on now"

<KJanowic> Yes +1 on that

<KJanowic> I like this idea!

Kjanowic: have not yet considerd actuation - may needs broadeing as Option 5

<KJanowic> I would be pretty unhappy with option 4

<ClausStadler> an actuation result seems to me more like the return value of a function invocation - if i say: rotate some component by 45 degree, the result may be a pointer (URI) to a sequence of observations being made as the action runs.

<KJanowic> +1 to having a vote and keep improving!

phila: good conversation about technical details - urges some sort of vote to demonstrate progres - can amend later if needed

<mlefranc> +1

<laurent_oz> +1

<KJanowic> IMHO, too general

<KJanowic> option 4 is like voting on almost nothing, let's be brave ;-)

<ahaller2> PROPOSED: SOSA pattern for Observation and Value: remove hasValue, keep class Result as of Option 3 on wiki: https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_Value:_remove_hasValue.2C_keep_class_Result , pending a modelling decision on isProducedBy, and a decision on how to attach values in SOSA

<mlefranc> can me further specialized

<KJanowic> +1

<DanhLePhuoc> +1

<KJanowic> than do :-)

<SimonCox> +1

<mlefranc> PROPOSED: SOSA patter for observation and value: do not vote about "hasValue" yet, keep some class, name it Result for now, nearly as of option 3 in wiki

<mlefranc> +1

+0

<Zakim> kerry_, you wanted to not claus'es remark

<KJanowic> I would not like this idea, this is like voting on nothing

<KJanowic> it is, for example, a change of state

<SimonCox> What is the result of an actuation? See RobA emails on list

kerry_: ref ClausStadler comment - what is an actuation result? Lack of discussion about this

<KJanowic> we are going in circles again

Thats why i voted +0 - wasnt 100% sure the model was completely described

<SimonCox> q

<SimonCox> q

<KJanowic> +1 to that

phila: is actuation result just a followon issue? OK to vote,

<mlefranc> +1

<mlefranc> ok

+1 to that. We need treatment of consequences now, and then revisit if needed

<ahaller2_> PROPOSED: SOSA pattern for Observation and Value: remove hasValue, keep class Result as of Option 3 on wiki: https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value#Option_3:_SOSA_pattern_for_Observation_and_Value:_remove_hasValue.2C_keep_class_Result

<KJanowic> +1

<mlefranc> +1

+1

<SimonCox> +1

<ahaller2_> +1

<DanhLePhuoc> +1

<Raul> +1

<kerry_> 0

<laurent_oz> 0

<mlefranc> action ?

<KJanowic> great, can we brielfy talk about the actuation part?

ahller2: agenda next meeting to include followup options and descriptions

Include Actuation, ActuableProperty and Actuator class with associated relations (invokedBy, actuatedProperty) in SOSA as of proposal on wiki: https://www.w3.org/2015/spatial/wiki/Actuation_in_SOSA

KJanowic: describes proposal on wiki.

<SimonCox> Window example: window has a property "open" with boolean value.

<mlefranc> (apparently I accidentally deleted all my edits in the wiki. please refresh your browser now)

<ahaller2_> roba: actuableproperty is promoted to be a special case in this option

<KJanowic> we do have observableproperty

<SimonCox> Actuation changes the value of this property from "true" to "false"

<KJanowic> no it has these axioms

<SimonCox> Note also distinction between ActuableProperty and actuatedProperty - nice!

<laurent_oz> We worked on this topic at the time of the XG, check this post on the mailing list: https://lists.w3.org/Archives/Public/public-xg-ssn/2010Feb/0002.html (please have a look)

<KJanowic> I will add the axioms and options

<KJanowic> we can discuss this next week

<SimonCox> ... and I will work up Sampling equivalent

<KJanowic> @ahaller2_ I will add the code and options for next week's discussion

KJanowic: confirms q from roba that its just the diagram incomplete - not representing the full proposed model here,

kerry_: seems reasonable - can we apply Use Cases to this pattern now to make sure we understand it

<KJanowic> will do so

<RaulGarciaCastro> In the WoT group they are defining as interaction patterns Properties and Actions (also events but these are not fix yet (https://w3c.github.io/wot/current-practices/wot-practices.html#interaction-patterns)

<KJanowic> [I cannot hear maxime]

<mlefranc> I like the idea that actuation and actuator is in sosa

mlefranc: reservations about names, but would like to vote to accept concept of actuation in SOSA

<KJanowic> I will

ahller2: asks for wiki to be updated with options to vote on next week

<mlefranc> I like the idea that we just mimic the observation/sensor/sensing for actuation/acutator/actuating, and limit the number of new terms

<SimonCox> Bye

<KJanowic> thanks for the productive telco today

<KJanowic> bye bye

<mlefranc> thans

bye all

<RaulGarciaCastro> Bye!

<kerry_> bye!