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

[Minutes-BP] 2016-08-24

From: Phil Archer <phila@w3.org>
Date: Thu, 25 Aug 2016 10:23:57 +0100
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <297df686-4831-93a6-30cc-36c7ad777e28@w3.org>
The minutes of this week's BP call are at 
https://www.w3.org/2016/08/24-sdwbp-minutes with a text snapshot below.

                        SDW WG, BP Sub Group telco

24 Aug 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/08/24-sdwbp-irc


           Linda, ScottSimmons, ByronCinNZ, jtandy, joshlieberman,
           billroberts, MattPerry, ClausStadler, ChrisLittle





      * [3]Topics
          1. [4]BP document status (quick update & request for
          2. [5]Review 'orphan' Best Practices in §11 "Other best
      * [6]Summary of Action Items
      * [7]Summary of Resolutions


       [8] https://www.w3.org/2015/spatial/wiki/Meetings:BP-Telecon20160824

    <scribe> scribe:billroberts

    <scribe> scribenick:billroberts

    <joshlieberman> Have to leave in 15 min, regretfully.

    <jtandy> [9]https://www.w3.org/2016/07/27-sdwbp-minutes

       [9] https://www.w3.org/2016/07/27-sdwbp-minutes

    PROPOSAL: approve minutes of last meeting

    <jtandy> +1

    <Linda> +1

    <MattPerry> +1

    0 - not there

    <ScottSimmons> +1

    <ByronCinNZ> +1

    <roba> +1

    roba: notes that he was at the last meeting, but not listed in
    the 'Present' list.

    <ClausStadler_> +0 (wasn't there)

    Jeremy will ask Phil to update

    RESOLUTION: minutes approved

    <jtandy> Patent Call

    <jtandy> [10]https://www.w3.org/2015/spatial/wiki/Patent_Call

      [10] https://www.w3.org/2015/spatial/wiki/Patent_Call

    (no patent issues raised)

BP document status (quick update & request for feedback)

    Linda: we've been restructuring the BP document, especially the
    BP section itself
    ... I've gone through all of Chapter 10

    <jtandy> Here's the latest editor's draft ...

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

    Linda: have aligned with Data on the Web BP document where
    ... and merged best practices where possible, notably in the
    identifier section and the linking data section
    ... but there are still open issues and many BPs lacking
    examples (though those examples will generally come from the

    <jtandy> Linking spatial data:

      [12] http://w3c.github.io/sdw/bp/#bp-linking

    Linda: Could everyone please look at the section 'Linking
    Spatial Data' and let me know if you agree with it, whether you
    think it makes sense. Please review
    ... and there are threads on the mailing list about various
    aspects of the BPs. Please continue to contribute to those as
    much as you can

    Jeremy: I started an email thread on CRS a few weeks ago. Payam
    is compiling responses to that and might lead to a new BP
    ... there is currently a note sitting between BP1 and BP2 with
    info on CRSs

    <jtandy> [13]http://w3c.github.io/sdw/bp/#narrative

      [13] http://w3c.github.io/sdw/bp/#narrative

    Jeremy: the narrative with its rich examples around the
    flooding scenarios is currently in Chapter 12
    ... progress slow on adding to that. We have a reasonable story
    but I need to explain what each actor in the narrative is doing
    ... notes that Bill is working on something for the narrative

    billroberts: will try to finish his section of the narrative by
    end of this week

    jtandy: we'll have to find a balance of level of detail
    ... what else is everyone expecting regarding the narrative?
    ... silence...
    ... in that case I assume everyone is happy with the direction.
    Thanks to Linda

Review 'orphan' Best Practices in §11 "Other best practices"

    <jtandy> [14]http://w3c.github.io/sdw/bp/#bp-notaligned

      [14] http://w3c.github.io/sdw/bp/#bp-notaligned

    jtandy: what should we do with these ?

    Linda: these are specific BPs, most of them related to
    observation or sensor data, which were difficult to align with
    the Data on the Web approach. So they're in Chapter 11 because
    of that
    ... they don't fit in the new structure. Do we still need them?
    can they be merged with another BP?

    jtandy: comments?

    roba: just before hte meeting I posted a review of the UCR
    document from the perspective of the SSN group
    ... and some of these BPs are covered to some extent in that
    review, which could help clarify the requirements relating to
    these BPs

    Rob's review:


    jtandy: it may have been premature to include some of those
    issues in the BP doc. Will they be covered sufficiently in the
    SSN group?

    roba: it's not up to just me but I think they probably will be
    dealt with
    ... it's about ensuring that semantics are described
    sufficiently and making sure that metadata can be attached to
    ... probably more a narrative thing than a new specific BP

    jtandy: we probably need an action to evaluate BPs in the light
    of Rob's review

    roba: a lot of it is about re-use of vocabularies. How far
    should we go in the BP towards picking a specific vocabulary
    ... for example the updated time ontology, the updated SSN
    ontology, Josh's lightweight 'spatial thing' ontology
    ... should we hav e a generic recommendation that people look
    by preference to OGC as an international standards organisation
    for existing vocabularies - as opposed to eg student projects

    jtandy: we are recommending that people use established and
    well-documented vocabularies

    <jtandy> (coming to ByronCinNZ next!)

    jtandy: so the question is should we recommend new work from
    the SDW group which, because it's new, is not yet an
    established practice?

    roba: a lot of stuff can be simplified by the generic practice
    of 'look at existing OGC work first'

    ByronCinNZ: SDW is aiming mostly at general web developers, not
    spatial data professionals. Data on the Web was aimed at a more
    experienced audience
    ... the SSN part in contrast seems aimed at expert level people
    ... so seems a bit inconsistent in tone

    roba: agrees with Byron. Probably too much detail at present in
    the BP

    jtandy: so specifics of the SSN work could go into a separate
    primer, part of the SSN package of things

    Linda: so BPs 16,17,18,19 and 20 should be removed from here
    and adopted by the SSN group. Is that right?

    jtandy: let's work through those one at a time

    PROPOSAL: BP16 is migrated to SSN work

    <Linda> BP16 = [16]http://w3c.github.io/sdw/bp/#bp-notaligned

      [16] http://w3c.github.io/sdw/bp/#bp-notaligned

    <jtandy> Best Practice 16: Provide context required to
    interpret observation data values

    <jtandy> +1

    <ByronCinNZ> +1

    <Linda> +1

    <ScottSimmons> +1

    <MattPerry> +1


    <Linda> BP16 = #provide-context

    roba: some of this comes down to metadata about specific pieces
    of data. So yes, the sensor bits could be moved to the SSN
    work, but some of this is more generic and not otherwise well
    handled in the BP work

    <scribe> ACTION:ByronCinNZ to review Data on the Web best
    practices document to see if this is covered [recorded in

      [17] http://www.w3.org/2016/08/24-sdwbp-minutes.html#action01]

    jtandy: Byron, please work with Rob to distil the key
    information and present it back to the group

    roba: again, note the UCR/SSN review

    jtandy is redrafting the previous proposal:

    <jtandy> proposal: specifics of BP 16 relating to sensors and
    observations should be covered in SSN work, the general case of
    interpreting entity-level metadata needs further consideration
    in the BP doc

    <jtandy> proposal: specifics of BP 16 relating to sensors and
    observations should be covered in SSN work, the general case of
    identifiable entity-level metadata needs further consideration
    in the BP doc

    <jtandy> (it's all about the user's ability to find the entity
    level metadata and understand it)

    <jtandy> ... scratch that change!

    roba: 'identifiable' because it's about the user's ability to
    find and understand metadata. But...could I withdraw that
    suggested change!

    <jtandy> proposal: specifics of BP 16 relating to sensors and
    observations should be covered in SSN work, the general case of
    interpreting entity-level metadata needs further consideration
    in the BP doc

    <jtandy> +1

    <roba> +1


    <ClausStadler_> +1

    <Linda> +1

    RESOLUTION: specifics of BP 16 relating to sensors and
    observations should be covered in SSN work, the general case of
    interpreting entity-level metadata needs further consideration
    in the BP doc

    <ChrisLittle> +0

    <jtandy> Best Practice 17: Describe sensor data processing

    jtandy: so this means BP16 will be removed and we'll review
    whether the generic stuff is covered

    <Linda> BP17 = #describe-process

    <jtandy> proposal: BP 17 is way too specific for the Best
    Practice work - the details of working with sensor data
    processing workflows should be covered in the ssn work

    <jtandy> +1

    <ClausStadler_> +1

    <Linda> +1

    <ByronCinNZ> +1

    <MattPerry> +1

    <roba> +1


    <jtandy> Best Practice 18: Relate observation data to the real

    RESOLUTION: BP17 moved to SSN work

    <Linda> BP18 = #relate-obs

    roba: this is a special case of linking best practice

    <jtandy> propsal: BP 18 is a special case of the linking best
    practices; remove from BP doc and address this concern as an

    <jtandy> +1

    <Linda> +1


    <roba> +1

    <ByronCinNZ> +1

    <ClausStadler_> +1

    <MattPerry> +1

    <ChrisLittle> +1

    <ScottSimmons> +1

    <jtandy> Best Practice 19: How to work with crowd-sourced

    <Linda> BP19 = #crowd-obs

    RESOLUTION: remove BP18 from BP doc and address as an example

    jtandy: concerns about what makes crowd-sourced data different
    from anything else
    ... it's less about the end user but our BPs are more relevant
    as guidance to the aggregator or app/API builder
    ... is there anything more general about crowdsourced data that
    should be covered by a BP?

    <ByronCinNZ> +1

    ChrisLittle: we need examples of how it is or isn't different
    to other data to help us decide
    ... one difference is the typical lack of quality assurance
    around crowdsourced data

    Linda: if the difference is mostly in the data quality, we
    could mention it in the quality BP as an example or special

    ChrisLittle: another difference is the volume of crowdsourced

    ByronCinNZ: this is a big topic, with a lot of variation. eg
    OpenStreetMap with a lot of process, versus others with no
    control at all. We don't have a good enough definition of the
    different types to be able to provide good guidance. It's a big
    can of worms

    ClausStadler_: availability of provenance information on
    crowdsourced data is another difference to other types. It's
    iportant to have provenance to be able to decide whether to
    trust it

    jtandy: maybe all the topics around crowdsourced data are out
    of scope for us. It's up to platform providers to decide their
    own governance arrangements?

    ByronCinNZ: in some ways, it's another kind of sensor

    jtandy: the Narrative includes an example of crowdsourced data,
    eg tweeting 'the flooding has reached my building', 'I have
    food to share', photos of flooding inside buildings
    ... this is spatial data. How should those platforms capture
    and share the spatial data?
    ... Hopefully the narrative will help us decide if the
    crowdsourcing aspect is significant
    ... so I think we should leave BP18 in the 'Other' section of
    the document for now and discuss further at TPAC.

    <jtandy> Best Practice 20: How to publish (and consume) sensor
    data streams

    <Linda> BP20 = #pub-streams

    (correction above: BP19 should stay in the 'Other' section, not

    <jtandy> Proposal: BP 20 should be removed from BP document;
    DWBP already covers the general case of data streaming and
    there is nothing inherently geospatial about it

    <jtandy> +1

    <Linda> +1


    <roba> +1

    <MattPerry> +1

    <ClausStadler_> +1

    <ByronCinNZ> +1

    <ChrisLittle> 0

    RESOLUTION: BP20 should be removed from BP document

    <jtandy> Best Practice 15: Provide a minimum set of information
    for your intended application

    <Linda> BP15 = #minimum

    jtandy: this is a bit like Rob's point about identifying your
    users and picking a vocabulary appropriate/familiar to them

    roba: this is hard to test as a recommendation. BP0 had some
    very specific info about what's useful in a spatial context

    ByronCinNZ: this has a lot of overlap with the one on make your
    data indexable by search engines


      [18] https://www.w3.org/2015/spatial/wiki/BP_consolidation_proposal

    Linda: you proposed to remove this one as it is covered by

    jtandy: I think we should probably drop it as it's difficult to
    test, but we should do a bit of assessment first
    ... there was an agenda item to talk about TPAC planning. I'll
    set up a wiki page for TPAC topics and ask people to contribute
    ideas. ok?


    <roba> +1

    linda and roba agree too

    <ChrisLittle> +0 not going to TPAC

    jtandy: AOB?
    ... no

    <ChrisLittle> Bye

    <jtandy> bye


    <ByronCinNZ> quit

    <ByronCinNZ> bye

    <jtandy> RRSAgent generate minutes

Summary of Action Items

    [NEW] ACTION: ByronCinNZ to review Data on the Web best
    practices document to see if this is covered [recorded in

      [19] http://www.w3.org/2016/08/24-sdwbp-minutes.html#action01

Summary of Resolutions

     1. [20]minutes approved
     2. [21]specifics of BP 16 relating to sensors and observations
        should be covered in SSN work, the general case of
        interpreting entity-level metadata needs further
        consideration in the BP doc
     3. [22]BP17 moved to SSN work
     4. [23]remove BP18 from BP doc and address as an example
     5. [24]BP20 should be removed from BP document

    [End of minutes]
Received on Thursday, 25 August 2016 09:24:07 UTC

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