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

[Minutes] 2016-02-09 F2F Day 2

From: Phil Archer <phila@w3.org>
Date: Tue, 9 Feb 2016 14:56:36 +0000
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <56B9FE24.9010506@w3.org>
Minutes from today's F2F meeting are, of course, at 

The text version is pasted below.

Thank you Linda, thank you Geonovum, for hosting us.

Thank you Kerry for staying the course to 02:00!

           Spatial Data on the Web Working Group Teleconference

09 Feb 2016


       [2] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

    See also: [3]IRC log

       [3] http://www.w3.org/2016/02/09-sdw-irc


           ahaller2, eparsons, kerry, BartvanLeeuwen, Lina, Linda,
           AndreaPerego, phila, frans, DanhLePhuoc, jtandy, aharth,
           LarsG, billroberts, ChrisLittle, rachel, jonblower,


           BartvanLeeuwen, billroberts, Linda, phila, aharth


      * [4]Topics
          1. [5]SSN stuff
          2. [6]SSN
          3. [7]Collaborative tool
          4. [8]assigning tasks
          5. [9]Coverages
      * [10]Summary of Action Items
      * [11]Summary of Resolutions

    <eparsons> [12]https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

      [12] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

    <kerry> scribe: BartvanLeeuwen

    <kerry> scribeNick BartvanLeeuwen

    <kerry> scribeNick: BartvanLeeuwen

    <phila> agenda:

      [13] https://www.w3.org/2015/spatial/wiki/Agenda_F2F3

    <phila> chair; Ed

    <phila> chair: Ed

