W3C home > Mailing lists > Public > public-sdw-wg@w3.org > April 2017

[Minutes SSN] 2017 04 04

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>
Message-ID: <547e2dbe-5fce-11ed-5c17-dec429681a5a@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


           ahaller2, ChrisLittle, ClausStadler, DanhLePhuoc,
           Francois, kerry, KJanowic, mlefranc, phila,
           RaulGarciaCastro, SimonCox

           Rob, Scott


           kerry, KJanowic


      * [4]Meeting Minutes
          1. [5]Approving last meeting's minutes https://
          2. [6]Patent Call https://www.w3.org/2015/spatial/wiki/
          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://
          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/

      [15] https://www.w3.org/2017/03/28-sdwssn-minutes

    <mlefranc> +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


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

    <RaulGarciaCastro> [17]https://www.w3.org/2015/spatial/track/

      [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


    <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/


    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 --

    <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://


    <phila> action-295?

    <trackbot> action-295 -- Maxime Lefrançois to And kjanowic to
    propose implementation options for option 2 on the wiki:
    measurement_and_operating_properties_for_actuators -- due
    2017-04-04 -- OPEN


    <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/



    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
    Measurement_and_Operating_properties_for_actuators in ssn


    <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].


    <mlefranc> [28]https://lists.w3.org/Archives/Public/


    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

    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

    <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
    … 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

    ... 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

    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/


    mlefranc: there are some claer options -- a Pr is a bit too

    <KJanowic> Okay, I can do so

    mlefranc: suggest a new page "sensing and actuating" is already

    <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

    <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/

      [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
    … should they be in sosa and ssn or deprecate latogether?

    ahaller2: we did something here ... i thoight we had them
    … 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

    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].


    <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

    <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

    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

    mlefranc: i understand simon's point but it is used , so
    options fr ssn are put in sosa, change text, and I sue them

    <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
    … ssn has "featureofinterest" without the "has"
    … are we making anypro

    <SimonCox> +1 phila - 'hasFeatureOfInterest' rather than

    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

    can we do that when under review? or does it need to be done

    ..we do not have time in next 3 weeks

    ... yes for the doc in ns space, but tr space doc is only in

    ... 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


    <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/

      [39] https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN

    <ahaller2> [40]https://www.w3.org/2015/spatial/track/actions/

      [40] https://www.w3.org/2015/spatial/track/actions/284

    <DanhLePhuoc> +1

    <ahaller2> KJanowic: startTime and endTime was decided to be

    <ahaller2> ... system, latencylifetime etc. are some other time

    <ahaller2> ... samplingTime = phenomenonTime was introduced

    <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 ...


    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

    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

    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


    <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

    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

    SimonCox: we should not leave this up to the data providers and

    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

    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’

    <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

    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/

      [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://
        Measurement_and_Operating_properties_for_actuators in ssn
     2. [44]KJanowic to propose options on Sensing class for SSN
     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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 April 2017 22:07:56 UTC