W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

[Minutes F2F] 2016-09-20

From: Phil Archer <phila@w3.org>
Date: Wed, 21 Sep 2016 08:58:57 +0100
To: SDW WG Public List <public-sdw-wg@w3.org>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
Message-ID: <8bfe0407-70bb-41b6-2137-6d4f4509c9a4@w3.org>
The minutes of day two of our face to face at TPAC 2016 are at 
https://www.w3.org/2016/09/20-sdw-minutes, linked from the agenda and 
pasted below as text for convenience.

Thanks to Andrea for spotting the RRSAgent problem, I was able to create 
a full set of minutes.


           Spatial Data on the Web WG F2F, TPAC 2016 Day 2
20 Sep 2016

Attendees

    Present
           eparsons, AZ, ahaller2, RaulGarciaCastro, AndreaPerego,
           kerry, raphael, Linda, frans, billrobe_, jtandy,
           dmitrybrizhinev, BartvanLeeuwen, jonblower, DanhLePhuoc,
           Maxime, billroberts, Achille, DarkoAnicic, victor,
           chunming, andreic, Sebastian_Kaebisch@Siemens

    Regrets
    Chair
           eparsons

    Scribe
           Linda, billroberts, phila, AndreaPerego

Contents

      * [2]Topics
          1. [3]SSN
          2. [4]SOSA core goals
          3. [5]SSN top-down
          4. [6]What topics are modules built around?
          5. [7]SSN Use Cases & Requirements
          6. [8]https://www.w3.org/2015/spatial/track/issues/78
          7. [9]What topics are modules built around? (for real
             this time)
          8. [10]'RecordOfObservation' vs 'ActivityOfObserving'
          9. [11]Future Face to face meetings
         10. [12]Joint Session with WoT IG
      * [13]Summary of Action Items
      * [14]Summary of Resolutions
      __________________________________________________________

    <eparsons> trackbot, start meeting

    <eparsons> Still waiting for people to arrive - may start in
    about 10 mins est. Time for a coffee ?

    <phila> trackbot start meeting

    <trackbot> Spatial Data on the Web WG F2F, TPAC 2016 Day 2

    <trackbot> Date: 20 September 2016

    <billrobe_> Documents we'll be discussing in the first session:

    <Linda> scribe: Linda

    <billrobe_> [15]http://w3c.github.io/sdw/eo-qb/

      [15] http://w3c.github.io/sdw/eo-qb/

    <billrobe_>
    [16]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
    ages

      [16] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages

    <billrobe_> [17]http://w3c.github.io/sdw/coverage-json/

      [17] http://w3c.github.io/sdw/coverage-json/

    <billrobe_> (sorry my irc client has mangled my username)

    <eparsons> Topic : Approve yeterdays minutes

    <eparsons> PROPOSED : Approve yesterdays minutes

    <eparsons> [18]https://www.w3.org/2016/09/19-sdw-minutes.html

      [18] https://www.w3.org/2016/09/19-sdw-minutes.html

    <jtandy> +1

    <eparsons> +1

    +1

    <billrobe_> +1

    <kerry> +1

    <AndreaPerego> +1

    <eparsons> RESOLUTION : Approve yesterdays minutes

    <raphael> +1

    <ahaller2> +1

    <frans> +1

    <RaulGarciaCastro> +1

    <eparsons> Topic : Coverage (demos and review of ed drafts)

    Bill: will bring everyone up to date of the last few months'
    work
    ... around using datacube for coverage data
    ... an australian team is working on that, Sam will talk about
    it
    ... and in a different strand roba is working on it

    <billrobe_> [19]http://w3c.github.io/sdw/eo-qb/

      [19] http://w3c.github.io/sdw/eo-qb/

    Bill: the doc at this link will become a w3c note

    <billrobe_>
    [20]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
    ages

      [20] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages

    Bill: roba's work is in this wiki page, could become part of
    the first doc
    ... also Jon Blower will join and tell us about CoverageJSON

    <billrobe_> [21]http://w3c.github.io/sdw/coverage-json/

      [21] http://w3c.github.io/sdw/coverage-json/

    Bill: this will also be a W3C note and OGC discussion paper

    <billrobe_> [22]https://covjson.org/

      [22] https://covjson.org/

    Bill: we're not trying to replace existing cov standards but
    targetting new users

    sam: using rdf datacube for coverages
    ... rdf + triple store doesn't work for large coverages
    ... 3 ways of doing this with rdf

    dmitrybrizhinev: been working on an example which is in the
    draft note

    <billrobe_>
    [23]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
    er/ANU-LED.owl

      [23] 
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED.owl

    dmitrybrizhinev: using rdf to say things about your data

    <billrobe_>
    [24]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
    er/ANU-LED-example.owl

      [24] 
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED-example.owl

    dmitrybrizhinev: the example helps you understand how to do it

    <RaulGarciaCastro> The second file should be a .ttl file,
    shouldn’t it?

    <dmitrybrizhinev> yes, they both probably should be

    kerry: suggests a demo showing the work, people here haven't
    seen it

    <sam> [25]https://anu-linked-earth-data.github.io/#/

      [25] https://anu-linked-earth-data.github.io/#/

    (just a moment while we get the beamer working)

    billrobe_: we got the demo on screen now

    sam: its a javascript application
    ... data stored on the server in rdf
    ... you can move through time
    ... backend supports directly querying the rdf

    <jonblower> I don't suppose the screen can be shared through
    Webex? Demo link works but might be easier to follow if we
    could see what Sam's doing

    kerry: it was difficult to understand you so I will rephrase

    <sam> I can try poking around in WebEx to see whether screen
    sharing works.

    <jonblower> Thanks Sam. Actually I could hear you better than I
    can hear Kerry now!

    kerry: data is stored as binary pixels and every tile has an
    url where you can get image details

    <billrobe_>
    [26]https://github.com/ANU-Linked-Earth-Data/ontology/blob/mast
    er/ANU-LED-example.owl

      [26] 
https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED-example.owl

    <sam> Yes, that's the one. Thanks.

    sam: the example makes it clear.

    kerry: the ontology here is describing this dataset
    ... roba is more looking at standardizing the dimensions

    <AndreaPerego> JSON output from one of the queries:
    [27]https://anulinkedearth.org/landsat/query?query=PREFIX+xsd:+
    %3Chttp:%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%3E%0APREFIX+led:
 
