Spatial Data on the Web Working Group Teleconference

trackbot, start meeting

<trackbot> Meeting: Spatial Data on the Web Working Group Teleconference

<trackbot> Date: 02 December 2015

<eparsons> scribe : phil

<eparsons> Topic : Approve last week's minutes

<eparsons> http://www.w3.org/2015/11/25-sdw-minutes

Last week's minutes

<jtandy> +1

<phila_> PROPOSED: Accept last week's minutes

<ClemensPortele> +1

<Linda> +1

<phila_> phila: 0 Not present

<ahaller2> +1

<phila_> +1

<eparsons> Resolved : Approve last week's minutes

<DanhLePhuoc> +1

<eparsons> Topic : Patent Call

<eparsons> https://www.w3.org/2015/spatial/wiki/Patent_Call

<phila_> Resolution : Approve last week's minutes

<eparsons> Topic : BP Editors Update

<phila_> jtandy: Payam, Linda and I got together last week and spent 8 hours working through stuff

<phila_> ... key point was that we reached consensus of what we wanted to cover.Each came up with a similar set of BPs that we want to cover

<phila_> jtandy: Want to thank Payam for hosting us at Uni Surrey

<jtandy> file:///Users/jeremy/Workspace/sdw/bp/index.html

<jtandy> http://w3c.github.io/sdw/bp/

<phila_> http://w3c.github.io/sdw/bp/

<phila_> jtandy: I'll work through some of the main parts. We've added to the intro and scope

<phila_> ... We're still in the process of putting our notes into the doc. Some sections are in yellow which indicates that it's a work in progress

<phila_> ... Yellow is really a note to the editors that we need to do more

<jtandy> http://w3c.github.io/sdw/bp/#bp-summary

<phila_> ... If we go to the BP Summary

<phila_> jtandy: In the BP summary, you'll see that we have 31 BPs

<phila_> ... in the main body of the doc is do adopt... each BP follows the template that was put in place for DWBP

<phila_> ... So you'll see the description

jtandy: Evidence, how to test etc.
... One of the sections I'll mention now... we've included a cross reference to the requirements in the UCR doc. Comments welcome of courser

phila: Highlights the RFC 2119 keyword issue

jtandy: I don't think we need those keywords

<eparsons> phila: notes that dwbp have changed template for BP's

jtandy: When we got together we looked at their benefit clusters, it didn't look like a natural fit for our work.
... We feel we want to show that we're a specialisation and don't think we need to follow that

eparsons: I like the structure you're using
... As long as we get a narrative going as well, I'm happy. Usability from a dev POV is important

jtandy: One of the things we di on friday was to try and order the sections, prioritising what we think people will want to know forst.
... So let's talk about that order.
... First - identifiers

<eparsons> +1

jtandy: that's fundamentally different to the way SDIs work
... Next up - we thoughgt the next thing that people would expect to hear was how to express your spatial data. So there's a section on how to describe your geospatial things
... We had a long chat at TPAC and we said that all the stuff that describes the non-spatial stuff is out of our scope, which leaves the spatial relationship stuff
... Next thing is how to decribe temporal data
... What we decided was that we probably don't need a specific section on temporal data in our doc, what we do have is sections where our BPs give examples of how to use temporal data
... Most of the time related stuff will be in the time deluverable
... Then we have a little section on sensor data.
... Following that we move to the linking section and enabling discovery.
... Then exposing through APIs
... The handling large data.
... but note that earlier sections talk about accessing larger data sets through APIs etc. And that's how we can talk about coverages.

<jtandy> http://w3c.github.io/sdw/bp/#requirements

jtandy: When we went through the UCR against the BPs that we've defined, a lot weren't listed as things for the BP doc
... We've done the cross references there. Even where sometehing wasn't a BP deliverable, we've included it where we think it's relevant.
... The list of the BPs themselves is the heart of it.

<jtandy> http://w3c.github.io/sdw/bp/#bp-summary

jtandy: First BP is Use globally unique identifiers for entity-level resources

<KJanowicz> I would propose so

jtandy: So question - do we want to 'force'people to use HTTP URIs?

<BartvanLeeuwen> +1 to http

<KJanowicz> +1 for http

<Linda> +1 to http

<ClemensPortele> +1 for http(s)

<KJanowicz> exactly

eparsons: I'd say HTTP, that's what we're talking about

<MattPerry> +1 for http

<ahaller2> +1 for http

<KJanowicz> well for LD http and https will be the same

phila: Raises issue of HTTPS

<scribe> ACTION: archer to propose some wording around HTTPS cf HTTP [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action01]

<trackbot> Created ACTION-107 - Propose some wording around https cf http [on Phil Archer - due 2015-12-09].

BartvanLeeuwen: If we aren't going to recommend using HTTP, then we should change the name of the group.

