Spatial Data on the Web SSN Task Force Group Teleconference
04 April 2017
<mlefranc> +1
-1
<RaulGarciaCastro> +1
<ahaller2> +1
<SimonCox> +1
<tidoust> +1
<DanhLePhuoc> +1
please add regrets for kerry to minutes
<KJanowic> +1
phila: I can do it
+1
<RaulGarciaCastro> https://www.w3.org/2015/spatial/track/issues/117
<ahaller2> https://www.w3.org/2015/spatial/track/issues/111
issue-117?
<trackbot> issue-117 -- The dul:includesEvent property has disapeared -- open
<trackbot> http://www.w3.org/2015/spatial/track/issues/117
<ChrisLittle> * no audio, just lurking
<phila> [Minutes from last week amended to show Kerry's regrets, originally given at https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170328]
armin invites raul to speak
raul: at end of page can see implementation
… new prop was isStimulatedBy
armin: can we close the issue? questions?
<phila> close issue-117
<trackbot> Closed issue-117.
<phila> issue-111?
<trackbot> issue-111 -- SOSA/SSN mapping to O&M needed -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/111
<phila> action-295?
<trackbot> action-295 -- Maxime Lefrançois to And kjanowic to propose implementation options for option 2 on the wiki: https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators -- due 2017-04-04 -- OPEN
<trackbot> http://www.w3.org/2015/spatial/track/actions/295
<mlefranc> https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
armin: maxime or krz to speak on this?
maxime: the main issue is properties that can also apply to actuators (Measurement props)
three options (too fast) discussed last week
...worked on implementing option 2
<KJanowic> Maxime did all the work on this so far so I leave it to him to introduce the changes
maxime: measurementX becomes systemX
… you can see I tried to rewrite most of the defs so they now apply to system
… would like to introduce repeatability for actuators
… [not keeping up]
… old classes and props would become sub- of these new ones.
armin: looks good to me
<RaulGarciaCastro> also good for me
armin: what do others thing?
<KJanowic> I did not really have time to look into this in detail as they were pubished yesterday but it looks good to me
kJanowic has not looked at it, agrees do an implementation
ahaller2: giving an anction item
Action: maxime to implement the changes proposed in https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators in ssn
<trackbot> Created ACTION-301 - Implement the changes proposed in https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators in ssn [on Maxime Lefrançois - due 2017-04-11].
<mlefranc> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0233.html
mlefranc: draw attention to issue
… measurement range has moved so now way systems linked to capabilities now duplicated --- but called Xrange
… so we have a structure for measurement propoerties and measurement range
… [not keeping up]
… asking for opinion
ahaller2: anyone recall why this is so?
mlefranc: suggest deprecate previous measurement range
… or rename
… i prefer the former
ahaller2: agrees
<phila> kerry: For the previous topic and this one, I can't keep up with adding various links to the IRC
<phila> kerry: If people don't have time to comment, maybe the option is to do nothing.
ahaller2: have been talking for past meetings
<phila> ahaller2: It's not a new issue, we've been talking about it for the last 2 meetings
<phila> ahaller2: Comments on the pull requests usually works well
ahaller2: any other comments?
… please maxime indicate which issue in PR -- do 2 PRs
ahaller2: krz what did you do here?
<phila> issue-296
<trackbot> Sorry, but issue-296 does not exist.
<phila> action-296
<trackbot> action-296 -- Krzysztof Janowicz to Look into https://www.w3.org/2015/spatial/track/issues/153 and propose a solution -- due 2017-04-04 -- OPEN
<trackbot> http://www.w3.org/2015/spatial/track/actions/296
<ahaller2> https://www.w3.org/2015/spatial/track/issues/153
<phila> issue-153
<trackbot> issue-153 -- reconsider role of device in ssn as a result of the changes to platform required for sosa -- raised
<trackbot> http://www.w3.org/2015/spatial/track/issues/153
KJanowic: link broken -- if about putting in writing not done yet, only changed source code
ahaller2: [missed] around changes to sensing devices and device class
<KJanowic> Okay sorry, I have no updates on this for this week.
ahaller2: around sensingdevice -- action was to look at old class and deal wit hthat sensors and actuators can now attach to platofrms directly
… was an email sent
KJanowic: i will do this next week
ahaller2: i will change date on action item
<phila> action-298
<trackbot> action-298 -- Maxime Lefrançois to Send an email to the list to list classes/properties in ssn from the "integrated" directory that we have not discussed yet -- due 2017-04-04 -- OPEN
<trackbot> http://www.w3.org/2015/spatial/track/actions/298
<mlefranc> https://www.w3.org/2015/spatial/wiki/Terms
ahaller2: maxime sent an email and made a wiki page
mlefranc: i posted the link - you can see i split the old ssn terms into little "modules" and
<ahaller2> close action-298
<trackbot> Closed action-298.
mlefranc: the third col is the new term in the lite vs the full ontology
… if we agree on all the axioms and naming and alignment ...
… ot all finished yet.
… at the right we can put comments if needed
… we should go through them quickly
ahaller2: has anyone looked? some of this is still open issues and many are terms we have not yet discussed
… could be left unchanged unless there is n issue
… maybe if we cannot find implementations we could deprectate
… maybe just there is nothing wrong with the status quo
KJanowic: i already worte something 2 hours ago -- I am surprised about sensing
… old ssn distinguished sensing (process) from observation -- the latter is the setting or context
… in a f2f we agrred that observation should be an activity
… so we don't need sensing any more
ahaller2: propose to deprecate sensing?
KJanowic: yes
<KJanowic> "Sensing is a process that results in the estimation, or calculation, of the value of a phenomenon."
mlefranc: i disagree -- the old process class has been renamed procedure and the old sensing class was a subclass, so not the actof but now a procedure that results in the [missed]
<KJanowic> That would not work as procedure means something slightly different
mlefranc: could rename sesning as sensingprocedure
… could also have actuatingprocuedure
KJanowic: this is more complicated becuase one procedure for several observations
<mlefranc> definition: Sensing is a procedure that results in the estimation, or calculation, of the value of a phenomenon.
the sensing is the act of carrying out -- the actual thing each time
... i would simply deprecate
<KJanowic> we can deprecated sensing
<phila> kerry: I'm confused... I wasn't keeping up fully with that conversation. I don't think anyone has replaced observation with sensing...
<KJanowic> that is what I proposed
<phila> ... I can't see that it's disappeared but I may not be keeping up
<phila> ... The change of procedure to process I lost track of
KJanowic: so observation is the act
… to translate stimulus to a result
… which is different to a social construct
… like a nexus (as neon and dulce would do it)
… we don't need to use the sensing any more
… so i would deprecate the sensing class
<KJanowic> observation is now the act of carrying out the activity that the snesor performs to translate the stimulus to a result
ahaller2: makes sense
<mlefranc> * kerry, mute yourself please :-)
<KJanowic> [please mute yourself when you type :-)]
ahaller2: action item? alternative is to intro a similar class for actuation pattern
… what you just said about stimulus is more complicated
… per definition of stimulus you canot have implementations of that
ahaller2: propose issue a pr
<KJanowic> The 'stimulus' is the thing that triggers a sensor, therefore it has no instances. It is part of the ontological modeling framework
mlefranc: there are some claer options -- a Pr is a bit too quick
<KJanowic> Okay, I can do so
mlefranc: suggest a new page "sensing and actuating" is already there
<KJanowic> but this is not covered by the term 'observation'
mlefranc: to me you can instantiate sensing and do some cooking to make an observation.
<SimonCox> Note I introduced a 'ObservationProcedure' class in the O&M alignment
KJanowic: please lay at options and explain rationale - a bit too early for pr -- deprecating will be the easist
ahaller2: can deprecate or rename or make it like actuation -- please lay out options on wiki
<SimonCox> 'ObservationProcedure' is a sub-class of Procedure
<SimonCox> also SamplingProcedure and ActuationProcedure
Action: KJanowic to propose options on Sensing class for SSN new
<trackbot> Created ACTION-302 - Propose options on sensing class for ssn new [on Krzysztof Janowicz - due 2017-04-11].
ahaller2: still on topic for this wiki page -- some more issues are there
<SimonCox> http://w3c.github.io/sdw/ssn/#OM_Alignment_utility
ahaller2: I don't think we can go through all the terms here but we can invite people to look who have not had time yet
… is there anything specific we should look at now?
mlefranc: the first on feature of interest and propoerties /hasproperry/ispropertyog
… should they be in sosa and ssn or deprecate latogether?
ahaller2: we did something here ... i thoight we had them unchanged
… they are used in sosa comments although they o not exist
<KJanowic> hmm, can you give examples?
ahaller2: linkinf geatureofinterest and properties
… strange if used in text but not defined in sosa at all
KJanowic: am confused
<mlefranc> Activity of carrying out an (Observation) Procedure to estimate or calculate a value of a Property of a FeatureOfInterest.
mlefranc: will provide example
<KJanowic> yes, the observedProperty!
mlefranc: here is an implicit link between prop and feature
ahaller2: in some comments we need to make sure that if something is not a class it should not be capitalised
KJanowic: but that sentence is totally ok
… the only propble is Property should not be upper case?
ahaller2: [agrees]
<KJanowic> sosa:ObservableProperty
KJanowic: i will go throuigh it all and check each text def matches the axioms
ahaller2: i can do that
<ahaller2> ACTION ahaller2 checking definitions in SOSA to make sure we do not reference terms in capital letters that are not terms in the ontology
<trackbot> Created ACTION-303 - Checking definitions in sosa to make sure we do not reference terms in capital letters that are not terms in the ontology [on Armin Haller - due 2017-04-11].
s.problem/problem/
<mlefranc> see definition of sosa:observedProperty: Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.
<KJanowic> again only a naming issue
mlefranc: I can help but here is another example of the problem -- it is not just case
… the observed property is a property and it is called hasProperty which is not in sosa
ahaller2: i will check all these -- some of the comments are out of date
KJanowic: agrees
<KJanowic> I agree with Simon, no way of being 'feature complete'
SimonCox: want to comment on hasProperty - the reality is that there is an unlimited set of relations are possible
… business iof providding a generic metamodel... in order to c0onnect with all possible things is maybe intersting
<KJanowic> I would strongly suggest not to have a very generic hasProperty property.
SimonCox: from a completeness point of view
… e.g geospatial part of iso.. does not make the worl;d a better place
… i say that rdf property is not present but this is not a major problem
<KJanowic> hasProperty was a name we used tome time ago that has been replaced some time ago
ahaller2: is only used in property path .. doe we need to deprecate?
mlefranc: i understand simon's point but it is used , so options fr ssn are put in sosa, change text, and I sue them extensivlely
<KJanowic> okay with me
<SimonCox> If they are used, then they should stay - I withdraw my objection - leave them in the 'full' ontology
ahaller2: do not want it in sosa --- i will fix up text in sosa
phila: it sounds like this makes sense
… am looking at feature ofinterest -- there is a class and a property
… ssn has "featureofinterest" without the "has"
… are we making anypro
<SimonCox> +1 phila - 'hasFeatureOfInterest' rather than 'featureOfInterest'
are me using any propert with the same name as the class (with only prperty differnt?)
ahaller2: intention is we don't it must be leftover
KJanowic: thanks for spotting
… we have done a lot of renaming over past few meetings
… there are so many things we need to keep track of and things get out of sync
… there will be no such cases.
ahaller2: editors are stuggling to keep up with speed of change
<KJanowic> Sometimes a simple change in one file triggers changes in many different files and we need to keep everything in sync but sometimes there will be meetings where this is not the case as syncing has not yet taken place.
ahaller2: we also have an issue of internationalisation of comments
can we do that when under review? or does it need to be done beforejnad
..we do not have time in next 3 weeks
... yes for the doc in ns space, but tr space doc is only in English
... so yes, no timeout at all
ahaller2: 2 options for isproperty and has proerty
<KJanowic> keep in new-ssn, we do not include it in sosa?
ahaller2: just need to vlean up comments in sosa
ahaller2: still working on comments in english -- will do translations later
<mlefranc> ok
KJanowic: is there a vote?
… something that means we do not revisits
<ahaller2> PROPOSED: hasProperty and isPropertyOf remain in SSN new as is
<KJanowic> but not in SOSA
<KJanowic> +1
+1
<mlefranc> 0
<ahaller2> +1
<RaulGarciaCastro> 0
<DanhLePhuoc> 0
<SimonCox> +1
Resolved: hasProperty and isPropertyOf remain in SSN new as is
ahaller2: i will clean up any reference in sosa
<KJanowic> I can take over
ahaller2: scribe?
<ahaller2> scribe KJanowic
<ahaller2> scribenick KJanowic
<KJanowic> https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN
<ahaller2> https://www.w3.org/2015/spatial/track/actions/284
<DanhLePhuoc> +1
<ahaller2> KJanowic: startTime and endTime was decided to be deprecated
<ahaller2> ... system, latencylifetime etc. are some other time properties
<ahaller2> ... samplingTime = phenomenonTime was introduced earlier
<ahaller2> ... sosa:phenomenonTime and sosa:resultTime was proposed to be the only time properties left
one has one was not
<DanhLePhuoc> +qq
The proposal on the table is "Deprecate ssn:observationSamplingTime and ssn:observationResultTime and use sosa:phenomenonTime and sosa:resultTime exclusively, making both of them object type properties (that make use of the new OWL-Time). "
exactly my concern as well but see Raul's reply
@DanhLePhuoc we will generate a lot of more data, performance-wise this may be an issue worth considering
we will need an extra triple every time we have a result time and this will be very frequent
kerry: these would be the only time properties, yes?
kj: yes,those are unchanged
ahaller2: if we get implementation evidence, we will keep them
ahaller2: define both as rdf property and then in ssn-new make them datatype and objecttype properties.
<SimonCox> I think the issue is between model and implementation ...
Maxime:
This could be interesting, these are the side effects I can think of now: - we would need to assert these properties are instances of AnnotationProperty, else the ontology would not be OWL DL; - no ontology that extends SSN can assert it's also a ObjectProperty or a DatatypeProperty; - one cannot make this property be involved in a OWL logical axiom in any possible way, apart from rdfs:domain, rdfs:range, and rdfs:subPropertyOf; - still, people can crea[CUT]
<SimonCox> In principle it is indeed an object property (with time-instant as the object) but there is a simpler solution in the implementation layer.
kerry: no, I do not think that this is true
<SimonCox> By 'building in' the XSD types, OWL doesn't separate concerns properly, so we get problems like this ...
maxime: then you are not in OWL2 DL
maxime we should use one of those
ahaller2: we would only use rdf:Property in SOSA and ObjectProperty or a DatatypeProperty in SSN
kerry: agrees with ahaller
ahaller and kj: keep the current version in which resultTime remains a datatype property
danh: the user can directly attach the simple value
danh: no need to introduce a blank node here as this will be so commonly used
danh: data more important
kerry: supports that Danh said
kerry: what is the use case for not having result time just being a time stamp
why does it need to be an objecttype property
raul: The idea of having them as object type properties was to use the time ontology and allow users to select which one to select.
Raul: I think this has a lot of value, maybe somebody wants to use more complex time models
Maxime: if we keep them as is, I just want to make sure that they will never be linked by subproperty axioms
<RaulGarciaCastro> For example
Kerry: Raul, I think you convinced me. Example: satellite images.
kj: I do not understand the satellite example
<SimonCox> Definition of resultTime is 'when the act was completed' so it is axiomatically a time stamp (instant)!
Kerry: why not have a simple and a more complex solution?
<DanhLePhuoc> +1
Simon: Agree with KJ. ResultTime is a time stamp. It is when the entire observation act is completed. This was done by design in O&M and does away with the problem. So, by definition resultTime is an instant. No matter how long the observation process takes, the resultTime is when the process finished.
ClausStadler: In some cases people model time using time intervals and their relations.
claus: kerry's approach will give you the flexibility
<Zakim> kerry, you wanted to correct that use case
ahaller2: let us reverse the pattern here and have the simple case be the default and intorduce the complex case for SSN only. Conceptual neighborhoods vor resultTimes may matter but would be very rare
Kerry: totally with Armin and Claus.
Kerry: let us just not call it complextime.
but this is the satellite use case is all about resulttime, not processing timewe are discussing right now
<SimonCox> If a particular application needs a more sophisticated set of time properties, then these can be added in an ontology for that application.
let us vote on the idea first, then on the exact name.
sometimes we all agree on the issue but disagree on the name :-)
<ahaller2> PROPOSED: phenomenonTime is an object property, resultTime a datatype property in SOSA and SSN will introduce a new complex result time property (pending name) that is an object property
+1
<ahaller2> +1
<DanhLePhuoc> +1
<kerry> +1
<ClausStadler> +1
<mlefranc> 0
<RaulGarciaCastro> 0
<SimonCox> +0.5 because not sure about '*will* introduce'
simon: may, not will
Resolved: phenomenonTime is an object property, resultTime a datatype property in SOSA and SSN will introduce a new complex result time property (pending name) that is an object propert
<SimonCox> 'resultTime' is 'when the result became available'
kj: they will have a slightly different semantics; we will need to change the definition in sosa.ttl
Kerry: most useful if it was allowed for an observation to [did not get the rest]
Kerry: would drop the term instant
Kerry: the time at which the observation was made and you can do what you like with it.
Claus: the simple value is just the quantification.
Claus: the complex version can get an URI
kj: IMHO 'whatever you want' is always dangerous when it comes to definitions within an ontology
SimonCox: I would like to get back to the real semantics of resultTime. The satellite sensing case gets stimuli over a long time but this is not what resultTime expresses but phenomenonTime.
SimonCox: Many possible time properties but let us not try to define all of them. What we have covers the most common cases
SimonCox: I am worried about a time property without clear semantics.
SimonCox: we should not leave this up to the data providers and users.
Claus: in principle yes.
kj: this is very similar to how pellet handled spatial topology
Claus: not exactly sure how that will work.
Claus: okay, so maybe it is really not necessary.
<SimonCox> [someone typing very loud!]
Ahaller2: can we work out a use case for next week?
claus: kj, can you help?
kj: sure
Action: ClausStadler to investigate the need of a complex resultTime property in SSN new
<trackbot> Created ACTION-304 - Investigate the need of a complex resulttime property in ssn new [on Claus Stadler - due 2017-04-11].
Danh: one more example: sensor that has to calibrate the reading for a few minutes. It will present the data as observations that have a start time and end time.
Danh: measuring the speed of the car is one example. This uses a time interval.
<SimonCox> +1 KJanowic - that's exactly why it was named 'result-time' !
<ahaller2> zakim close queue
Kerry: minor correction [quoting result time]
Kerry: asks for clarification of what ‘becomes available’ means.
<SimonCox> ... what I wrote at 23:42
kj: we need simon to speak about this
Kerry: again, I believe we need both.
<ClausStadler> +1 to KJanowic and SimonCox in regard to 'result-time'
Can do so
I will add it to the current wiki page
<SimonCox> 'became available' might mean 'inserted in data-store' or 'appeared on readout' or 'put on the wire' ...
Action: KJanowic to revisit the rdfs:comment on sosa:resultTime
<trackbot> Created ACTION-305 - Revisit the rdfs:comment on sosa:resulttime [on Krzysztof Janowicz - due 2017-04-11].
<ahaller2> https://beta.doodle.com/poll/25yhn8a5ibg5c88u#table
Ahaller2: reminds everybody of the doodle poll.
<kerry> so resulttime means "recording time"?
I do not see this timeslot on the doodle
<ahaller2> https://www.w3.org/2015/spatial/wiki/Open_Issues
<SimonCox> kerry: in some cases, but 'became available' encompasses other possibilities
<SimonCox> Well done all
ahaller2: we need to close all these issues in said meeting
<RaulGarciaCastro> Bye!
Thanks everybody for this very productive meeting!
bye bye
<kerry> bye!
<ChrisLittle> bye