https://anulinkedearth.org/landsat/query?query=PREFIX+xsd:+<http://www.w3.org/2001/XMLSchema#>

    +%3Chttp:%2F%2Fwww.example.org%2FANU-LED%23%3E%0APREFIX+geo:+%3
    Chttp:%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0APR
    EFIX+qb:++%3Chttp:%2F%2Fpurl.org%2Flinked-data%2Fcube%23%3ESELE
    CT+%3Fsubject+%3FgeoSparql+%3FtimePeriod+%3Fband+%3Fvalue+%3Fre
    solution+%3Flon+%3Flat+%3FdggsLevelSqua[CUT]

    kerry: the work also has a prov alignment and some ssn
    ... and a bit of owl time

    billrobe_: rob please give us an overview of your work

    <billrobe_>
    [28]https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Cover
    ages

      [28] https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages

    roba: looked at rdf datacube and how to add in dimensions via
    an extension
    ... the work is still in strawman stage

    (showing roba's screen)

    scribe: flattened out dimension hierarchy to make it simpler to
    use
    ... as a single file
    ... communities can define their own dimensions
    ... and register them

    <Zakim> phila, you wanted to ask about validation

    <sam> (some example Turtle from demo before:
    [29]http://pastebin.com/DUrGGiNj)

      [29] http://pastebin.com/DUrGGiNj)

    phila: you have some spin in there to validatie
    ... can I check that my data is valid to your templates?

    <billrobe_> (thanks sam for the example data)

    roba: would be possible to make a validation spin, this is an
    entailment spin

    (shows the UI letting you add a coordinate dimension binding
    using a form)

    phila: are you depending on spin for this to work?

    roba: not particularly, backend could use anything

    billrobe_: Rob is explicitly asking for feedback on this
    ... Sam and Dmitri also welcome feedback
    ... let's move on to coveragejson work

    jonblower: doing this work in the context of Melodies project
    ... aim is to publish scientific data on the web in a way which
    lets web developers use it
    ... coveragejson is the data format we developed for this
    ... not oversimplified compared to eg NetCDF, but with linking
    capabilities etc
    ... specification, tools and libraries. The website the screen
    is showing is the frontend.
    ... also a cookbook, the best starting place.
    ... and a playground
    ... explains the covjson format

    <billrobe_> [30]https://covjson.org/playground/

      [30] https://covjson.org/playground/

    jonblower: several strategies for when the data gets big
    ... (missed the first one)
    ... you can tile the data, split it up in multiple ways

    <maik> (bug with Safari, try in Chrome/Firefox)

    jonblower: tools: js library for reading the format, plugin for
    leaflet, plugin for WIP virtual globe
    ... and others

    <billrobe_> [31]http://w3c.github.io/sdw/coverage-json/

      [31] http://w3c.github.io/sdw/coverage-json/

    jonblower: we have a draft Note we're working on

    includes some thoughts on converting the covjson to RDF

    scribe: using JSON-LD
    ... its limited, parts like domain and range are difficult

    billrobe_: how do you see this in relation to existing OGC
    standards?

    jonblower: its an encoding format, not tied to OGC or others.
    But with mapping between covjson and CIS its possible to use it
    with OGC services
    ... one dif is in covjson we allow multiple CRS.
    ... covjson is similar to datacube and a mapping between them
    would be interesting

    frans: how is metadata handled?

    <frans> How interoperable are the different coverage solutions
    on the metadata level?

    jonblower: you have to decide how deep you want to go with
    metadata. At a minimum define the units of measure and things
    your measuring.
    ... not sure theres a single metadata set that fits everybody.
    Roba's profiles could be interesting.

    <Zakim> jtandy, you wanted to ask about the structure of the
    value arrays

    jtandy: a colleague has been using the spec to test it. He said
    the value range is always a single dimensional array, have you
    tried multidimensional?

    jonblower: decided it would be a bad idea to do this in json.

    <frans> Isn't this a possible solution for the requirement to
    have quality metadata for each value?

    jonblower: with a single dimension array it's always trivial to
    check if it fits, with multi dimensional or nested arrays its
    difficult

    <Zakim> phila, you wanted to ask about relative merits of each
    approach

    phila: we're sort of looking at two things at different stages
    of maturity here: covjson has had more work put in than the ANU
    work
    ... how to decide which approach is better?
    ... is it possible to converge or bridge?

    jonblower: there's no competition in my eyes. We use JSON
    because that's where web developers live.
    ... roba and ANU have nice work on making these things more
    generic and richer

    <frans> Could having the same metadata model allow convergence?

    Kerry: the ANU team came from a different direction.
    ... roba's formalizing dimensions for datacube

    eparsons: we're having connectivity problems

    billrobe_: we should ask ourselves who it's for. That should
    help with choosing.
    ... the spec should spell out what the target audience is for
    each approach

    <eparsons> sorry connectivity problems in Lisbon

    <Zakim> billrobe_, you wanted to ask about linking

    jonblower: not too much choice though, a standard with too much
    choice is too difficult to implement.
    ... profiles would help

    <Zakim> roba, you wanted to discuss RDF QB role

    roba: there is a vocabulary for describing dimensions and
    measures
    ... the way to handle dimensions should be the same in covjson
    and RDF DQ, ie we should work on a mapping

    jonblower: true. The current mapping to RDF is not well
    developed, we should look at it more seriously in this light.
    ... also, interoperability is lossy.

    <phila> issue: alignment between CoverageJSON and EO-QB for
    metadata, etc. What does the @context file for CovJson lead to

    <trackbot> Created ISSUE-79 - Alignment between coveragejson
    and eo-qb for metadata, etc. what does the @context file for
    covjson lead to. Please complete additional details at
    <[32]http://www.w3.org/2015/spatial/track/issues/79/edit>.

      [32] http://www.w3.org/2015/spatial/track/issues/79/edit

    jtandy: in the BP session we were trying to help people choose
    the right format for their data.
    ... covjson could be an example of making the right choices.

    jonblower: will be at metoffice in october, we chould have a
    chat about it

    billroberts: in covjson you can have a collection of coverages
    and there's a tiled approach, with each tile having a URL.
    ... is there a formalism for using fragment identifiers within
    a coverage?
    ... identifying a data point or a slice or dice is useful.

    jonblower: we've talked about extracts/subsets.

    bill roberts: issue 66 on github

    jonblower: are looking at identifiers for extracts, not an API
    for doing this
    ... works in coverage world, maybe not in general world. Not
    sure it will make it into the spec, not really mature.

    bill roberts: it would address the linkability requirement

    kerry: Chris Little has been talking about having named dices

    <Zakim> phila, you wanted to ask about MIME type registration

    kerry: could be considered to do something like this
    ... not native DQ
    ... in ANU solution you can do sparql queries as well so user
    is able to get their own abstract, but this may be an
    unattractive solution.

    <jonblower> Here's the issue on the CovJSON GitHub:
    [33]https://github.com/covjson/specification/issues/66

      [33] https://github.com/covjson/specification/issues/66

    jonblower: like Kerry thinking to have rectangular extracts

    <eparsons> billroberts Working on FPWD

    <eparsons> Kerry - Feedback on template requested

    <eparsons> kerry : Style in particular

    <eparsons> phila_ : No use of "click here" please

    <eparsons> phila_ Link should be name of doc for example

    <eparsons> phila_ Are mime times registered for covJSON ?

    <eparsons> jonblower No but help would be great...

    <eparsons> phila_ w3c process will be shared

    <Werk_> [34]https://www.w3.org/QA/Tips/noClickHere

      [34] https://www.w3.org/QA/Tips/noClickHere

    <jonblower> apologies that I can't return after the coffee
    break, I will be travelling, then

    <jonblower> in meetings

    <eparsons> scribe: billroberts

SSN

    kerry: The SSN ontology was built some time ago through a W3C
    incubator group.
    ... the objective of the SDW group in its charter is to deliver
    the SSN ontology as a standard
    ... and to modularise it to make it simpler to use
    ... This is on the REC track so we need at least two
    implementations of every term in the ontology

    <AZ> I don't hear anything, can someone in Lisbon connect to
    the webex

    kerry: and that has to be complete 7 months from now
    ... We'll do that using a survey, to ask people if/how they are
    using each term

    (Ed is trying to reconnect the webex)

    scribe: Also we have agreed that any variants will be backward
    compatible to previous uses of SSN
    ... Other things in the landscape - there is a lot of demand
    and fast moving implementations in the Internet of Things area
    ... many people are using SSN, but there is criticism about the
    size and complexity, so the modularisation should address that
    issue
    ... Later today, the Web of Things working group is joining us
    for 2 hours.
    ... In summary, I think we are going too slowly, and perhaps
    concentrating on the wrong things.

SOSA core goals

    kerry: We decided early on to remove DOLCE from the ontology as
    it is a major challenge for usability
    ... there is a proposal for a core of SOSA. Armin will
    introduce

    <ahaller2> [35]http://w3c.github.io/sdw/ssn/#Modularisation

      [35] http://w3c.github.io/sdw/ssn/#Modularisation

    ahaller2: We propose a vertical modularisation. The details of
    naming in the SSN document are a little out of date but don't
    worry about that
    ... the outer layers in the diagram at the above link are
    importing a lightweight core
    ... So it could be reused easily in other things, eg schema.org
    or Web of Things
    ... SSN module will import the core as an ontology and extend
    it with concepts around sensor networks

    <ahaller2>
    [36]https://www.w3.org/2015/spatial/wiki/SOSA_Ontology

      [36] https://www.w3.org/2015/spatial/wiki/SOSA_Ontology

    ahaller2: work so far is currently on the wiki
    ... listing classes and properties that are included in the
    core
    ... It's a dumbed-down version of SSN with one or two extra
    things
    ... These classes already exist in SSN, so SSN can import this
    core with conflict to the semantics of SSN
    ... There are no axioms in the core, to keep it lightweight
    ... the wiki page is the consensus of the working group members
    that have been closely involved

    DanhLePhuoc: we'll need alignment or cross-linking from the new
    namespace to the old namespace to support people who made
    queries etc that used the old namespace

    ahaller2: that alignment can be done in the higher level
    ontologies such as SSN

    DanhLePhuoc: to support adoption we should do that alignment
    and support existing users

    ahaller2: the main part of SSN will be untouched, so that
    should cover people using the old namespace. They can
    transition to the new namespace if they want but they don't
    have to

    kerry: we should have everything in one namespace and it should
    be the new SSN namespace

    RaulGarciaCastro: the SSN ontology is the de facto standard. We
    take the risk of creating a new competing standard.
    ... (and by the way 'SOSA' in Spanish means dull or boring!)
    ... there have been decisions on conceptualisation,
    implementation, modularisation. It would be easier to discuss
    if it could be divided up a bit

    kerry: agrees with Raul's point
    ... there are a lot of changes, potentially confusing ones
    ... we should start with SSN, pull it apart, then look
    individually at the various extensions
    ... It's not an option to use the old namespace. Best option
    would be to convert all terms to the same new namespace
    ... Separating out the core to a different namespace could be
    confusing

    ahaller2: the namespace is not really important. SSN namespace
    has to change and there will be a link back to the old one
    ... the editors have proposed a core which is as simple and
    reusable as possible.
    ... we can discuss the choice of specific terms according to
    feedback
    ... but I don't think we need to go back to the start. Just to
    discuss questions about the choice of individual terms

    <Zakim> raphael, you wanted to remind what's happen with the
    vcard namespace mess

    raphael: regarding the two namespaces for SSN, something
    similar happened in the past with Vcard. There were 2
    namespaces and it caused confusion for years as no-one knew
    which to use

    phila: W3 process does not prevent use of purl.org as a
    namespace, but there are technical issues around use of purl,
    which looks like it is not going to be maintained
    ... purl redirects to a W3 URL. We could perhaps set up a
    redirect from that to some new place

    Maxime: I am working in a European project with a large
    versioned vocabulary. We had one namespace that linked to
    multiple documents, each defining a set of concepts
    ... so there is no technical issue in having one namespace and
    separate modules in separate files

    ahaller2: the namespace choices were not really technical but
    because of the concepts addressed in the core, which are not
    really SSN realted

    <Zakim> jtandy, you wanted to note that the sosa-core seems
    like it's simple enough to pick up and use even if you're not
    deep into RDF/OWL - which I like ...

    jtandy: I like the work on the core - it's simple for
    developers to use without having to worry about the axioms/Owl
    aspects.

    <DanhLePhuoc> +q

    <Zakim> phila, you wanted to talk about cores and timing

    phila: do you have a stable core that you are happy with and
    that is widely used? Are the non-core aspects less stable or
    less used?

    kerry: no, the other way round. The 'extensions' are stable and
    used. The core is new so not yet used

    phila: reminder that we only have 9 months left. This is on REC
    track so needs implementations and that takes time. You'll need
    to enter candidate-REC by Feb or March latest. So with
    holidays, that's only 2.5 working months left
    ... so needs decisions soon. Best to focus on what is known to
    be used and needed for the REC
    ... you've done a lot of work. Publish it soon

    DanhLePhuoc: returning to the bridge to the old ontology, doing
    the alignment work is important for driving use
    ... we need to demonstrate that it is really backward
    compatible, or we'll end up with another different standard

    ahaller2: the new SSN plus an import of the unchanged DULCE
    extension will be the same as the old stuff

    DanhLePhuoc: I have a lot of sensors and data using the old
    vocab.
    ... querying a mix of old and new will lead to very messy
    queries

    RaulGarciaCastro: best thing would be new ontology and
    mappings. But in terms of timing, that is two new deliverables.
    Is that feasible?

    ahaller2: so Danh's proposal is having two ontologies both with
    links back to old terms. Plus a Best Practice document
    explaining how to use
    ... for modularisation, should they go in new sub-sections of
    the namespace?

    DanhLePhuoc: even changing of labels may cause backward
    compatibility issues

    ahaller2: the description has to change because the semantics
    has changed - but it is in a new namespace, so it's a different
    term

    DanhLePhuoc: lots of developers do text search and regular
    expressions to find data - they might not use URIs

    ahaller: the label in SSN doesn't change. Just the core

    DanhLePhuoc: but confusing for people if there are two very
    similar but distinct terms

    kerry: if you are using a lightweight part of SSN, you probably
    want it to be compatible with the rest of SSN, otherwise you
    wouldn't use SSN
    ... are people going to understand what is intended by a term?
    if they are doing lightweight work, they will probably not do
    any reasoning, just want a properly defined term to use

    DanhLePhuoc: different levels of semantic info: RDFS, OWL,
    semantic rules. Depends on the capability of your processor

    Maxime: methodology to modularise: this should be led by some
    requirements. Modules could define alignment to old ontology.
    Another could define alignment to DUL
    ... could be a module to talk about actuators for example.
    Should that be aligned to the old ontology?
    ... comments and labels found in the new namespace might be
    different to the old ones
    ... at lower levels there could be simpler descriptions of
    terms
    ... technically I'm not sure we need a new namespace

    <ahaller2> [37]http://purl.oclc.org/NET/ssnx/ssn#Property

      [37] http://purl.oclc.org/NET/ssnx/ssn#Property

    ahaller2: I agree with you about labels. We need to change
    labels because the old ones referenced DULCE and we're taking
    that out.

    kerry: also there are lots of spelling mistakes that need fixed

    ahaller2: we haven't yet decided on specific namespaces, only
    that they will be 'slash' namespaces. Maxime's suggestion on
    implementation sounds good
    ... we have changed descriptions of the terms in the core
    because they have much more lightweight semantics
    ... and we have to remove references to other terms that will
    not be in the core

    BartvanLeeuwen: should we record the things in the minutes
    where we have consensus? Lots of discussions but we're not
    recording the conclusions

    <Maxime> Requirement: have a core module that is very
    lightweight

    <Maxime> Requirement: have other modules that are alignemnts to
    the old version of SSN.

    <Maxime> Requirement: have a module that describe actuators

    <Maxime> Requirement: when accessing the new namespace, one
    needs to access an ontology that is logically equivalent to the
    old ontology, with

    <Maxime> the alignement to DUL, and that allows to lead the
    same entailments.

    <Maxime> Constraint: the descrition of concepts in the
    different modules (for instance with/without DUL) cannot be the
    same (they will not have the same semantics)

    BartvanLeeuwen: are we already talking to IoT people?

    kerry: yes

    raphael: can we have a simple table that lists the old terms
    and what we are doing with each term (eg moving to core, etc)

    RaulGarciaCastro: I tried to do that but it was too difficult

    raphael: if we can't do that, it is indicating a problem

    phila: re spelling mistakes needing correction. We can't change
    purl.org but we can change the thing it points to

    kerry: plan to leave old stuff as is, and make a new better one

    phila: we can probably make things work if it's worth doing

SSN top-down

    kerry: early on we pulled out DULCE from the ontology. Several
    people didn't like the previous modularisation
    ... first attempt wasn't right
    ... a few weeks ago I went back to the original SSN and pulled
    out DULCE.
    ... it changes DULCE to the new namespace for DOLCE which has
    changed in the mean time
    ... uses the new W3 namespace
    ... From a process point of view, I'd like to start there for
    modularisation
    ... then we can be very explicit about tracking changes and
    documenting reasons for changes
    ... given delivery dates, I'd like to prioritise that before
    making any deeper changes
    ... I think that's the only strategy that will allow us to know
    what we're doing and be able to discuss changes one at a time
    ... let's decide as a group what the modules need to be and
    look for volunteers to work on each one
    ... the modularisation is the most important thing

    frans: are you planning to record provenance of terms?

    <Zakim> phila, you wanted to ask an awkward question

    kerry: old ontology is very good at describing provenance

    (AZ - many thanks for the correction and explanation! I think I
    was getting confused about those two things)

    DanhLePhuoc volunteers to document alignment of new ontology
    with existing ontologies including PROV-O and Time

    scribe: and coverage

    <Maxime> can anyone add me as a collaborator on the github
    project ? maximelefrancois86

    Maxime: will help on this

    kerry: we need to agree what the content of the modules will be

    Maxime: we can follow Raul's suggestion of going through the
    terms one by one and deciding for each

    ahaller2: agree we need to decide what modules
    ... shouldn't have too many different modules. A lot could be
    in main SSN

    eparsons: regarding new modules and that you are on the REC
    track so need implementations, can you prioritise those parts
    that are most likely to be adopted quickly?

    kerry: we're talking about terms that are already in use, we're
    just moving them around

    eparsons: do you have to prove that people are using your new
    modularisation? (rather than the old stuff)

    kerry: don't think so

    <DanhLePhuoc> +q

    <eparsons> ack ack next

    kerry: we need the modules first, then the extensions
    ... implementation of extensions is more significant

    phila: the things you can get implemented are the bits that go
    in the REC track document. You can separate out
    not-yet-implemented aspects into a Note or other document

    DanhLePhuoc: the previous version was not formally
    standardised. Need evidence of implementation of the old terms

    phila: would be neater to have separate documents rather than
    one document with non-normative sections
    ... (for implemented and not-yet-implemented parts)

    <raphael> The alternative approach presented by Kerry is at
    [38]https://github.com/w3c/sdw/tree/gh-pages/ssn/ssn_separated

      [38] https://github.com/w3c/sdw/tree/gh-pages/ssn/ssn_separated

    kerry: there are few things in there that need urgent
    attention.
    ... and there are some errors in SSN that should be corrected

    eparsons: go ahead and fix those errors

    general approval from the meeting that kerry should fix the
    errors she listed

    <raphael> Details are: delete the explicit statements that says
    that a concept is a subClassOf owl:Thing (e.g.
    FeatureOfInterest)

    <raphael> In the DOLCE alignments, PhysicalObject need to be
    changed to Objects

    <eparsons> +1

    <raphael> +1

    <DanhLePhuoc> =1

    <RaulGarciaCastro> +1

    <jtandy> +0 ... not sure of implications

    <DanhLePhuoc> +1

    <AZ> +1

    <phila> +1

    <BartvanLeeuwen> +1

    <Maxime> prcision: In the DOLCE alignments, sensor subclassOf
    PhysicalObject need to be changed to sensor subclassOf Object

    time for lunch. Restart at 1.30 local time

    <eparsons> Returning from Lunch - Dialling webex now !

    <phila> scribe: phila

    <scribe> scribeNick: phila

What topics are modules built around?

    kerry: Maybe now is a good time to do the use cases discussion

SSN Use Cases & Requirements

    <frans> [39]https://www.w3.org/2015/spatial/track/products/1

      [39] https://www.w3.org/2015/spatial/track/products/1

    frans: Yesterday we talked about the UCR with 6 open issues
    ... 2 remaining issues open

    issue-77?

    <trackbot> issue-77 -- New SSN requirement: programming/tasking
    and actuation -- open

    <trackbot> [40]http://www.w3.org/2015/spatial/track/issues/77

      [40] http://www.w3.org/2015/spatial/track/issues/77

    issue-78?

    <trackbot> issue-78 -- New SSN requirement: SSN usage examples?
    -- open

    <trackbot> [41]http://www.w3.org/2015/spatial/track/issues/78

      [41] http://www.w3.org/2015/spatial/track/issues/78

    frans: These two seem not have been recorded for the new SSN
    ... Issue-77. I'm not in touch with the details...

    phila: How can you use a vocab to program and actuation

    kerry: Concept is to model the capabilities and control of a
    sensing device
    ... It's an old SSN req that wasn't implemented but it's back
    through WoT

    <DanhLePhuoc> +q

    kerry: I think it needs to be there

    DanhLePhuoc: I roughly understand. But task/programming is
    confusing.
    ... I think this is modelling

    kerry: Tasking is on OGC word. An implementation might be,
    here's an interface where you can attach code

    frans: Is the programming only related to actuation?

    DanhLePhuoc: You can change the rate of acquisition, etc.
    ... Some sensors have features you can... send some
    parameters... that's what people need
    ... There may be serial tasks, sequences of tasks. I think
    there was a task ontology some years ago.

    frans: So are tasking and programming different things?

    DanhLePhuoc: Tasking is more like sequencing

    BartvanLeeuwen: DO we have enough knowledge and time to do
    this?

    kerry: It's trivial to do what's proposed in SOSA core. Whether
    it's useful...
    ... There are certainly examples of this being done
    ... It's not hard, but we don't have an implementation

    eparsons: So this is not currently in SSN

    kerry: It was in the old requirements but never implemented

    eparsons: So you'd have to come up with a way of meeting this
    requirements, then you have to prove implementation within the
    time we have.

    kerry: Were not going to meet all the requirements, in realit.
    ... I think it's easy to do a simple solution.
    ... I think Danh will do an implementation.
    ... and WoT can do one I think
    ... I suspect this is a high priority from the SSN Group

    ahaller2: Maybe you can make it more specific
    ... There could be a simple on/off property

    frans: So this requirement will only focus on actuation.

    kerry: That's fine

    <DanhLePhuoc> proposal the description for Issue #77: A new
    requirement for SSN is proposed: It should be possible to model
    actuation functions of sensing devices.

    <ahaller2> +1

    <eparsons> +1

    <DanhLePhuoc> +1

    <jtandy> +1

    <frans> +1

    <Linda> +1

    <BartvanLeeuwen> +1

    PROPOSED: the description for Issue #77: A new requirement for
    SSN is proposed: It should be possible to model actuation
    functions of sensing devices

    <BartvanLeeuwen> +1

    RESOLUTION: the description for Issue #77: A new requirement
    for SSN is proposed: It should be possible to model actuation
    functions of sensing devices

    ISSUE-78

    <trackbot> ISSUE-78 -- New SSN requirement: SSN usage examples?
    -- open

    <trackbot> [42]http://www.w3.org/2015/spatial/track/issues/78

      [42] http://www.w3.org/2015/spatial/track/issues/78

[43]https://www.w3.org/2015/spatial/track/issues/78

      [43] https://www.w3.org/2015/spatial/track/issues/78

    <DanhLePhuoc> +1

    <RaulGarciaCastro> +1

    <ahaller2> +1

    <frans> proposal: add ssn req: There should be examples of how
    the SSN ontology can be used together with other vocabularies.

    <RaulGarciaCastro> +1

    <Maxime> +1

    <BartvanLeeuwen> +1

    <frans> +1

    RESOLUTION: add ssn req: There should be examples of how the
    SSN ontology can be used together with other vocabularies.

    <kerry> +1

    <scribe> ACTION: frans to act on resolution of issues 77 and 78
    [recorded in
    [44]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]

      [44] http://www.w3.org/2016/09/20-sdw-minutes.html#action01]

    <trackbot> Created ACTION-200 - Act on resolution of issues 77
    and 78 [on Frans Knibbe - due 2016-09-27].

    close issue-77

    <trackbot> Closed issue-77.

    close issue-78

    <trackbot> Closed issue-78.

    phila: Asks about timing of future UCR publication

    frans: Couple of weeks or so

    eparsons: It's going to be the final draft, at least that's the
    intention

What topics are modules built around? (for real this time)

    <ahaller2>
    [45]https://www.w3.org/2005/Incubator/ssn/wiki/Report_Work_on_t
    he_SSN_ontology

      [45] 
https://www.w3.org/2005/Incubator/ssn/wiki/Report_Work_on_the_SSN_ontology

    kerry: What actually is a module, what goes into one
    ... We think we have a core and then outside that is
    topic-specific modules and I want to get an understanding of
    what those modules are
    ... Modules that are too big can be a problem
    ... The famous image is a modularisation that doesn't really
    exist
    ... For me it's obvious that the deployment on the top left is
    a module, some people care, others don't.
    ... On the right... some survival range and operating range
    ... There's the datasheet that says how a sensor will perform
    in different environments.
    ... That area might be able to be hived off

    maxime: Feature of interest and property can be used alone.

    kerry: That's tiny

    Maxime: Yes

    [discussion of 'property']

    phila: Probes into what modules are, why not just use what's
    there? What effect will users see if you drew the boxes
    differently?

    [Bit of discussion]

    <DanhLePhuoc> +q

    phila: You can have multple docs defining terms in a single
    namespace (IMHO)

    Maxime: I think there's more in modularisation that drawing
    boxes. If you take out DUL, you remove axioms like feature and
    @@ aree disjoint
    ... You have an object of interest that's a fridge, and then
    you want to talk about the frequency of the voltage. It is a
    property of the fridge?

    kerry: I'd be happy, not sure of OGC folks would be.

    Maxime: It's not the properties, it's the axioms

    <RaulGarciaCastro>
    [46]https://www.w3.org/2015/spatial/wiki/SSN_conceptual_modules
    #Overview_of_the_conceptual_modules

      [46] 
https://www.w3.org/2015/spatial/wiki/SSN_conceptual_modules#Overview_of_the_conceptual_modules

    RaulGarciaCastro: Describes his diagram

    <Maxime> +1

    <DanhLePhuoc> -q

    <DanhLePhuoc> +q

    RaulGarciaCastro: Maybe we go through the use cases and see
    which modules are needed.

    <Zakim> jtandy, you wanted to ask what the downsides of not
    modularising are?

    jtandy: What prob;em occurs if we don't modularise. I know we
    want core, O&M, etc as axioms in other modules might conflict.
    I'd modularise of the governance or maintenance sections for
    example are going to be different.
    ... but breaking it up into chunks makes sense for explanation
    and usage, but I don't know the pros and cons
    ... If we don't split it, what do we lose.

    Maxime: If we don't split, when do we know it was right.

    jtandy: If an implementation only uses part of that, and
    references classes they don't use, is there an extra burden?

    <ahaller2> +1 great summary jtandy

    jtandy: Simplicity wins. We're talking about cutting it up into
    smaller pieces - why?

    DanhLePhuoc: We only have 20 classes
    ... So we don't need to ask people to import several things,
    but I think there's a separation in usage.
    ... If I just want to use 3, I don't see why I need to import
    the other 17

    kerry: So if I'm hearing this right, it would all be in the
    same file, but outside that, we'd expect DULCE alignment, @@
    alignment, UoM etc.

    RaulGarciaCastro: We can take the decision about what is core.

    kerry: There is one core.

    jtandy: This morning we talked about SOSA core that doers't
    have axioms beyond the simple.
    ... That's the first level of the Sem Web stack
    ... In the editors draft there's that target diagram

    <ahaller2> [47]http://w3c.github.io/sdw/ssn/#Modularisation

      [47] http://w3c.github.io/sdw/ssn/#Modularisation

    jtandy: Is this diagram we're looking at
    ... I think some of the boxes in the complex diagram we see
    exist in the blue box, pink box etc.
    ... It seems that SOSA core seems to have the simple stuff I'd
    need.
    ... Looking at the other diagram and deciding what's in the
    core...

    kerry: Modulo the details...

    frans: It seems that modularisation makes the diagrams smaller
    ... Perhaps it's possible to modularise the explanations
    without modularirising the ontology.

    kerry: Do we have a decision?

    <RaulGarciaCastro> We will have a core module that contains a
    subset of the concepts in the current SSN ontology; we don’t
    plan to split the current SSN ontology into different files;
    and potentially we will have modules that extend the ontology
    (e.g., O&M)

    <RaulGarciaCastro> The modules that extend the ontology will be
    in different files

    Points of agreement

    - There will be a core module that is a subset of SSN

    <Maxime> my understanding: core, ssn, extra, alignment X,
    alignemnt Y, ...

    - There will be an extension file

    - there will be room to add more modules, such as O&M

    <jtandy> so ... the Sensor Network Module imports the SOSA-Core
    module? yes?

    <Maxime> my updated understanding: core, ssn, alignment O&M,
    alignemnt DUL, ... where alignements are the "extra" parts and
    in the non normative parts of the doc

    <Zakim> jtandy, you wanted to point out that we previously
    talked about a SSN Primer as a NOTE ...

    phila: AIUI - you want a 'normative' section that defines the
    well implemented 'core' properties. Then there is a section on
    extensions, with examples. These will not be part of the formal
    standard but will introduce terms to the single namespace
    ... AIUI - you want a 'normative' section that defines the well
    implemented 'core' properties. Then there is a section on
    extensions, with examples. These will not be part of the formal
    standard but will introduce new terms

'RecordOfObservation' vs 'ActivityOfObserving'

    kerry: We discussed this a little in the last SSN meeting.

    <ahaller2>
    [48]https://www.researchgate.net/publication/305809446_Pitfalls
    _in_alignment_of_observation_models_resolved_using_PROV_as_an_u
    pper_ontology

      [48] 
https://www.researchgate.net/publication/305809446_Pitfalls_in_alignment_of_observation_models_resolved_using_PROV_as_an_upper_ontology

    kerry: This potentially a big change being proposed for SSN
    ... The key point of the concept of an observation in SSN is
    deliberately different from O&M concept. That difference is
    either serious or irrelevant...
    ... The difference is how an observation in interpreted wrt the
    act of observing
    ... SSN took the view that it was a record, not an action
    ... For many purposes it doesn't matter
    ... After SSN, Simon created O&M Light. He took an observation
    as an event.
    ... It becomes an issue when SSN gets aligned with DOLCE
    ... We're taking DOLCE out so that's not a problem

    <jtandy> when looking to align O&M and SSN with PROV-O ...
    Simon says: "PROV-O provides just three base classes: Entity,
    Activity and Agent. om:Observation is sub-classed from
    prov:Activity, while ssn:Observation is sub-classed from
    prov:Entity."

    Kerry: But if you align with, say, PROV....
    ... Prov of data and other systems, you get access to the SSN
    info as part of that provenance chain.
    ... This makes the observation an entity

    Kerry; In DOLCE they're disjoint

    scribe: In PROV an activity can be an entity
    ... But the O&M observation it matters
    ... independently, Simon did an alignment with PROV.
    ... When we did it, we introduced an 'Activity of Sensing'
    ... That can be associated with the O&M observation
    ... It gets ugly

    [Kerry moves to the whiteboard]

    -> [49]http://ceur-ws.org/Vol-1401/paper-05.pdf Sensor Data
    Provenance: SSNO and PROV-O

      [49] http://ceur-ws.org/Vol-1401/paper-05.pdf

    Together at Last

    kerry: SSN has an observation as a sub class of entity, O&M has
    it as a sub class of activity
    ... The jump between the two you need mappings and rules -
    which gets ugly.

    eparsons: What if you give up on aligning them?

    kerry: I can do better than that.
    ... Simon made a proposal to just say they're the same but I
    don't think that works.
    ... I want to take advantage of entity and activity not being
    disjoint

    <Zakim> jtandy, you wanted to give my opinion when keery has
    done the intro

    kerry: We can just say that O&M and SSN Observation are the
    same thing. That's OK in Prov. Ontologically suspect but
    practical

    <jtandy> I think ... For me, it seems natural to treat
    Observation as an Activity ... it's something that's done at a
    particular time using a specified process. It produces a some
    data (the result) ... the data, an information resource, is an
    Entity. SSN seems unnecessarily complex in splitting the
    problem into SensorOutput, Observation and ActivityOfSensing;
    OM does this in two classes: Result and Observation.

    [Scribe realises I must have misunderstood what Simon said]

    kerry: ActivityOfSensing doesn't exist in SSN
    ... It was proposed as a way of doing the alignment but it
    seems overly complicated.
    ... I'd be happy with saying don't bother but I don't think
    others would be.
    ... We need to take account of other people's opinions

    eparsons: If it's documented what you mean...

    kerry: it is

    eparsons: Users can deal with the issue of they're made aware
    of it. Should we have to solve it?

    danbri: Is there lots of O&M data?

    jtandy: Yes, It has a lot of data in OGC and ISO
    ... Simon has proposed an RDF representation

    ahaller2: I think there's a lot of reason to align the modules
    ... How we do it, I'm agnostic
    ... We have to change the DOLCE alignment anyway

    kerry: No, I don't see a reason for doing that.
    ... In Prov, it's OK to be an activity and an entity

    ahaller2: But not DOLCE

    kerry: No.
    ... I think there is an event class in DOLCE
    ... DOLCE requires them to be disjoint, Prov doesn't

    <Maxime> so SSN+DUL will be incompatible with SSN+O&M, and
    that's it ? if these are two different extensions, that's maybe
    no big deal

    [Discusses changing SSN to match O&M]

    jtandy: Would you be upset if SSN Observation were a sub class
    of prov:Activity

    kerry: No, but why

    jtandy: In O&M the definition begins with it as an event

    Maxime: I care about the result of this discussion...

    <Zakim> danbri, you wanted to ask about nature of SSN
    deployments (e.g. is it in hardware production etc?)

    danbri: SSN deployment - sounds as if O&M is well deployed.
    ... What's the installed base for SSN?

    Kerry: It's not a standard itself.

    DanhLePhuoc: There a sensor manufacturers using it, with
    JSON-LD

    danbri: Are there major stakeholders you could consult?

    DanhLePhuoc: I know Siemens are doing this. I know one M2M

    danbri: Would it make sense to identify the top users and go
    and ask them?

    DanhLePhuoc: There's a plugfest with Fujistu tomorrow
    ... I think I can collect some usage infoi

    eparsons: I think you say we have two choices...

    jtandy: I suggest "we're thinking of doing this, would it
    disturb you?"
    ... I think we propose tentatively to convert ssn:Observation
    to a sub class of prov:Activity, and ask at least 3 people.
    ... Question is, would this change cause massive problems?

    kerry: And the other option is, do nothing?

    DanhLePhuoc: I prefer that way.

    kerry: The do nothing approach is to say that O&M and SSN
    Observation are the same thing but if you use Prov then you
    need to recognise that it's both Activity and Entity

    PROPOSED: To either (1) align with O&M (Observation is
    activity) or (2) say O&M and SSN Observation are the same thing

    <danbri> is the suggestion that (SSN) Observation be refined to
    treat it as a kind of action/event/activity, bringing it closer
    to O&M's notion of Observation (and e.g. also prov Activity)?

    PROPOSED: To either (1) align with O&M (Observation is
    activity) or (2) say O&M and SSN Observation are the same thing
    but leave described as they are in their own spaces

    ahaller2: DOLCE has an event, it can't be an entity

    <jtandy> SOSA Core currently says ...

    <jtandy> sosa-core:Observation

    <jtandy> rdf:type owl:Class ;

    <jtandy> rdfs:comment "Activity of carrying out an
    (observation) Procedure to estimate or calculate a value of a
    Property of a FeatureOfInterest. Links to a Platform or Sensor
    to describe what made the Observation and how; links to an
    ObservableProperty to describe what the result is an estimate
    of, and to a FeatureOfInterest to detail what that property was
    associated with; the Result is the output."@en ;

    <jtandy> rdfs:comment "An Observation carries out an
    (observation) Procedure to estimate or calculate a value of a
    Property of a FeatureOfInterest. Links to a Platform or Sensor
    to describe what made the Observation and how; links to an
    ObservableProperty to describe what the result is an estimate
    of, and to a FeatureOfInterest to detail what that property was
    associated with; the Result is the output."@en ;

    <jtandy> rdfs:label "Observation"@en ;

    <jtandy> .

    [More discussion]

    kerry: There would be an impact on DOLCE alignment.

    <danbri> ("entity" here meaning dolce's notion of entity,
    rather than something broader approximating 'thing'?)

    PROPOSED: To either (1) align with O&M (Observation is
    activity) or (2) say O&M and SSN Observation are the same thing
    but leave described as they are in their own spaces

    <Maxime> 1

    <jtandy> vote : (1)

    <danbri> 1

    <Linda> 1

    <ahaller2> 1

    <DanhLePhuoc> 1

    <RaulGarciaCastro> 1

    <jtandy> (on behalf of Kerry = 2)

    <eparsons> 1

    RESOLUTION: The ssn:Observation will be redefined as an
    activity, in line with O&M Observation

    jtandy: Consequently, there will need to be work to realign
    with DOLCE

    <danbri> (do we still get this sanity-checked with top 3 SSN
    stakeholders?)

    <scribe> ACTION: kerry to redefine ssn:Observation and update
    alignment with DOLCE [recorded in
    [50]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]

      [50] http://www.w3.org/2016/09/20-sdw-minutes.html#action02]

    <trackbot> Created ACTION-201 - Redefine ssn:observation and
    update alignment with dolce [on Kerry Taylor - due 2016-09-27].

    jtandy: We've just made a decision. We should make sure that
    our vocab is reviewed by current users, incl, say, Siemens.

Future Face to face meetings

    Discussion around WWW 2017, 3-7 April

    <AZ> audio is gone

    <ahaller2> trying to get you back

    Meeting in December, London 12-13 December. Prob then in March
    21-22 in Delft, TBC

    [Coffee Break]

    <eparsons> Back at 16:00

    <eparsons> Thanks AZ see you so

    <eparsons> NP :-)

    <AZ> enjoy Lisbon

    <Kerry> Introductions..

    <Kerry> Chair:Kerry

    <AndreaPerego> scribe: AndreaPerego

    <scribe> scribeNick: AndreaPerego

    <phila> scribeNick: AndreaPerego

    kerry: We need to discuss about decisions that may have
    implications for both groups.

    DarkoAnicic: I can give a short introduction on the work done
    so far.

Joint Session with WoT IG

    <Kerry> Topic : web of things update

    DarkoAnicic: f2f meeting will be thu - fri. You're welcome to
    join.
    ... each f2f will have also a practical session to show what we
    are doing.
    ... IoT means different devices, and how to connect such
    devices.
    ... we are working also on enabling interoperability at the
    application layer.
    ... today we have a number of standards bodies working on
    different standards and platforms.
    ... our goal is to build a set of building blocks so that such
    standards and platforms are able to use them and be
    interoperable.
    ... in other words, we want to bridge these standards and
    platforms.
    ... (responding to kerry) we don't want to provide different
    solutions for each of these standards / tools, but to set up
    re-usable and sharable building blocks.
    ... (describing the building blocks) building blocks include:
    application script layer (interoperability of scripts across
    devices), resource model (abstraction of properties and actions
    for devices), protocol bindings.
    ... Notion of "thing description" plays a central role in the
    framework.

    <DarkoAnicic> TD current practices:
    [51]http://w3c.github.io/wot/current-practices/wot-practices.ht
    ml#thing-description

      [51] http://w3c.github.io/wot/current-practices/

    DarkoAnicic: Why we need it? This is needed to know what kind
    of data you serve, who you are, how you can access
    data/function, what kind of functions are available, protocols,
    encodings, which are the security constraints (if any).
    ... The thing description describes the resource model, the
    protocol bindings, and the WoT servient (client/server role).
    ... This allows also to avoid all the work around embedded
    programming.
    ... Thing descriptions include descriptive metadata,
    security-related info (e.g., security token), supported
    protocols and data formats.
    ... Thing descriptions are provided in JSON-LD.
    ... The JSON-LD context mechanism allows to provide also
    contextual information that is important for operating the
    device.
    ... Also JSON binary formats exist.
    ... (describing JSON-LD snippet).

    victor: About the ontology, this includes two different
    contexts, one defined by [missed it] and one that can be used
    in order to define your own context.

    frans: Do you have predefined contexts people can use?

    victor: Yes.

    DarkoAnicic: Information like UoM can be imported from other
    contexts as well.

    frans: Have you also location information?

    DarkoAnicic: Not really, but you can extend it with location
    information, by reusing an existing vocabulary.
    ... One part of the work is devoted to discovery.
    ... In the future we'll have events where you can bring your
    own vocabulary (e.g., location), and we'll play with them
    (e.g., to find devices in a given location).

    Kerry: Are you then agnostic wrt the vocabularies used?

    DarkoAnicic: Yes, we have a vocabulary that needs to be used
    for making things work, but then you can add other
    vocabularies.

    Maxime: Are in this way limiting the extensibility of the thing
    description?
    ... I have some concerns about the fact that the thing
    description denotes both the representation and the
    presentation of the "thing".

    <ahaller2> +1 to maxime's concern

    DarkoAnicic: A component of the architecture includes a thing
    description repository, meant to register and discover things
    descriptions (TDs).
    ... You can extend TDs with other semantic models.
    ... This can be done for infos concerning application models,
    domain-dependent models, domain-independent models.

    Maxime: About UoM there are different vocabularies that may be
    incompatible. How you solve these possible conflicts?

    DarkoAnicic: We don't have a solution - this is a normal
    problem with standards.
    ... So, it's out of scope of our WG.

    danbri: What about specific domains (e.g., agriculture)? Can
    you deal with them?

    DarkoAnicic: No, this is not in the WG scope - we don't define
    domain-specific properties. We focus on the TD, that is
    domain-independent.

    sebastian: The TD is like the index.html page of a Web site.
    It's an entry point to know what the device can provide.

    Kerry: Is there any protocol to negotiate the change of
    context?
    ... How you can find out who can speak that language?

    <danbri> (agriculture for example,
    [52]http://agroportal.lirmm.fr/
    [53]http://www.agrisemantics.org/ … are very relevant to WoT
    apps but are not presented as IoT/WoT initiatives; it is good
    that that Thing Description architecture seems open-ended for
    such things to be included.

      [52] http://agroportal.lirmm.fr/
      [53] http://www.agrisemantics.org/

    <danbri> )

    DarkoAnicic: You can, e.g., import SSN, then the other thing
    discover yours, and then it has to fetch the context to know
    about SSN.
    ... The discovery can be done also on the additional
    vocabularies that have been used.

    victor: There's a proposal for an WoT ontology based on DUL.
    ... there's an alignment problem that should be solved by SSN
    [missed which is that]

    Kerry: We can standardise the WoT ontology in the work on SSN.

    <DanhLePhuoc_> +q

    <Kerry> Wot should be standalone

    Kerry: Do you consider alignments to be your task, or rather
    this should be done by other communities?

    victor: The idea is this should be done by communities using
    these "things".

    Kerry: This may be an opportunity to optimise the alignments
    planned in SSN.

    <DanhLePhuoc_> +q

    RaulGarciaCastro: SSN is not covering the digital
    representation of the "thing" (i.e., the TD).

    <Maxime> major difference: ssn:Device is a physical thing,
    whereas wot2:Thing would be its digital mirror

    DarkoAnicic: We can also use alignments in schema.org.

    <sebastian> we consider both, a wot2:Thing can be physical or
    virtual

    danbri: The problem is that this is covering too many domains.

    DanhLePhuoc_: (showing a discovery example)

    victor: This shows the use of one of the discovery APIs - in
    this case a SPARQL endpoint.

    <danbri> …. it passes in a basic sparql-based pattern (as an
    example at least)

    <Kerry> +

    ahaller2: Coming back to SSN, we may need to link back to your
    TD, or vice versa.

    DarkoAnicic: Yes, and you can use also a generic property ("has
    description").

    sebastian: Which can be the scenario for this?

    ahaller2: To show which is the origin of the observations.

    <DanhLePhuoc_> +q

    ahaller2: And maybe to know how to access the sensor.

    DanhLePhuoc_: May be worth knowing a bit the agenda and the
    timing for your work, so we can try to align our efforts.

    DarkoAnicic: WoT to be a WG in october, and 1st f2f end of this
    year / beginning of next year.

    sebastian: We have 3-4 f2f meetings every year.

    DarkoAnicic: The next f2f is very likely to be in the US. But
    we can arrange a "plug fest" where anyone can participate.

    Maxime: May be worth checking if SSN and WoT are talking the
    same language - this would help better understand what needs to
    be done.

    AndreaPerego: About the property to link observations and TDs,
    this may already exist, e.g., in PROV-O.

    Kerry: Yes, but if we define one in SSN this would be
    "stronger".

Summary of Action Items

    [NEW] ACTION: frans to act on resolution of issues 77 and 78
    [recorded in
    [54]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
    [NEW] ACTION: kerry to redefine ssn:Observation and update
    alignment with DOLCE [recorded in
    [55]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]

      [54] http://www.w3.org/2016/09/20-sdw-minutes.html#action01
      [55] http://www.w3.org/2016/09/20-sdw-minutes.html#action02

Summary of Resolutions

     1. [56]the description for Issue #77: A new requirement for
        SSN is proposed: It should be possible to model actuation
        functions of sensing devices
     2. [57]add ssn req: There should be examples of how the SSN
        ontology can be used together with other vocabularies.
     3. [58]The ssn:Observation will be redefined as an activity,
        in line with O&M Observation
        jtandy: Consequently, there will need to be work to realign
        with DOLCE
        <danbri> (do we still get this sanity-checked with top 3
        SSN stakeholders?)
        <scribe> ACTION: kerry to redefine ssn:Observation and
        update alignment with DOLCE [recorded in
        [59]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
        <trackbot> Created ACTION-201 - Redefine ssn:observation
        and update alignment with dolce [on Kerry Taylor - due
        2016-09-27].
        jtandy: We've just made a decision. We should make sure
        that our vocab is reviewed by current users, incl, say,
        Siemens.
        Future Face to face meetings
        Discussion around WWW 2017, 3-7 April
        <AZ> audio is gone
        <ahaller2> trying to get you back
        Meeting in December, London 12-13 December. Prob then in
        March 21-22 in Delft, TBC
        [Coffee Break]
        <eparsons> Back at 16:00
        <eparsons> Thanks AZ see you so
        <eparsons> NP :-)
        <AZ> enjoy Lisbon
        <Kerry> Introductions..
        <Kerry> Chair:Kerry
        <AndreaPerego> scribe: AndreaPerego
        <scribe> scribeNick: AndreaPerego
        <phila> scribeNick: AndreaPerego
        kerry: We need to discuss about decisions that may have
        implications for both groups.
        DarkoAnicic: I can give a short introduction on the work
        done so far.
        Joint Session with WoT IG
        <Kerry> Topic : web of things update
        DarkoAnicic: f2f meeting will be thu - fri. You're welcome
        to join.
        ... each f2f will have also a practical session to show
        what we are doing.
        ... IoT means different devices, and how to connect such
        devices.
        ... we are working also on enabling interoperability at the
        application layer.
        ... today we have a number of standards bodies working on
        different standards and platforms.
        ... our goal is to build a set of building blocks so that
        such standards and platforms are able to use them and be
        interoperable.
        ... in other words, we want to bridge these standards and
        platforms.
        ... (responding to kerry) we don't want to provide
        different solutions for each of these standards / tools,
        but to set up re-usable and sharable building blocks.
        ... (describing the building blocks) building blocks
        include: application script layer (interoperability of
        scripts across devices), resource model (abstraction of
        properties and actions for devices), protocol bindings.
        ... Notion of "thing description" plays a central role in
        the framework.
        <DarkoAnicic> TD current practices:
        [60]http://w3c.github.io/wot/current-practices/wot-practice
        s.html#thing-description
        DarkoAnicic: Why we need it? This is needed to know what
        kind of data you serve, who you are, how you can access
        data/function, what kind of functions are available,
        protocols, encodings, which are the security constraints
        (if any).
        ... The thing description describes the resource model, the
        protocol bindings, and the WoT servient (client/server
        role).
        ... This allows also to avoid all the work around embedded
        programming.
        ... Thing descriptions include descriptive metadata,
        security-related info (e.g., security token), supported
        protocols and data formats.
        ... Thing descriptions are provided in JSON-LD.
        ... The JSON-LD context mechanism allows to provide also
        contextual information that is important for operating the
        device.
        ... Also JSON binary formats exist.
        ... (describing JSON-LD snippet).
        victor: About the ontology, this includes two different
        contexts, one defined by [missed it] and one that can be
        used in order to define your own context.
        frans: Do you have predefined contexts people can use?
        victor: Yes.
        DarkoAnicic: Information like UoM can be imported from
        other contexts as well.
        frans: Have you also location information?
        DarkoAnicic: Not really, but you can extend it with
        location information, by reusing an existing vocabulary.
        ... One part of the work is devoted to discovery.
        ... In the future we'll have events where you can bring
        your own vocabulary (e.g., location), and we'll play with
        them (e.g., to find devices in a given location).
        Kerry: Are you then agnostic wrt the vocabularies used?
        DarkoAnicic: Yes, we have a vocabulary that needs to be
        used for making things work, but then you can add other
        vocabularies.
        Maxime: Are in this way limiting the extensibility of the
        thing description?
        ... I have some concerns about the fact that the thing
        description denotes both the representation and the
        presentation of the "thing".
        <ahaller2> +1 to maxime's concern
        DarkoAnicic: A component of the architecture includes a
        thing description repository, meant to register and
        discover things descriptions (TDs).
        ... You can extend TDs with other semantic models.
        ... This can be done for infos concerning application
        models, domain-dependent models, domain-independent models.
        Maxime: About UoM there are different vocabularies that may
        be incompatible. How you solve these possible conflicts?
        DarkoAnicic: We don't have a solution - this is a normal
        problem with standards.
        ... So, it's out of scope of our WG.
        danbri: What about specific domains (e.g., agriculture)?
        Can you deal with them?
        DarkoAnicic: No, this is not in the WG scope - we don't
        define domain-specific properties. We focus on the TD, that
        is domain-independent.
        sebastian: The TD is like the index.html page of a Web
        site. It's an entry point to know what the device can
        provide.
        Kerry: Is there any protocol to negotiate the change of
        context?
        ... How you can find out who can speak that language?
        <danbri> (agriculture for example,
        [61]http://agroportal.lirmm.fr/
        [62]http://www.agrisemantics.org/ … are very relevant to
        WoT apps but are not presented as IoT/WoT initiatives; it
        is good that that Thing Description architecture seems
        open-ended for such things to be included.
        <danbri> )
        DarkoAnicic: You can, e.g., import SSN, then the other
        thing discover yours, and then it has to fetch the context
        to know about SSN.
        ... The discovery can be done also on the additional
        vocabularies that have been used.
        victor: There's a proposal for an WoT ontology based on
        DUL.
        ... there's an alignment problem that should be solved by
        SSN [missed which is that]
        Kerry: We can standardise the WoT ontology in the work on
        SSN.
        <DanhLePhuoc_> +q
        <Kerry> Wot should be standalone
        Kerry: Do you consider alignments to be your task, or
        rather this should be done by other communities?
        victor: The idea is this should be done by communities
        using these "things".
        Kerry: This may be an opportunity to optimise the
        alignments planned in SSN.
        <DanhLePhuoc_> +q
        RaulGarciaCastro: SSN is not covering the digital
        representation of the "thing" (i.e., the TD).
        <Maxime> major difference: ssn:Device is a physical thing,
        whereas wot2:Thing would be its digital mirror
        DarkoAnicic: We can also use alignments in schema.org.
        <sebastian> we consider both, a wot2:Thing can be physical
        or virtual
        danbri: The problem is that this is covering too many
        domains.
        DanhLePhuoc_: (showing a discovery example)
        victor: This shows the use of one of the discovery APIs -
        in this case a SPARQL endpoint.
        <danbri> …. it passes in a basic sparql-based pattern (as
        an example at least)
        <Kerry> +
        ahaller2: Coming back to SSN, we may need to link back to
        your TD, or vice versa.
        DarkoAnicic: Yes, and you can use also a generic property
        ("has description").
        sebastian: Which can be the scenario for this?
        ahaller2: To show which is the origin of the observations.
        <DanhLePhuoc_> +q
        ahaller2: And maybe to know how to access the sensor.
        DanhLePhuoc_: May be worth knowing a bit the agenda and the
        timing for your work, so we can try to align our efforts.
        DarkoAnicic: WoT to be a WG in october, and 1st f2f end of
        this year / beginning of next year.
        sebastian: We have 3-4 f2f meetings every year.
        DarkoAnicic: The next f2f is very likely to be in the US.
        But we can arrange a "plug fest" where anyone can
        participate.
        Maxime: May be worth checking if SSN and WoT are talking
        the same language - this would help better understand what
        needs to be done.
        AndreaPerego: About the property to link observations and
        TDs, this may already exist, e.g., in PROV-O.
        Kerry: Yes, but if we define one in SSN this would be
        "stronger".
        DarkoAnicic: You're also very welcome to join our meetings
        here at TPAC, also to send a message to the WG.
        Kerry: (describing the re-design of SSN)
        ... (going through the source in GH).
        <Maxime> [63]http://ci.emse.fr/pep/
        <Maxime> SOSA-Core
        [64]https://raw.githubusercontent.com/w3c/sdw/kjanowicz-ssn
        /ssn/rdf/sosa.ttl
        WoT IG wiki: [65]https://www.w3.org/WoT/IG/wiki
        <frans> ACTION: kerry to propose a property in SSN to link
        to WoT TD [recorded in
        [66]http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
        <trackbot> Created ACTION-202 - Propose a property in ssn
        to link to wot td [on Kerry Taylor - due 2016-09-27].
        <frans> ACTION: Kerry to make an agenda item to analyze the
        difference between TD between SSN [recorded in
        [67]http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
        <trackbot> Created ACTION-203 - Make an agenda item to
        analyze the difference between td between ssn [on Kerry
        Taylor - due 2016-09-27].
        <frans> ACTION: Kerry to plan to use WoT plugfests to do
        SSN implementation [recorded in
        [68]http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
        <trackbot> Created ACTION-204 - Plan to use wot plugfests
        to do ssn implementation [on Kerry Taylor - due
        2016-09-27].
        meeting closes
        Summary of Action Items [NEW] ACTION: frans to act on
        resolution of issues 77 and 78 [recorded in
        [69]http://www.w3.org/2016/09/20-sdw-minutes.html#action01]
        [NEW] ACTION: Kerry to make an agenda item to analyze the
        difference between TD between SSN [recorded in
        [70]http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
        [NEW] ACTION: Kerry to plan to use WoT plugfests to do SSN
        implementation [recorded in
        [71]http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
        [NEW] ACTION: kerry to propose a property in SSN to link to
        WoT TD [recorded in
        [72]http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
        [NEW] ACTION: kerry to redefine ssn:Observation and update
        alignment with DOLCE [recorded in
        [73]http://www.w3.org/2016/09/20-sdw-minutes.html#action02]

      [59] http://www.w3.org/2016/09/20-sdw-minutes.html#action02]
      [60] http://w3c.github.io/wot/current-practices/
      [61] http://agroportal.lirmm.fr/
      [62] http://www.agrisemantics.org/
      [63] http://ci.emse.fr/pep/
      [64] 
https://raw.githubusercontent.com/w3c/sdw/kjanowicz-ssn/ssn/rdf/sosa.ttl
      [65] https://www.w3.org/WoT/IG/wiki
      [66] http://www.w3.org/2016/09/20-sdw-minutes.html#action03]
      [67] http://www.w3.org/2016/09/20-sdw-minutes.html#action04]
      [68] http://www.w3.org/2016/09/20-sdw-minutes.html#action05]
      [69] http://www.w3.org/2016/09/20-sdw-minutes.html#action01
      [70] http://www.w3.org/2016/09/20-sdw-minutes.html#action04
      [71] http://www.w3.org/2016/09/20-sdw-minutes.html#action05
      [72] http://www.w3.org/2016/09/20-sdw-minutes.html#action03
      [73] http://www.w3.org/2016/09/20-sdw-minutes.html#action02

        Summary of Resolutions

     1. [74]the description for Issue #77: A new requirement for
        SSN is proposed: It should be possible to model actuation
        functions of sensing devices
     2. [75]add ssn req: There should be examples of how the SSN
        ontology can be used together with other vocabularies.
     3. [76]The ssn:Observation will be redefined as an activity,
        in line with O&M Observation

    [End of minutes]
      __________________________________________________________
Received on Wednesday, 21 September 2016 07:59:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 07:59:12 UTC