jtandy: The W3C rec is that you MUST use gloablly unique identifiers, then that you SHOULD use HTTP

DanhLePhuoc: In spatial data, we're also talking about sensors and IoT, they don't use HTTP necessarily.
... So are we limiting ourselves?

jtandy: I think when we're talking about identifiers, we're saying that they should use those IDs, but not necessarily say that they must always be in a resolvable situation.

DanhLePhuoc: In some smaller devices, they might use other unique IDs, without binding to any protocol.#

jtandy: Like DOIs

<KJanowicz> there are URIs for DOIs

<jtandy> ACTION: jtandy to add issue to Best Practice 1 regarding use of HTTP URI or just globally unique identifier [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action02]

<trackbot> Created ACTION-108 - Add issue to best practice 1 regarding use of http uri or just globally unique identifier [on Jeremy Tandy - due 2015-12-09].

issue: Use of HTTP URIs or just globally unique identifiers

<trackbot> Created ISSUE-35 - Use of http uris or just globally unique identifiers. Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/35/edit>.

<ClemensPortele> In which sense is a sensor "on the web", if it does not use http(s)?

close action-108

<trackbot> Closed action-108.

<AndreaPerego> +1 to Clemens. If we are talking about spatial data *on the Web*, then we're talking about HTTP(S)

KJanowicz: Everything I wanted to say is that the SemWeb community is well aware of the HTTP/S issue. I think it's important for us to stay in the LD paradigm and say that we shoujld use HTTPS? URIs

<scribe> ACTION: Janowicw to sned us the info on HTTPS? in SemWeb community [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action03]

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

<scribe> ACTION: Janowicwz to sned us the info on HTTPS? in SemWeb community [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action04]

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

<scribe> ACTION: kryzstzof to sned us the info on HTTPS? in SemWeb community [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action05]

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

