- From: Phil Archer <phila@w3.org>
- Date: Tue, 4 Apr 2017 23:07:51 +0100
- To: SDW WG Public List <public-sdw-wg@w3.org>
The minutes of this week's SSN meeting are at
https://www.w3.org/2017/04/04-sdwssn-minutes with a snapshot below.
Progress is being made...
Spatial Data on the Web SSN Task Force Group Teleconference
04 April 2017
[2]Agenda [3]IRC log
[2] https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170404
[3] http://www.w3.org/2017/04/04-sdwssn-irc
Attendees
Present
ahaller2, ChrisLittle, ClausStadler, DanhLePhuoc,
Francois, kerry, KJanowic, mlefranc, phila,
RaulGarciaCastro, SimonCox
Regrets
Rob, Scott
Chair
Armin
Scribe
kerry, KJanowic
Contents
* [4]Meeting Minutes
1. [5]Approving last meeting's minutes https://
www.w3.org/2017/03/28-sdwssn-minutes
2. [6]Patent Call https://www.w3.org/2015/spatial/wiki/
Patent_Call
3. [7]Progress on issue ISSUE-117, replace isStimulatedBy
by wasOriginatedBy
4. [8]Progress on ACTION 295 to propose implementation
options for Option 2 on the wiki: https://
www.w3.org/2015/spatial/wiki/Measurement_and_Opera
ting_properties_for_actuators
5. [9]Action-295
6. [10]Progress on https://www.w3.org/2015/spatial/track/
actions/296 to look into https://
www.w3.org/2015/spatial/track/issues/153 and
propose a solution
7. [11]Progress on ACTION-298 to send an email to the
list to list classes/properties in SSN from the
"integrated" directory that we have not discussed yet
8. [12]Progress on ACTION-284, temporal properties in
both SOSA/SSN
* [13]Summary of Action Items
* [14]Summary of Resolutions
Meeting Minutes
Approving last meeting's minutes [15]https://www.w3.org/2017/03/
28-sdwssn-minutes
[15] https://www.w3.org/2017/03/28-sdwssn-minutes
<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
Patent Call [16]https://www.w3.org/2015/spatial/wiki/Patent_Call
[16] https://www.w3.org/2015/spatial/wiki/Patent_Call
Progress on issue ISSUE-117, replace isStimulatedBy by
wasOriginatedBy
<RaulGarciaCastro> [17]https://www.w3.org/2015/spatial/track/
issues/117
[17] https://www.w3.org/2015/spatial/track/issues/117
<ahaller2> [18]https://www.w3.org/2015/spatial/track/issues/111
[18] https://www.w3.org/2015/spatial/track/issues/111
issue-117?
<trackbot> issue-117 -- The dul:includesEvent property has
disapeared -- open
<trackbot> [19]http://www.w3.org/2015/spatial/track/issues/117
[19] 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 [20]https://www.w3.org/2015/
spatial/wiki/Meetings:SSN-Telecon20170328]
[20]
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> [21]http://www.w3.org/2015/spatial/track/issues/111
[21] http://www.w3.org/2015/spatial/track/issues/111
Progress on ACTION 295 to propose implementation options for Option 2
on the wiki: [22]https://
www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties
_for_actuators
[22]
https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
<phila> action-295?
<trackbot> action-295 -- Maxime Lefrançois to And kjanowic to
propose implementation options for option 2 on the wiki:
[23]https://www.w3.org/2015/spatial/wiki/
measurement_and_operating_properties_for_actuators -- due
2017-04-04 -- OPEN
[23]
https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators
<trackbot> [24]http://www.w3.org/2015/spatial/track/actions/295
[24] http://www.w3.org/2015/spatial/track/actions/295
<mlefranc> [25]https://www.w3.org/2015/spatial/wiki/
Measurement_and_Operating_properties_for_actuators
[25]
https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
Action-295
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
[26]https://www.w3.org/2015/spatial/wiki/
Measurement_and_Operating_properties_for_actuators in ssn
[26]
https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators
<trackbot> Created ACTION-301 - Implement the changes proposed
in [27]https://www.w3.org/2015/spatial/wiki/
measurement_and_operating_properties_for_actuators in ssn [on
Maxime Lefrançois - due 2017-04-11].
[27]
https://www.w3.org/2015/spatial/wiki/measurement_and_operating_properties_for_actuators
<mlefranc> [28]https://lists.w3.org/Archives/Public/
public-sdw-wg/2017Mar/0233.html
[28]
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
Progress on [29]https://www.w3.org/2015/spatial/track/actions/296 to
look into [30]https://www.w3.org/2015/spatial/track/issues/153
and propose a solution
[29] https://www.w3.org/2015/spatial/track/actions/296
[30] https://www.w3.org/2015/spatial/track/issues/153
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
[31]https://www.w3.org/2015/spatial/track/issues/153 and
propose a solution -- due 2017-04-04 -- OPEN
[31] https://www.w3.org/2015/spatial/track/issues/153
<trackbot> [32]http://www.w3.org/2015/spatial/track/actions/296
[32] http://www.w3.org/2015/spatial/track/actions/296
<ahaller2> [33]https://www.w3.org/2015/spatial/track/issues/153
[33] 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> [34]http://www.w3.org/2015/spatial/track/issues/153
[34] 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
Progress on ACTION-298 to send an email to the list to list
classes/properties in SSN from the "integrated" directory that we
have not discussed yet
<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> [35]http://www.w3.org/2015/spatial/track/actions/298
[35] http://www.w3.org/2015/spatial/track/actions/298
<mlefranc> [36]https://www.w3.org/2015/spatial/wiki/Terms
[36] 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> [37]https://www.w3.org/2015/spatial/wiki/
index.php?title=Sensing_and_Actuating&action=edit&redlink=1
[37]
https://www.w3.org/2015/spatial/wiki/index.php?title=Sensing_and_Actuating&action=edit&redlink=1
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> [38]http://w3c.github.io/sdw/
ssn/#OM_Alignment_utility
[38] 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
Progress on ACTION-284, temporal properties in both SOSA/SSN
<KJanowic> [39]https://www.w3.org/2015/spatial/wiki/
Time_in_SOSA_and_SSN
[39] https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN
<ahaller2> [40]https://www.w3.org/2015/spatial/track/actions/
284
[40] 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> [41]https://beta.doodle.com/poll/
25yhn8a5ibg5c88u#table
[41] 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> [42]https://www.w3.org/2015/spatial/wiki/Open_Issues
[42] 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
Summary of Action Items
1. [43]maxime to implement the changes proposed in https://
www.w3.org/2015/spatial/wiki/
Measurement_and_Operating_properties_for_actuators in ssn
2. [44]KJanowic to propose options on Sensing class for SSN
new
3. [45]ClausStadler to investigate the need of a complex
resultTime property in SSN new
4. [46]KJanowic to revisit the rdfs:comment on sosa:resultTime
Summary of Resolutions
1. [47]hasProperty and isPropertyOf remain in SSN new as is
2. [48]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
Received on Tuesday, 4 April 2017 22:07:56 UTC