SDW WG, BP Sub Group telco

<jtandy> 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> 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> 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 ... http://w3c.github.io/sdw/bp/

Linda: have aligned with Data on the Web BP document where possible
... 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 Narrative)

<jtandy> Linking spatial data: 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> 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> 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: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0172.html

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

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

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

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

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

+1

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

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 example

<jtandy> +1

<Linda> +1

+1

<roba> +1

<ByronCinNZ> +1

<ClausStadler_> +1

<MattPerry> +1

<ChrisLittle> +1

<ScottSimmons> +1

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

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

ChrisLittle: another difference is the volume of crowdsourced data

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

<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

+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

<Linda> https://www.w3.org/2015/spatial/wiki/BP_consolidation_proposal

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

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?

+1

<roba> +1

linda and roba agree too

<ChrisLittle> +0 not going to TPAC

jtandy: AOB?
... no

<ChrisLittle> Bye

<jtandy> bye

bye

<ByronCinNZ> quit

<ByronCinNZ> bye

<jtandy> RRSAgent generate minutes