<scribe> ACTION: Janowicz to sned us the info on HTTPS? in SemWeb community [recorded in http://www.w3.org/2015/12/02-sdw-minutes.html#action06]

<trackbot> Created ACTION-109 - Sned us the info on https? in semweb community [on Krzysztof Janowicz - due 2015-12-09].

jtandy: Works through more of the BPs
... Got as far as the BP on locally unique IDs. We want to provide guidance on how they can mint their own URIs based on those things.
... We want to talk about situations where there is no ID, just the inference that something exists
... In schema.org you can talk about a hotel without actually naming it. A bit like a blank node, but not, we need to give guidance on minting URIs
... BP4 is to give advice on stable IDs for things that change over time
... Things change over time and space. Need to give guidance so we don't end up with a bunch of broken links.
... BP5 is on providing IDs for parts of larger datasets
... There will be a lot more notes going into this over the coming week.
... Next on the list is expressing spatial data, section 7.2
... The big green section is based on action-101 from Bill, Janowicz, Clemens etc.
... I don't think the list is going to appear directly in our doc
... We're going to want to give people a methodology for choosing the vocab that they want to use

eparsons: Would we say it's OK to publish data without an explicit vocabulary

<KJanowicz> -1 I would not consider that good practice

eparsons: So you've provided stable URIs but there's no vocab as such

jtandy: So there are either no semantics or it's a local vocab only.

<eparsons> sck next

jtandy: A local vocab is OK as a last resort but it's better to use an existing vocab.

KJanowicz: One of the things about RDF is that the data and metadata come together. You always have some describing vocab

<ahaller2> +1 for always recommending a vocabulary, regardless if your's or a commonly used one

ClemensPortele: I just want to point out that if we stick to that (using existiung vocabs) then we'reruling out ShapeFiles, GeoJSON etc.

<KJanowicz> but there are converters from shapefiles to RDF

ClemensPortele: I recognise the value in having a vocab but if we stick with that then we're going down a very RDF-only route

<eparsons> +1 to ClemensPortele

jtandy: Some folks will have tool chains based around GML.

<KJanowicz> and in some cases just using a shapefile is fine (not everything has to be Linked Data)

jtandy: One thing we've talked about is a grid that shows which BPs are supported by each of the main formats

<KJanowicz> +1

jtandy: We can say it's a BP to say what your vocab is, but we should recognise that some encoding or format choices won't support it.

ClemensPortele: It's also the wording 'Best practice' - some are 'Good practices'
... The format list I made for last week... you need to specify some details
... sometimes it's easier just to create a bit of GeoJSON
... And sometimes its justified to make less effort
... I think there is case for a range of approaches

jtandy: I agree. One of the advantages of having such a big WG is that we can be sensitive to those issues - please keep us on track.

eparsons: I was just going to reaffirm what Clemens said. WE should necessarily jump to 5 stars which would require an open well recognised RDF vocab, but the pragmatic solutions include just getting the unique IDs with data in whatever encoding it is
... I think we have to recognise that there are graduations of BP

jtandy: A request to Linda - can we put something like that in the scope or the intro?

<KJanowicz> agreed, but a best practice document should explain what to do in an ideal case. Of course, reaching these solutions is not always possible for multiple reasons.

Linda: I'm sure that we can come up with something that links the BPs in that way

<jtandy> phila: graduations of best practices are what lead to DWBP benefits and sharePSI maturity model

<jtandy> ... some sort of clustering (e.g. DWBP benefits or maturity model) will be useful

<jtandy> ... everyone does "this"

<jtandy> ... but to do "that" takes a bit more effort

AndreaPerego: Just a comment on the discussion about vocabs, HTTP etc.
... I was thinking - sometimes we tahink about a stepwise approach. First data on the Web, then more enhanced
... The first step is HTTP URIs, then those with conng
... We have different formats that can be used for some things and not others. If you have a format you want to use, OK.
... There is a notion of profile
... Depending on what I want to do, if you think about CSWs, you already can get the info in DC or ISO19115

jtandy: To play back the key point, there some things that everyone should do, then you gradually get more sophisticated
... I'll rattle through exrfessing spatial data. Minimum expressivity - you want to give people a type, a label, multi-lingual content if your're in that kind of environment, a ref point to put it on a map
... ANd then in the examples we'll show lots of ways of doing it.

<KJanowicz> Agreed

phila: rambles about giving people too much choice and not enough guidance

<AndreaPerego> +1

<Linda> +1 to phila

<KJanowicz> +1

jtandy: We can give guidance on giving a label, going on to toponyms, and more, you might write that in a different way.

KJanowicz: I agree with what was said before - people turn to BP documents because there's too much choice. If we make too many things optional with different alternatives
... We need to make sure that the SSN can handle non-HTTP URIs if we don't insist on that, for example - we shouoldn't make a rod for our own backs (scribe paraphrase)

eparsons: What people are saying is right - this doc needs to give advice - but we have to remember that this is a BP doc so we need to be able to identify where BPs actyally exist and are being followed.
... We need a real world example for all our BPs

<KJanowicz> Agreed

eparsons: I think it's going to be hard to publish even a draft without at last some real world examples in there to show we mean business.

jtandy: You know when you're climbing a hill and you get to a false summit...

eparsons: We need to prove that it's not just us.

jtandy: BP7 - how to describe geometry.
... Lots of meat involved, hop to determine the geometry from point to volume geometries
... How do you handle the case where geometries are 95% of your data, might want to point to things
... Bounding boxes, CRSs etc.
... BP8 - Tried to resolve the long running conversation about CRSs
... There's a BP that says if you're working on a high-precision application then WGS84 probably won't be good enough
... and you need to use something better

eparsons: I agree, but I'm concerned about the terminology. It's not just about precision. WGS84 with enough decimal points works, but some user communities have reqs that are not met by the geoid that WGS84 uses

jtandy: Aus is moving 7 cm/year which doesn't help. Geographers please help

eparsons: It's so unusual for anyone to pray to a geographer I'm enjoying it...

jtandy: How to describe relative positions. It's not in the reqs but we know people want to know it - it might fall off our list.
... BP10 describes positional inaccuracies
... etc.
... ANd finally in that section, BP11 is about properties that change over time which is hard, so BP is going to be helpful
... Over the next few days, Linda and I will be putting as much unstructured text into the doc and then we'll try and structure the text as we go.
... Hoping to have enough structure to vote next week.

eparsons: Thanks for all the work you've done in the f2f meeting, much appreciated.

Linda: I was wondering in what state should the doc be for the WG to accept it for publishing?

<jtandy> phila: FPWD? provide enough information to determine whether the document will be useful

<jtandy> ... something that someone can look at to see where we are going ...

<jtandy> ... regarding timelines; we like to have a week for members to read before voting

<jtandy> ... give people time to consider

<jtandy> ... we need to be realistic on timescales

<jtandy> ... before xmas is good; but ...

Christmas is coming

eparsons: We have the potnetial for a call on 30 Dec

So we meet on 23 Dec but not 30

<BartvanLeeuwen> +1

<KJanowicz> will miss 23rd and 30st

<AndreaPerego> Me too, I'm afraid.

<ahaller2> will miss the 23rd

<jtandy> agree with KJanowicz

<LarsG> I'll miss the 23rd and the 30th as well

phila: I'd be inclined to stop on 16th

<KJanowicz> +1

<ClemensPortele> +1

eparsons: OK, done deal. We stop after 16th

<BartvanLeeuwen> thx by

<jtandy> +1

<AndreaPerego> Thanks, and bye

<ClemensPortele> thanks!

<LarsG> cheers

eparsons: recommence on 6 Jan 2016

<ahaller2> bye