SSN stuff




    kerry: 1st thing, modularisation
    ... this is the most indemand thing, we had a discussion about
    this already
    ... can we do our FPWD about this
    ... the task of modularizing SSN is a significant thing to do,
    to get feedback

    jtandy: I agree, that breaking it up in small chunks is making
    the vocabulary easier to use.

    ahaller: will DULC be a module

    kerry: it will be external, a vocabulary which imports SSN and

    ahaller2: shouldn't we just have one vocabuarly, and a
    lightweight IOT deliverable

    kerry: I don't have big objection that, but probably a lot of
    other have
    ... others might argue that SSN including DOLCE is too

    frans: I wonder what the modularization is about, it seem to
    split it in several files

    <ChrisLittle> preseent+ ChrisLittle

    frans: how does that influence usability, it could be a barrier
    to have different namespaces for different properties

    kerry: I'm inclined to agree with you

    frans: which problem is being solved by modularization?

    <ahaller2> agree too, too many modules may prevent usage

    DanhLePhuoc: do we do modularization on base of previous work
    on SSN, or on newly chartered requirements

    kerry: if we don't want to split SSN and take out DOLCE, I
    don't have a problem with that, we do have new requirements
    which we could do a new vocabulary
    ... I've put something on the list which is something like a
    'profile' which a reasoner could put back together
    ... on of the other calls is about lightweight IOT vocabulary
    ... I'd like to relate that to SSN
    ... I'm not pushing the idea we need to split up SSN

    <Zakim> jtandy, you wanted to ask how / if modularisation will
    help _users_ of the vocabulary? other than providing it in
    smaller conceptual chunks

    jtandy: I'm thinking why I said modularization is a good thing,
    what are the key benefits of modularization here? Is this going
    to work with OWL ontology
    ... are we making it easier for users, or does it introduce
    problems with multiple namespaces
    ... is it easier to maintain. Key question what is it what we
    want to achieve ?

    DanhLePhuoc: I have some answer why we might need to split up,
    if you have small devices we need to have a option to build a
    small device we need to be able to load a subset of the
    ontology on the reasoner.
    ... it is also a strong requirement in wht WOT group, how can
    we do processing on the micro controler

    <jtandy> [wow - I hadn't realised that @DanhLePhuoc & others
    was intending to load reasoners onto embedded devices!]

    frans: I wonder how the usage of ontologies on the devices will
    work, if I have a array of devices do I just implement SSN, or
    do I subset it.

    <Zakim> phila, you wanted to talk about SHACL and IoT Lite

    phila: in a seperate domain I keep comming up into application
    profiles, which puts wonderfull ideas of ontologies in
    something practical one can use.
    ... what is in my head, SSN is being put forward as a REC,
    including modularization you talked about, parallel to that we
    publish a NOTE which is already written, IOT-Light a member
    ... it fits in this group, and the internet of things interest
    ... if the group agrees we could jointly review this submission
    and publish this jointly
    ... we could also publish a machine readable SHACL which
    represent the profile

    <jtandy> [SHACL: [15]https://www.w3.org/TR/shacl/]

      [15] https://www.w3.org/TR/shacl/]

    eparsons: with you proposal, is there any sequencing needed ?

    phila: no, NOTEs are not normative
    ... if we do decide to do this, we have no idea what that means
    to the OGC/W3C publising scheme

    eparsons: its a different domain in OGC

    phila: its interesting to see how this needs to be processed

    <jtandy> [a good job that Scott S is our rep from OGC :-) ]

    kerry: steve liang, the sensors things person, did show up on
    our meetings.

    <phila> [16]SHACL

      [16] https://www.w3.org/TR/shacl

    <phila> [17]IoT Lite Ontology

      [17] https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126

    kerry: I posted on the list how to create a extraction of SSN

    DanhLePhuoc: regarding the joined forced the WOT I talked to
    people in WOT IG about the joined work
    ... we have large project with 13 partners about IOT , we have
    a strong will for standarisation
    ... it is a good idea to have joined force, the WOT will go for
    a working group bringing a lot of industry.

    <ahaller2> +1 to collaborate with WOT on the Lite ontology

    eparsons: is this working group thinking about publishing SSN
    and do a IOT light note, or still do modularization of SSN

    kerry: I'm happy with the plan phila put forward, a profile of
    SSN sounds like a smart thing to do, not sure how SHACL fits in

    aharth: I think modularization has a couple of benefits, it
    keeps modeling small, lowering the learning curve

    <frans> I can see how modularization helps the ontology
    developers. If users only use profiles the modularization won't
    bother them

    aharth: it allows to reuse certain parts of existing
    vocabularies, e.g. coverage of SDW, units vocab by NASA or

    <Zakim> phila, you wanted to separate SHACL and profile issues

    aharth: this could be the benifit of reuse instead of inventing
    your own.

    <kerry> +q

    <kerry> SHACL uses RDF and RDFS vocabulary (in particular
    rdf:type, rdfs:Class, rdfs:subClassOf, rdf:Property, rdf:List,
    rdf:langLiteral, and rdfs:Resource) and notions (notably
    classes, instances, and subclasses). However, SHACL does not
    always use this vocabulary or these notions in exactly the way
    that they are formally defined in RDF and RDFS [rdf11-mt].

    phila: a Profile is a document describing the profile, doesn't
    have to contain SHACL

    kerry: I don't like what I see from the beginning of the SHACL

    <ahaller2> kerry point to the github



    kerry: the charter mentions modularisation in particular


      [19] https://github.com/AGLDWG/TR/blob/master/ontology

    kerry: I did a sketch of what is written in the email



    kerry: yellow arrows are imports
    ... The design pattern on the top is about how sensors work,
    but not really usefull
    ... it imports DOLCE on the right
    ... the left imports the sensor descriptions

    <jtandy> [BTW: @kerry is describing this picture:

      [21] https://www.w3.org/2015/spatial/wiki/File:Ssn_modular.png]

    kerry: SSN has problems without DOLCE, I started with modules,
    but needed DOLCE in the end



    <Zakim> jtandy, you wanted to ask about O&M and sampling

    jtandy: <wrongtime> one of the things we wanted to do is to
    bind in observations/ measurements from the OGC in SSN, do we
    need to mention that in the FPWD </wrongtime>
    ... does modularisation allow blending in
    observations/measurments form OGC

    kerry: I think this would blend in via import with
    ... there are allignment issues

    jtandy: Simon recently published something on
    observations-light and measurements-light

    Linda: without knowing the details, I did see some work on
    using a profile instead of DOLCE

    <jtandy> [Simon = Simon Cox]

    Linda: without knowing the details, I did see some work on
    using a PROV-O instead of DOLCE



    kerry: a SSN alignment with PROV-O is publised a while ago
    ... I don't see where DOLCE and PROV-O are alternatives

    ahaller2: from the original SSN the modularization is imho a
    bit to fine grained
    ... I think if we modularize DOLCE so that we can load it

    <kerry> [24]http://ceur-ws.org/Vol-1401/paper-05.pdf

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

    kerry: I'm inclined to agree
    ... the number of namespace you need to remember is large, the
    cost of the modularization is high

    <ahaller2> ahaller2: we may want to consider modules for O&M
    and Actuators, though, i.e. the new stuff we want to add

    eparsons: the argument for modularization is about replacing
    certain parts which might not be of your liking

    frans: modularization is about being able to replace parts

    kerry: I disagree, there is universal agreement that DOLCE
    should not be tied to much to SSN as it is now
    ... so pull out DOLCE
    ... there is potential use of including others e.g. PROV-O and

    <aharth> qudt has units and measurements:

      [25] http://www.qudt.org/

    kerry: other then DOLCE there is nothing we should take away

    <ahaller2> +1 to modularise DOLCE out

    DanhLePhuoc: I could agree with kerry that multiple namespaces
    is a terrible idea to work with sensors
    ... just splitting the SSN in smaller pieces is not something
    wel should do

    ahaller2: in terms on the namespaces we could use slashes in
    stead of hash so the main part of the namespace stays the same

    <frans> If users only use a profile they only have a single
    namespace, don't they?

    <aharth> @prefix ssn: <[26]http://ssn.example.org/schema/> .

      [26] http://ssn.example.org/schema/

    <aharth> and then multiple files:
    [28]http://ssn.example.org/schema/core.rdf and

      [27] http://ssn.example.org/schema/dolce.rdf,
      [28] http://ssn.example.org/schema/core.rdf

    <aharth> so on

    <DanhLePhuoc> +1 for associate namespace with a profile

    ahaller2: this will not solve that DOLCE is part of SSN so it
    needs to be imported anyway

    <kerry> propose: for modularisation we work with michael's
    proposal (but remove dul and replace with native appropriately)
    and serve it using /uris and redirects as sugested by Armin

    <phila> PROPOSED: for modularisation we work with michael's
    proposal (but remove dul and replace with native appropriately)
    and serve it using /uris and redirects as suggested by Armin

    <eparsons> +1

    <aharth> +1


    <AndreaPerego> +!

    <AndreaPerego> +1

    <ahaller2> +1

    <jtandy> +1 ... seems fair, I'm no expert tho

    <kerry> +1

    <DanhLePhuoc> +1

    <Linda> +1

    RESOLUTION: for modularisation we work with michael's proposal
    (but remove dul and replace with native appropriately) and
    serve it using /uris and redirects as suggested by Armin

    <LarsG> +1

    ahaller2: on which infrastructure do we do that?

    phila: that was my question, it can be done on w3/NS space

    <phila> ==PAUSE==

    <ChrisLittle> Thanks for scribe Bart

    <eparsons> Scribe : billroberts

    kerry: are there any other serious proposals on the table

    kerry thanks Bart for rotating her picture

    no proposals in the meeting room for other SSN modularisation

    next on agenda is: Armin's proposal for collaborative editing

    <kerry> [29]https://www.w3.org/2015/spatial/wiki/SSN_Tasks

      [29] https://www.w3.org/2015/spatial/wiki/SSN_Tasks

    ahaller2: has reviewed predictability of tool behaviour when
    working with ontologies and how that might work with Github
    ... with imported ontologies, Protege is unpredictable in terms
    of serialisation, which would cause problems if storing the
    output in Github

Collaborative tool

    ahaller2: web-protege looks promising as it has the main
    features that people will want
    ... there is a widget where you can type in axioms directly
    ... Vocol requires typing turtle, so Armin would prefer
    ... TopBraid has predictable serialisation so would work well
    with Github
    ... Webprotege has advantages for collaborative working as it
    is software as a service

    kerry: if you use this editing approach (line based editing in
    Webprotege), do you lose the Protege advantages of keeping you
    in OWL-DL

    ahaller2: it claims full OWL2 support but documentation is
    sparse so would need to check

    <Zakim> jtandy, you wanted to ask if web protege =
    [30]http://webprotege.stanford.edu ... is there a better link?

      [30] http://webprotege.stanford.edu/

    jtandy: is the above link the correct one?

    ahaller2: that is the correct link

    <jtandy> billroberts: how far are you planning to go with the
    OWLy parts (axioms) in addition to the classes and properties?

    <jtandy> ... for just classes and properties I use a text
    editor- but this doesn't scale to big ontologies

    kerry: the ontology already contains things beyond simple
    classes and properties, for example role compositions and
    multiple inheritance

    so it's already complex enough that tool support is likely to
    be needed

    kerry: will Webprotege be sufficient to support those features?

    ahaller2, DanhLePhuoc - discussion of whether RDFS is
    useful/appropriate - easy and efficient though limited
    capabilities. Is it enough?

    kerry: good idea, is it possible to add an RDFS view of the
    ontology? could be another module, similar to IoT-Lite

    ahaller2: "SSN-Lite" might be effectively another module

    kerry: don't want to take existing things out of SSN, because
    it might be already in use by the user base

    DanhLePhuoc: we'll need to consider complexity of processing

    kerry: bringing discussion back to the question of
    collaborative tools
    ... only feasible choice appears to be Webprotege

    ahaller2: alternative: just put it on Github and people can use
    their own choice of tools, as long as they check the

    kerry: would be easy to break the ontology, using that appraoch
    ... does Webprotege support versioning?

    ahaller2: not sure of details, would need to investigate

    kerry: could we use Github diff to determine changes?

    <Zakim> jtandy, you wanted to ask @phila what his other teams

    ahaller2: webprotege manages changes internally, but we can't
    use git with it

    jtandy: what are other working groups using for developing

    <frans> a canonical serialization was mentioned once?

    phila: there has been much discussion of this. No standard tool
    is available at W3C
    ... DWBP - ontology developed as a diagram and phila manually
    created the Turtle
    ... in most other groups it has not been collaborative.
    Collaboration makes it hard
    ... wishes there was a better tool available

    ChrisLittle: wikipedia notes 200,000 users for Protege "highly
    recommended, most used ontology tool"
    ... sounds a good reason for choosing Protege

    jtandy: challenge is collaboration versus desktop tool

    kerry: so only choice appears to be WebProtege
    ... there was a question on serialisation tools. Using those is
    ... vote needed?

    eparsons: no

    <ahaller2> i have already created a project on webprotege



    Decision made: use Webprotege

    RESOLUTION: The SSN editors will use Web Protege as the
    collaborative editing tool

    discussion of access to the collaborative tool

    kerry: ok for people to see work in progress, just want to
    control editing rights

assigning tasks

    anyone have a link to the task list?

    kerry: reviews task list

    <Linda> [32]https://www.w3.org/2015/spatial/wiki/SSN_Tasks

      [32] https://www.w3.org/2015/spatial/wiki/SSN_Tasks

    kerry: volunteers?

    <DanhLePhuoc> I can do 3.

    <phila> DanhLePhuoc++

    ahaller2 will do 1.1 on WebProtege

    kerry will do 1.2

    <phila> ahaller2++

    <ahaller2> ahaller2 helps with 1.2 too

    DanhLePhuoc volunteers for 1.3, to be reviewed by kerry

    <phila> ACTION: DanhLePhuoc to Reconsider O&M alignment (see
    O&Mlite) - as alternative to DUL [recorded in

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

    <trackbot> Error finding 'DanhLePhuoc'. You can review and
    register nicknames at

      [34] http://www.w3.org/2015/spatial/track/users

    <phila> ACTION: Phuoc to Reconsider O&M alignment (see O&Mlite)
    - as alternative to DUL [recorded in

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

    <trackbot> Error finding 'Phuoc'. You can review and register
    nicknames at <[36]http://www.w3.org/2015/spatial/track/users>.

      [36] http://www.w3.org/2015/spatial/track/users

    <phila> ACTION: Danh to Reconsider O&M alignment (see O&Mlite)
    - as alternative to DUL [recorded in

      [37] http://www.w3.org/2016/02/09-sdw-minutes.html#action03]

    <trackbot> Created ACTION-139 - Reconsider o&m alignment (see
    o&mlite) - as alternative to dul [on Danh Le Phuoc - due

    <phila> ACTION: Haller to clearly separate observation, sensor,
    and deployment parts of SSN [recorded in

      [38] http://www.w3.org/2016/02/09-sdw-minutes.html#action04]

    <trackbot> Created ACTION-140 - Clearly separate observation,
    sensor, and deployment parts of ssn [on Armin Haller - due

    <phila> ACTION: kerry to disentangle SSN from DUL (this may
    require adding things to SSN that are needed from DUL)
    [recorded in

      [39] http://www.w3.org/2016/02/09-sdw-minutes.html#action05]

    <trackbot> Created ACTION-141 - Disentangle ssn from dul (this
    may require adding things to ssn that are needed from dul) [on
    Kerry Taylor - due 2016-02-16].

    kerry: leave task 2 (align with Prov-O) until the previous
    tasks have been completed as there is a dependency
    ... ACTION-140 has already been done?

    <phila> action-140?

    <trackbot> action-140 -- Armin Haller to Clearly separate
    observation, sensor, and deployment parts of ssn -- due
    2016-02-16 -- OPEN

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

      [40] http://www.w3.org/2015/spatial/track/actions/140

    ahaller2: Michael's modularisation is too fine grained, so it
    does need further thinking
    ... will create a WebProtege file that separates DOLCE and SSN
    ... is happy with action 140

    kerry: that's enough for now.

    DanhLePhuoc will review previous work for aligning RDF Data
    Cube with SSN.

    DanhLePhuoc: requires first draft of modularisation

    <eparsons> action Danh will review previous work for aligning
    RDF Data Cube with SSN

    <trackbot> Created ACTION-142 - Will review previous work for
    aligning rdf data cube with ssn [on Danh Le Phuoc - due

    eparsons: that's the end of items scheduled for this morning

    kerry: we've set up initial actions around modularisation and
    removal of DUL, perhaps incorporating data cube context into
    SSN in a better way. Do you think that is enough for a first
    public working draft? or do we also need to address use cases,
    wishlist, O&M etc

    phila: is that enough for someone outside to read the document
    and understand what you are doing and make suggestions
    ... enough to show people the direction you are heading in,
    then it's enough for a first public working draft

    kerry: thinks that would be about 2 months away. Would that be



    eparsons: soon would be good

    kerry: plan for FPWD is 9 April

    RESOLUTION: Target date for FPWD of SSN is 9 April (ish)

    eparson: thanks kerry. End of SSN discussion

    eparsons: there is an hour of discussion time available.

    BartvanLeeuwen: question on terminology. Use of 'GIS' and 'SDI'

    eparsons: thinks of GIS as the tool to manage spatial content

    <jtandy> see definitions in BP doc:

      [41] http://w3c.github.io/sdw/bp/

    eparsons: once you have lots of data you want to publish,
    that's when you move to SDI

    <jtandy> GIS: Geographic information system or geographical
    information system, a system designed to capture, store,
    manipulate, analyze, manage, and present all types of spatial
    or geographical data. (ref. Geographic information system)

    <jtandy> SDI: Spatial Data Infrastructure, a data
    infrastructure implementing a framework of geographic data,
    metadata, users and tools that are interactively connected in
    order to use spatial data in an efficient and flexible way.
    (ref. Spatial Data Infrastructure (SDI))

    eparsons: so expected that SDI is discussed much more than GIS
    in SDWWG context

    ChristLittle: desire to expose the details of the data on the
    web. How do you get 'inside' the GIS in a web context

    eparsons: make distinction bewteen private internal view and a
    public external view - maybe a subset, maybe with extra

    jtandy: we have definitions in the BP glossary. Maybe they
    could be improved, but we have them (see Appendix D)

    BartvanLeeuwen: reason would be to help people who think of
    themselves as GIS experts to understand what in the BP is
    relevant for them

    eparsons: sharing my GIS with someone else might be a new use

    BartvanLeeuwen: might just want to share a shapefile with
    someone. Don't really want to set up a full SDI for that

    frans: maybe SDWWG will offer a simpler alternative to sharing
    shapefiles for exchanging this kind of info

    <Zakim> kerry, you wanted to talk about glossary

    eparsons: shuold describe simple sharing of info in our

    kerry: early on we had a partial glossary, some of it copied
    from Point of Interest working group, and ISO documents
    ... consistency of BP glossary with that other list?

    would be good to be consistent across deliverables


      [42] https://www.w3.org/2015/spatial/wiki/Glossary_of_terms

    kerry: eg we have more than on definition of coverage

    <frans> I like the idea of having a shared glossary. I think it
    is needed to reach different audiences

    eparsons: agrees. Action on editor of every document to ensure

    jtandy: Github issue 212 to address this for BP

    <jtandy> see [43]https://github.com/w3c/sdw/issues/212

      [43] https://github.com/w3c/sdw/issues/212

    frans: there is an online glossary and we could link to those
    ... could turn simple words into links to the glossary

    eparsons: it's a working document,not a separate deliverable

    frans: should be a public glossary

    eparsons: yes useful, but not required by the charter

    jtandy: respec has some automatic tools to link to glossary
    within the same document

    frans: replicate a shared glossary to each document?

    jtandy: but you might get lots of terms not relevant for that

    <Linda> scribe: Linda

    wiki page can be internal glossary which could be partially
    duplicated to different documents

    <jtandy> scribenick: Linda

    kerry: the docs should each have their own glossary internally,
    and against having glossary as separate deliverable. But we
    need to be consistent.

    The wiki glossary should help with that.

    scribe: definition clashes should be addressed when needed by

    ed: agrees

    eparsons: agrees and good point brought up by BartvanLeeuwen

    frans: is this a new action for the UCR editors?
    ... it has no glossary section now

    eparsons: it's up to you to have one or not

    <Zakim> jtandy, you wanted to suggest looking at public

    jtandy: let's take a look at the public comments of the SDW BP
    first draft



    jtandy: Rob Atkinson had a comment that needs some unpicking
    ... it's about the structure of the doc which is lacking (just
    a long list of BPs)



    jtandy: another one is from a 'Bergi' do we know him?

    BartvanLeeuwen: I encouraged him

    jtandy: we could also look at his comments

    eparsons: lets look at Robs comment first
    ... agrees with structure comment
    ... how much will introducing narrative around emergency
    response help in solving this?

    BartvanLeeuwen: agrees that structure is currently missing
    ... has funding to work on emergency response narrative

    jtandy: currently the BPs are grouped by theme, but it's not an
    easy road in
    ... the first BP will probably remain first
    ... agree that more structure is needed
    ... a pathway into the doc is needed for different user groups
    ... have the BPs in order of sequence of steps to take
    ... the data on the web BP people have tried to use a common
    theme for their examples as well
    ... we could use the emergency response theme in example
    snippets in the BPs, and have a longer narrative of the ER
    theme in an appendix.

    eparsons: makes sense

    jtandy: maybe have two main sections:
    ... one for web content people, one for data publishers.

    eparsons: one group is actors who already have GIS systems and
    another group is people who use data on the web. Both involved
    in the same scenarios.
    ... but coming from different directions.

    frans: I think their are more audiences than two.
    ... the BP could be seen as a data cube. Different user groups
    need different information from the doc.
    ... a narrative requires reading the doc from top to bottom. We
    should allow people to pick the information they need out of it
    without doing that.
    ... so self contained sections / modules needed
    ... not too many links from sections to other sections.

    eparsons: raises a fundamental point: the narrative could be a
    completely separate doc.
    ... the BP itself is then more a reference doc.
    ... the narrative would point to the BP relevant sections
    ... maybe we could use the event tomorrow where we have 'normal
    people' to ask them what would be the best way in for them.

    jtandy: this is certainly one of the questions to ask them

    BartvanLeeuwen: the DW BP now asks a lot from the reader.
    ... not sure if suggestions so far help readers

    jtandy: Rob's suggestion is to add a section that explains the
    document is not prescribing one way of doing things. We should
    do this.

    eparsons: but there's a balance, we're also helping people pick
    the right approach, not just providing a menu.
    ... to be useful we do need to make recommendations

    jtandy: Rob gives four different options which are too detailed
    to unpick here.

    eparsons: they are fair comments and not surprising to us

    jtandy: working through the ER narrative might help us
    illustrate in our own minds how it will actually work. This
    will help us describe it.
    ... Geonovum testbed results will hopefully help us.

    action jtandy to respond to Rob Atkinson's comments

    <trackbot> Created ACTION-143 - Respond to rob atkinson's
    comments [on Jeremy Tandy - due 2016-02-16].

    BartvanLeeuwen: let's talk about Bergi's comments

    GeoJSON and JSON-LD conflict in the way they are constructed.

    BartvanLeeuwen: has been discussed a lot, conclusion is it
    cannot be solved
    ... if you add LD to GeoJSON it will not work in current
    ... is unlikely to be supported.
    ... should we take this problem on?

    frans: let's say there is a single spatial ontology with a
    geometry datatype:
    ... then this will not be a problem anymore.

    BartvanLeeuwen: but still the problem of tool support

    frans: a common datatype like WKT would help

    aharth: what they did was extend geosparql ontology with their
    own property.
    ... they didn't want to use WKT but their own format they had
    ... this is a repeating thing, everyone wants to use their own
    format and keep doing that.

    frans: that's a problem we need to solve because otherwise we
    don't have interoperability.

    aharth: but that will not fly with these guys.

    <Zakim> AndreaPerego, you wanted to mention Simon's comment on
    geometry encoding in GeoJSON

    frans: we should compare different solutions

    AndreaPerego: simon Cox had a good comment on the mailing list
    about in GeoJSOn using JSON arrays for this is sensible.

    BartvanLeeuwen: but the problem with the array is if you
    serialise this back it is screwed up

    LarsG: if we standardise one format would this prevent others
    from doing their own thing anyway?

    frans: in the relational DB world it worked

    eparsons: is it really an interoperability issue on the level
    we're talking about?
    ... aren't we more concerned about interoperability on the
    Thing level instead of the encoding?

    BartvanLeeuwen: i suggested to Berni et al to separate the geo
    part and LD part on the web, but they want the whole package

    LarsG: so Bart is saying use content negotiation and choose an
    encoding depending on which format is requested.
    ... but this asks more of the publisher

    frans: geometry should be considered a data type that should be
    used the same in any format

    LarsG: is anyone in close contact with geojson community?

    eparsons: nobody really
    ... they are busy at IETF

    phila: we had contact with them before Sapporo
    ... we could ask eg if they are ok with WKT

    LarsG: that would solve our problem what to write in the BP

    billroberts: they would probably not want that

    frans: we need to look at the pros and cons of having coords in
    one string or in an array
    ... the advantage of one datatype is you don't need any

    aharth: they want to use javascript to draw coordinates on a
    ... wkt will be more difficult for them to parse

    frans: it would need only a small library.

    billroberts: they want to use it natively, not using a library

    jtandy: in rdf it is not useful to separate geometry into
    triples. Literal is good
    ... having coordinates in literal is a recommendation. Not
    saying it should be wkt especially.
    ... seems like there is a common ground: treat it as a literal
    object, not as a nested array

    frans: a datatype is more durable, json might go away and be

    billroberts: having big rdf literals is a pain in practice.
    ... having a triple refering to a separate web resource would
    be good
    ... maybe geosparql extension needed to still be able to do
    spatial things with the geometries

    <Zakim> phila, you wanted to ask about NeoGeo treatment of

    billroberts: but the serialization doesn't matter that much

    phila: neogeo doesn't put the geometry into one literal, what's
    your experience?

    aharth: a good way of doing it.
    ... if it's not one big file, but links to geometries outside,
    this makes file sharing more difficult.

    eparsons: break for lunch
    ... back at 13:00 CET, 1 hour from now.

    <phila> ==LUNCH==

    <phila_> scribe: phila

    <phila_> eparsons: Recommences the meeting

    <phila_> ... We need to talk about coverages etc. this


    <phila_> eparsons: It's the thing we've done least development
    on, but I think we're ready to make a start.

    <phila_> billrobe_: I asked for it to be on the agenda to
    discuss what we're going to do and how.

    <phila_> ... I agreed to be one of the editors

    <phila_> billrobe_: My background is in the LD work, but less
    so in coverages - I'm going to need help from the WG

    <phila_> jon: What is the scope?

    <phila_> billrobe_: Quotes the charter

    <phila_> ... mentions Data Cube, WaterML

    <phila_> ... subsetting

    <phila_> ChrisLittle: WaterMl recognises that the coverage is
    in time, not space

    <phila_> billrobe_: So what worries me is, to what extent will
    that ISO standard constrain things

    <Zakim> AndreaPerego, you wanted to say that RDF rep may be
    useful for some specific cases (e.g., centroids, bboxes)

    <phila_> jtandy: When I wrote that paragraph in the charter,
    compliant with 19123, it was so you could figure out how your
    data maps to 19123, not conformant to it.

    <phila_> ... We know about domains and ranges... the intention
    was never a formal line by line compliance.

    <phila_> jtandy: This could be a Rec track doc. It says in the
    charter we're going to do this. We could decide that a mapping
    to 19123 could be the weay to do it.

    <Zakim> kerry, you wanted to ask if sound can be improved?

    <phila_> kerry: I can't follow what's going on...

    <phila_> ... It was better this morning

    billrobe_: So the other thing I'd welcome explanation on, what
    does it mean that it will be a formal Recommendation?

    jtandy: Rec Track

    billrobe_: Does that say anything about the style or content of
    the doc?

    jtandy: It has an implication on the process you need to work
    ... Particularly you need to be able to refer to 2 independent
    implementations of all its features.

    frans: In the UCR, a note was added to the description of the
    coverages deliverable, about new work in OGC being relevant.

    jtandy: So that refers to Peter Baumann's 'CIS' which has been
    approved as a work item in the ISO process, which is hte
    beginning of the road, not the end.
    ... An implementation schema is more detailed than a conceptual
    ... CIS will eventually be 19123 Part 2

    billrobe_: So if there is existing work on this it makes sense
    to reuse.

    jonblower: So if a Rec has to be implementable, what if wanted
    to weaken that and say intelligent things about related things.
    Do we have to come up with an implementable thing?

    jtandy: We have the ability to publish more or less what we
    like as a Note.
    ... The BP doc is a Note. SSN Vocab will be a Rec.
    ... As will Time
    ... How you prove that you have 2 implementations of a vocab is
    that the terms are used more than once.
    ... If we get to the point where we don't want to make a Rec
    then we can decide as a group to do that.

    jonblower: I think doing something implementable could open a
    can of worms and involve a lot of people.
    ... I'm happy to put forward what we've done in MELODIES, but
    it's early days and not BP at this stage.
    ... I might be comfortable talking about the issues, like when
    would you use Data Cube? When would you use JSON, when is OGC's
    CIS right etc.

    kerry: I don't understand why we wouldn't do a Rec Track. I see
    this as an ontology for combining EO data with he data Cube
    ... I can find some old work that pre-dates the data Cube
    ... Implementation evidence is just that all terms have been
    ... All being well, I'll have a student project soon with 6-7
    students implementing what we're talking about here. For them
    to benefit most, implementing it in the Australian GeoScience
    model would be good.
    ... I'd be interested in that, provided others are too.

    billrobe_: The other thing that I wanted to raise ... who do we
    think it's for? We have our overall remit, but within that,
    it's about levels of sophistication.
    ... Is it aimed at people who do this all day every day?

    eparsons: I think that's fundamental and will guide us in our

    <kerry> if we are not aiming at the "nonspecialists' we have
    nothing to do

    jtandy: When I wrote the bit in the charter was - there are
    already infrastructures for handling big binary files, we're
    not going to help them
    ... And there's the LD community.
    ... What we need to do is to be able to use some array-based
    data and apply it to areas.
    ... My intention was app developers who want to use LOD and
    coverage data in a single application. That's what I was aiming
    ... It's hard to do at the moment.

    <kerry> +1

    eparsons: Are people interested in both?

    jtandy: The MELODIES project recognises 8 application areas
    where they're linking EO data with LOD. So 8 different areas
    where we can say that the problem exists.

    jonblower: Yep.

    <eparsons> Steps out for 30 minutes

    frans: Coverage is a concept from the OGC. It's a broad
    concept, time series, point clouds...
    ... Is it useful to apply that on the Web?
    ... I can image that there are several ways of modelling a time
    series that don't need to bother with a coverage.
    ... Do we want to say to the Web that it shoujld accept the
    concept of a Coverage?

    <kerry> chair: kerry

    jonblower: As well as following on from Jeremy - I think Frans
    makes a good point.
    ... There's a use case extraction job here. There's addressing,
    accessing, annotating coverages
    ... That might point us to a range of solutions.
    ... We might want to think about a specialisation of that.
    ... What sort of thing do people actually want to do.

    <Zakim> kerry, you wanted to answer frans question

    phila: Highlights the CEO-LD project and its aims

    kerry: I was looking at the use cases. I got the response that
    people want the EO data to be more visible and more
    ... The same techniques should be available to everyone.
    ... Making the data available to Web develeopers is a good
    thing. As is making liefe easier for specialists.
    ... We had that conversation about how complicated coverages
    data is in Barcelona. I'm not sure that we made a decision in
    that meeting.
    ... For me it's clear that we should talk about data that is
    mappable to Data Cube.
    ... We talked this morning about using Data Cube with SSN. is
    the data Cube too much for time series data?
    ... Does it work for EO? Yes.
    ... So I would reduce it just to data Cube.

    jonblower: To relate this to the work with the CEO-LD group -
    is focussing on satellite imagery. The coverage world is wider
    than that.
    ... Time series, numerical models, etc.

    billrobe_: Next question - the schedule. I see we're due an
    FPWD by last September so we're starting 5.5 months behind
    ... with a target end dat of end of 2016

    <kerry> +1 to frans comment

    frans: I wanted to say something about the previous subject. I
    get the impression that a lot of the UCs are about EO data. OGC
    covers more. Maybe we start wieth the EO data?
    ... That might help reduce the complexity?
    ... I can also think of use cases that are not in the OGC
    definition. The microscopy slides UC for example. That gives
    you raster data that may not fit the OGC defn.
    ... So we *could* just think about the raster data, and that
    might be what people ar elooking for? Somrthing to consider.

    <Zakim> jtandy, you wanted to make a comment that datacube was

    jtandy: Whilst it's attractive to focus on raster data in the
    EO community, it woujld miss out time series, numberical models
    ... Maybe in our work we can set a boundary of the topologies
    to look at.
    ... Data Cube was mentioned as an illustrative way of saying
    how a coverage could be encoded. There's some commonality, not
    that we need to end up with a recommendation that says we must
    use Data Cube.

    <Zakim> billrobe_, you wanted to talk about data cube

    <frans> Does the data cube vocabulary suffice for time series?

    jonblower: On Kerry's point. I think it woujld be good to have
    a look at Data Cube and see how it applies. But I don't think
    we should restrict ourselves to one model A coverages model
    includes all use cases. All coverages havea the same kind of
    properites and attributes, so I don't see how we would do
    something that only applied to EO data.

    <jtandy> +1 from me ... not restrict ourselves to RDF DataCube

    jonblower: Great of Kerry has students to look at it

    ChrisLittle: The microscopic slides are a coverage and they are
    covered by the 19123 model.
    ... The Data Cube issue - you might get 2 data cubes you might
    have one with geospatial coordinates defined as dimensions and
    on where they're not.

    <billrobe_> I agree with what Jon and others have said on data

    kerry: Understandint that coverage is much broader in an OGC
    sense... but we have the Data Cube available to most of us, and
    it can handle time series
    ... My suggestion is to limit oursleves to coverages that can
    sensibly be encoded in the Data Cube.

    jtandy: Which data cube do you mean?

    kerry: the RDF Data Cube (not the geosci Aus one)

    <rachel> s/Understandint aht/Understanding that/

    <jtandy> [I included the 'timeseries' coverage in the charter
    statement specifically so we didn't focus only on EO satellite
    / raster data]

    jonblower: Kerry, you added a word in your last sentence that
    changed my view: 'sensibly.'
    ... So you mean relatively low volume ones, cf. 10^3 x 10^3
    pixel images

    kerry: It was more the mapping of the data model, where it fits
    the cube model that i was after.

    jonblower: So you're talking about coverages with orthogonal
    axes, rather than triangular reference systems.

    <ChrisLittle> +1 to john's comment

    jonblower: Right, OK, now I understand.

    billrobe_: I like Data Cube - I do a lot of it for statistics,
    but I think it would be very restrictive to only look at things
    that only worked in data Cube.
    ... The good thing is its flexibility, the bad thing is its

    <frans> I agree with Bill.

    <jtandy> +1 to billrobe_ ... look at datacube from evaluative

    billrobe_: I wouldn't want to exclude otehr things at this

    <Zakim> jtandy, you wanted to note that the datacube might
    still work for describing the coverage metadata

    <jonblower> I also agree with Bill

    jtandy: Even if you have 10^6 points, the Data Cube might have
    been a useful way to describe the coverage.
    ... My thought was that it might be good for the metadata,
    maybe not the payload.
    ... I agree with Bill that we should start with the solution.

    ChrisLittle: Can I come back on the comment about ruling out
    point clouds. They are amenable to being represented in a data
    Cube... I'd vote to have point clouds in.

    <jtandy> we should draw the line of coverages to exclude those
    with triangular mesh networks ... and point clouds - such as
    lidar for example

    jonblower: My response to Chris would be that in that case you
    could represent anything in an RDF Data Cube. Whether it would
    be useful, smart or efficient, is another question

    <Zakim> phila, you wanted to make a suggestion about elephant

    <kerry> +1

    phila: Can we start simple nad see how we go?

    <kerry> +1 to billrobe_

    billrobe_: It would perhaps be a good idea to look at the use
    cases we've got and see where that leads us. I know we don't
    want to add more but we haven't reviewed the UCs yet with this
    in mind.

    <jtandy> [jtandy also noted that rectilinear grids (whose axes
    are not necessarily orthogonal / 90degrees) should be _in_
    scope ... jonblower agreed]

    <frans> I like Phil's and Bill's suggestions

    <scribe> ACTION: bill to review the use cases from a Coverages
    point of view [recorded in

      [46] http://www.w3.org/2016/02/09-sdw-minutes.html#action06]

    <trackbot> Created ACTION-144 - Review the use cases from a
    coverages point of view [on Bill Roberts - due 2016-02-16].

    rachel: One of the use cases I submitted requires point cloud
    data anda LIDAR so I'd like those to be attempted.

    ChrisLittle: It's nice to have an ally in the Env SCiences

    jtandy: But we only have a finite resource. Maybe we should
    identify the order in which we'll tackle things.

    <rachel> +1 to Kerry's students working on this

    kerry: If I get the student support, we might have a
    significant extra capacity.
    ... But that leads on to the timing question that Bill was
    talking about.

    billrobe_: Coming back to what we're obliged to do, and the
    time scale. I don't know whether that's possible
    ... So we have to work through these steps and have some idea
    of ther work involved. ANd then meet up with the schedule.

    <Zakim> billrobe_, you wanted to talk about schedule

    jtandy: If I can talk to the schedule. All W3C WGs have a time
    line associated with them. If you want an extension, you need
    to demonstrate that you are making progress and that there is
    an end in sight.
    ... So if we can demonstrate community support and progress, we
    can asl for an extension.

    <kerry> +1

    phila: Talked a bit abouit asking for an extension when you
    have a realistic new timeline, not waiting until the lsat

    jtandy: So by May we should have an idea of when we want to

    kerry: Would anyone like to say that extending wouldn't be
    possible from their POV?
    ... Any more comments about coverages at this point?

    jonblower: There is some stuff that we've been doing in the
    MELODIES that I can show.
    ... If that would be useful.

    <rachel> fine by me

    ChrisLittle: I just wanted to say, I don't see any mileage in
    talking more about time.

    ==Short Pause for tea making==

    <rachel> [use case for point cloud, irregular mesh coverages:


    <billrobe_> are you there kerry and rachel?



    <kerry> chair: edparsons

    <rachel> I'm back !

    <aharth> scribe: aharth

    <eparsons> thanks aharth

    jonblower: presents current state of the melodies project
    ... coverage is any kind of mapping between points in
    space/time to data values
    ... satellite images, temperatures in space/time, point
    ... different kinds of coverages are distinguished by coverages
    in space and time
    ... basically a grid of data in space and time

    <frans> Why is point geometry not a coverage?

    jonblower: land cover product on screen is a kind of coverage
    ... three data objects make up a coverage
    ... the domain is the set of points for which we have data
    ... the domain varies between coverages
    ... the range is just the list of data values
    ... in many encodings there are rules for mapping points in the
    domain to items in the list of the range
    ... the range can just be a list of numbers
    ... terminology taken from mathematical functions
    ... then there's the range metadata
    ... how to interpret the values in the range
    ... in applications domain, range and metadata are separate
    bits of information that might be used separately
    ... the ogc coverage implementation schema consists basically
    of domain, range and range metadata
    ... rdf is not good at representing the range values
    ... but rdf could be useful to describe range metadata,
    possibly domain
    ... issue is to encode range values, one possible solution from
    the melodies project is shown
    ... how do you get data from server to web browser that the
    data can be manipulated and processed within the web
    ... CoverageJSON format specification
    b/master/spec.md (?)
    ... we defined specifications for the types of coverages we are
    interested in (e.g., grids)
    ... data values can be represented in-line or as a separate


    phila: domain is quite terse, range values can be big
    ... why is domain small, and range rather large?

    jonblower: domain can be represented more compactly, you do not
    need to list the full cartesian product

    <Zakim> LarsG, you wanted to ask if Jon's explanation of
    coverage is available somewhere

    jonblower: plus there can be several ranges (for example,
    measure temperature and other things)
    ... some satellite product have up to 200 different ranges

    LarsG: thank you for the explanation what coverage is about
    ... is that written up somewhere?
    ... we could refer that from our documents for people who are
    not versed in geographical sciences

    <rachel> [thanks Jon, very clear explanation]



    frans: the idea that coverage consists of three different bins
    is very helpful

    jonblower: that works for every discrete coverage

    <kerry> also see

      [51] https://www.w3.org/2015/spatial/wiki/Cov_References

    jonblower: for analytical coverages (based on mathematical
    functions that are continuous/infinite) that might not work

    eparsons: then you'd need to specify a sampling frame?

    jonblower: yes

    billrobe_: supposed i have data for manchester, do i need to
    read the whole domain?

    jonblower: we'll come to that
    ... for the "metadata" bits, coordinate systems, parameters on
    range metadata..., that basically is RDF in disguise (via
    ... explains JSON-LD @context header/document
    ... the example includes data like profiles, calendar
    ... for the range, you might want to have something more
    efficient than JSON
    ... then again, compression works well on JSON text
    ... gzipped json is efficient compared to binary formats
    ... range values can be served in different ways, that's where
    the api comes in
    ... haven't considered the standardisation discussion yet,
    wanted to have something first that works for us

    ChrisLittle: what is "Gregorian"? with our without leap

    jonblower: we reference an external definition, defined there
    ... the coverage community ignores small coverages
    ... some coverages might be fairly small, but you have lots of
    ... coverage collections is something we have to think about
    ... CoverageJSON is a format to describe single coverages
    ... but you might have 10k, and you only want to select 1k
    ... we looked into designing a REST API, but that's quite
    ... we want to bring coverages to people who do not want to
    deal with a complex service
    ... we support content negotiation, that you can use curl/wget
    to access data
    ... we use HTTP headers to control what the client requests and
    the server returns
    ... paging, for example, is handled via HTTP headers
    ... idea is to break datasets into smaller bits, provide an api
    to allow people to inquire about smaller bits

    frans: why did you use pages, not tiles?

    jonblower: a server that does not have spatial subsetting
    capability (e.g., a web server) you need something simple
    ... if the server supports spatial subsetting, you can do that,
    basically use the opensearch capabilites for bounding box

    <Zakim> jtandy, you wanted to ask is spatial / temporal filter
    is on collections or cover


      [52] https://github.com/Reading-eScience-Centre/coveragejson

    jtandy: how do represent spatial and temporal filters?
    ... how to access sample points?

    jonblower: there is a way to access the point of the domain
    based on an index

    frans: how to apply the slicing/subsetting functionality in QB

    ChrisLittle: we've done some initial work on tiling in ogc

    <Zakim> jtandy, you wanted to talk about datacube slices and

    jtandy: inside QB, they talk about subsets and slices, but it's
    pretty arbitrary how to set that up
    ... shouldn't get hung up on QB slices

    frans: interesting to have a more general api

    jtandy: in QB you specify how to slice your data when you
    publish it, with the CoverageJSON api you can do query-time

    ChrisLittle: here's a trade-off between scalability and

    jonblower: shows examples of hydra descriptions for the api
    ... there are other things as part of a stack on top of the
    coverage foundations
    ... on the github page
    ... initial work on api spec, javascript libraries, plugin for
    leaflet are available
    ... we use the technologies in a demo portal within a web
    browser (HTML5..., subsetting on the server side via api)
    ... we also provide GeoDCAT AP descriptions
    ... because we have the data in a browser we can apply mappings
    and process the data locally in the browser (e.g., remap
    melodies land cover to modis scheme)

      [53] https://github.com/Reading-eScience-Centre/coveragejson/

    eparsons: quite quick, how big is the data?

    jonblower: around 4k data points in the north, 2k data points
    in east/weast
    ... loads as tiles, preloaded before the demo, zooming triggers
    reloading of higher resolution tiles

    frans: so you have a pyramid of tiles?

    jonblower: generated on the fly, data fits in memory on the
    server, we do tiling on-demand
    ... we think we describe the data well enough to access
    multiple different coverages and integrate those (e.g., using
    inference in OWL)

    jtandy: just to confirm, the data is in json arrays which is
    sucked into a browser

    jonblower: before we had a mapping service to get tiles from
    the server with many roundtrips
    ... running in the browser is possible though with increased
    bandwidth and better browser performance
    ... the api could also work based on static files if you would
    like to do that

    <Zakim> phila, you wanted to ask about how we can help

    jonblower: not necessariliy needed to implement a server
    ... javascript used to plot data as a zoomable widget

    phila: sounds as if there's a lot of stuff there
    ... you showed two documents: coverageJSON, which is JSON-LD

    jonblower: not fully JSON-LD because of the range values

    phila: we could take that approach as basis for
    ... turn the vocabulary which has linked data where it makes
    sense and does not use linked data where it does not make sense
    ... one hesitation is that subsetting work is a big one, but
    not sure how well the existing method would work
    ... but there's almost a working draft there
    ... http link headers are useful

    eparsons: there are some challenges in socialising that back to
    the ogc community
    ... there are well-established views on how to handle coverages

    jonblower: there are discussions around getting a json view on
    ... but still ongoing work, concepts of json serialisation
    might deviate from the concepts of the xml serialisation

    ChrisLittle: good way to go forward as far as i have seen here
    ... there's active work in ogc on coverages
    ... the QB misses some geo things
    ... for example, slicing/dicing the cube is missing

    eparsons: do you see a division between qb and coverage
    ... the people involved are different, concepts might be

    ChrisLittle: there are similarities, for example city 3d work
    ... mechanisms are similar
    ... and fits into a bigger map

    <kerry> see [54]https://www.w3.org/2011/gld/track/issues/34 for
    the qb:subslice that was dropped from the datacube

      [54] https://www.w3.org/2011/gld/track/issues/34

    billrobe_: i like what jon presented, it works, simple,
    principled, powerful in practice, web-y
    ... what i don't know are the alternatives
    ... we need to enumerate the alternatives

    jtandy: don't know if there are many alternatives
    ... goes into similar direction to what peter baumann did with
    the xml stuff
    ... but targeted for web developers
    ... direction is right, details might need discussion
    ... one thing you might want to do is processing in the browser

    jonblower: we do some client-side processing

    frans: two questions
    ... metadata is DCAT, does the metadata identify format and api
    or are they separate?
    ... in DCAT you have a distribution, and the distribution has a
    ... file-centric view based on documents

    AndreaPerego: for example, you cannot say that something is a
    sparql endpoint, you need void for that

    jonblower: we used to use mime types

    frans: one problem with coverage is that you have large blobs
    of data
    ... but the subsetting would take care of that?

    eparsons: you could use whatever technology you want on the
    server side
    ... all what jon describes is the mechanisms for interaction

    frans: you need to limit the amounts of data that the api

    eparsons: wfs does not have a mechanism like that

    jonblower: at least need mechanism to tell the client: "the
    result is too big"
    ... do a http get on a large coverage collection
    ... and you would get a redirect to the first result page
    ... and links to next/prev

    frans: how about not getting any data at all, but only the
    ... that you can pose smaller queries

    jonblower: we use hydra to partially describe the api
    ... difficult to describe the api in a general way that a
    general client can understand
    ... curl does at least http redirects

    billrobe_: sounds like a good way to start
    ... we should see how to reconcile w3c/ogc views

    jtandy: we should read the material before we go to china

    <scribe> ACTION: jonblower to chase mike to update the
    JSONCoverage document [recorded in

      [55] http://www.w3.org/2016/02/09-sdw-minutes.html#action07]

    <trackbot> Created ACTION-145 - Chase mike to update the
    jsoncoverage document [on Jon Blower - due 2016-02-16].

    <eparsons> action billrobe_ to update on coverage plans
    following China Trip

    <trackbot> Error finding 'billrobe_'. You can review and
    register nicknames at

      [56] http://www.w3.org/2015/spatial/track/users

    jonblower: there is the interleaved format (which is
    domain:range pairs, rather like a csv file)
    ... especially for streaming and smaller formats
    ... but we do not have that in CoverageJSON

    <rachel> [should that be chase maik (Reichert) instead of chase
    Maik ?]

    eparsons: i worry about our bandwidth, there are many
    activities going on
    ... are the telecons we have are enough now that we have many
    things going on in parallel

    <kerry> not an unnecessary panic!

    eparsons: the subtopics are more of interest to particular

    <kerry> +q

    eparsons: one possibility would be to have separate telecons
    for different groups, with the "main" telco to sync up

    kerry: we might have to do that, issue could be that people
    only go to the meeting of the particular subtopic
    ... time/coverage/ssn and best practice could be split

    ChrisLittle: maybe split off time, maybe have a large meeting
    every fortnight
    ... specialised ones maybe in parallel

    <Zakim> phila, you wanted to talk about task forces and weekly

    ChrisLittle: we could then better fit the meeting times

    <kerry> +q

    phila: what the DWBP does is to rotate through the deliverables
    each week
    ... there are three deliverables
    ... short bit for each of the three, and then the focus is on
    one of the three topics

    jtandy: so once a fortnight a plenary, other weeks the
    subtopics in parallel

    kerry: i understand the proposal, is parallel at the same time?

    eparsons: not necessarily, depending on what the groups wish

    kerry: rational proposal to start from, rotating through
    different deliverables one a week might be too slow

    eparsons: we will make a proposal to the group for the modus
    operandi moving forward

    <jtandy> [subtopics: BP, Coverage, Time, SSN ... the use case
    issues will be rolled into the subtopics; don't need a separate
    call for UCR]

    kerry: we may not have enough chairs to manage all the meetings

    phila: need to involve the editors for organising meetings

    eparsons: any other comments/issues?

    jtandy: given we have four subtopics, some people might be
    interested in more than one, i'm interested in coverage and bp
    ... de-conflict meeting times as much as possible

    ChrisLittle: agenda page then could have the list of different

    eparsons: we would like to have some regularity in the meeting
    times so that other people can drop in
    ... we are about done, thanks for the hosts, linda for

    RESOLUTION: Thank you Geonovum

    <scribe> ... done, meeting adjourned

    <ChrisLittle> and thank you Linda for the chocolate

    <rachel> claps Linda for hosting, Kerry for staying up late,

    <ChrisLittle> bye

Summary of Action Items

    [NEW] ACTION: bill to review the use cases from a Coverages
    point of view [recorded in
    [NEW] ACTION: Danh to Reconsider O&M alignment (see O&Mlite) -
    as alternative to DUL [recorded in
    [NEW] ACTION: DanhLePhuoc to Reconsider O&M alignment (see
    O&Mlite) - as alternative to DUL [recorded in
    [NEW] ACTION: Haller to clearly separate observation, sensor,
    and deployment parts of SSN [recorded in
    [NEW] ACTION: jonblower to chase mike to update the
    JSONCoverage document [recorded in
    [NEW] ACTION: kerry to disentangle SSN from DUL (this may
    require adding things to SSN that are needed from DUL)
    [recorded in
    [NEW] ACTION: Phuoc to Reconsider O&M alignment (see O&Mlite) -
    as alternative to DUL [recorded in

      [57] http://www.w3.org/2016/02/09-sdw-minutes.html#action06
      [58] http://www.w3.org/2016/02/09-sdw-minutes.html#action03
      [59] http://www.w3.org/2016/02/09-sdw-minutes.html#action01
      [60] http://www.w3.org/2016/02/09-sdw-minutes.html#action04
      [61] http://www.w3.org/2016/02/09-sdw-minutes.html#action07
      [62] http://www.w3.org/2016/02/09-sdw-minutes.html#action05
      [63] http://www.w3.org/2016/02/09-sdw-minutes.html#action02

Summary of Resolutions

     1. [64]for modularisation we work with michael's proposal (but
        remove dul and replace with native appropriately) and serve
        it using /uris and redirects as suggested by Armin
     2. [65]The SSN editors will use Web Protege as the
        collaborative editing tool
     3. [66]Target date for FPWD of SSN is 9 April (ish)
     4. [67]Thank you Geonovum

    [End of minutes]
Received on Tuesday, 9 February 2016 14:56:37 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:20 UTC