Spatial Data on the Web Working Group Teleconference

22 Jul 2015


See also: IRC log


PhilA, Kerry, Frans, Alejandro_Llaves, SimonCox, Rachel, LarsG, joshlieberman, Linda
Bill Roberts Jeremy Tandy, Andrea


<trackbot> Date: 22 July 2015

<kerry> preent+ kerry

<kerry> chair: kerry

<scribe> scribe: phila

<scribe> scribenick: phila

propsed: Accept last week's minutes http://www.w3.org/2015/07/15-sdw-minutes.html

<kerry> http://www.w3.org/2015/07/15-sdw-minutes.html

proposed: Accept last week's minutes http://www.w3.org/2015/07/15-sdw-minutes.html

<eparsons> +1

<Alejandro_Llaves> +1

+0 wasn't present

<Linda> +0 wasn't there

<LarsG> +1

<Frans> +0 was not there

RESOLUTION: Accept last week's minutes http://www.w3.org/2015/07/15-sdw-minutes.html

<SimonCox> (+1 but I was minuter)

usual patent call https://www.w3.org/2015/spatial/wiki/Patent_Call

UCR Issue 11

<joshlieberman> +0 wasn't there

use cases isue-11


<trackbot> issue-11 -- Is the provenance requirement in scope? -- pending review

<trackbot> http://www.w3.org/2015/spatial/track/issues/11

kerry: Points to Frans' summary

Frans: It's about provenance req. There's a proposal for rephrasing
... First note has proposal which is...

"Ensure alignment of models or vocabularies for describing provenance that exist in the geospatial and semantic web domains. Examples are the W3C provenance ontology (PROV-O) and the OGC metadata specfication (ISO-19115)

PROPOSED: That Issue-11 is resolved by amending the wording to ""Ensure alignment of models or vocabularies for describing provenance that exist in the geospatial and semantic web domains. Examples are the W3C provenance ontology (PROV-O) and the OGC metadata specfication (ISO-19115)" and that this applies to all deliverables, not just BP

<SimonCox> There is a significant provenance hook in existing, widely adopted spatial metadata standards. It is optional there, but there are alternatives with more general adoption. THe requirements is to not let these drift too far from each other?

kerry: I would say that we just want to be sure that Provenenace *can* be used, cf. required to be used

eparsons: I'm happy with that

SimonCox: I just typed my comment. AIUI part of my concern is that we have 2 provenance standards, both widely used.
... My understanding is that these shouldn't drift apart from each other

Frans: I think that's what is meant by the requirement. Prov is not something that is unique to spatial, but we should acknowledge that there is existing modelling of prov
... in the spatial data world and we want alignment

joshlieberman: I wanted to address that assertion. There's nothing special about spatial data prov? There is - specifically that spatial data involved info from 2 sources
... one is characteristic of something and then there is the location of that something
... Different data may come from differnet agents/processes. So we need to make sure that the prov tools can address that and that looks like a special req for spctial data that we should be addressing

Frans: So that means you don't agree with the current phrasing

joshlieberman: I looked at the issue which says there's nothing special, I think there is
... and we need to be aware of that when recommending a method.
... So I want to assert that prov is in scope for this WG

kerry: I think it's worth making that statement, but I don't think it's in conflict with the proposal
... I'm worried by something Simon said about diverging - are we going to try and make sure that PROV-O and 19115 don't diverge
... I don't think that's our business

SimonCox: I agree that it's not our business to try and fix up other people's standards, but if we're in the business of distilling BPs for SDW then we need to take into acount all the things on the table

kerry: OK, yes
... More comments? It feels like consensus

<joshlieberman> Best practices should in all likelihood point at the efforts that are in fact currently looking to align PROV-O and 19115.

<Alejandro_Llaves> +1

<kerry> +1

<Linda> +1

<joshlieberman> +1

<Frans> +1

<eparsons> +1

RESOLUTION: That Issue-11 is resolved by amending the wording to ""Ensure alignment of models or vocabularies for describing provenance that exist in the geospatial and semantic web domains. Examples are the W3C provenance ontology (PROV-O) and the OGC metadata specfication (ISO-19115)" and that this applies to all deliverables, not just BP

<SimonCox> +1 Josh - like ISO 19115-2 revision ...

kerry: Maybe this is a good time to report on the UCR

phila: Just to report that http://www.w3.org/TR/2015/NOTE-sdw-ucr-20150723/ will happen tomorrow

<Alejandro_Llaves> yay!

<eparsons> woohoo

<kerry> calp,clap

phila: Thanks all concerned, please don't tweet that link yet

<joshlieberman> +1 to phila's guidance

BP Doc

kerry: I was expecting Payam to be here ... none of our BP editors are here today
... I can point you to
... There's some work going on wrt. the stories

<SimonCox> (Yahoo recommends =D> =D> =D>)

kerry: and consolidation

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

phila: I think it's this one https://www.w3.org/2015/spatial/wiki/BP_Consolidation

kerry: There was considerable discussion about narratives
... as a data publisher, I need to do X and we need a little story around that
... so Jeremy has been trying to push that forward.
... we also wanted to talk about the user perspective
... We think there might be 7 - 8 stories to include. "As a publisher of SDW I want to..."
... think of that as a high level task that enables us to structure the document
... so open to the floor to make a suggestion
... you might find it easier to begin with I am a producer/consumer...

eparsons: I guess mine is tied to the UC that I put in and that's really the issue that Google is concerned with
... That is, how can we identify the geospatial content on the Web rather than just crawling HTML.
... We can parse the page and work out if it's talking about a location but it's not great.
... the other side of that is how can we tag our own content so that our pages can be understood
... it's about a methodology for identifying spatial content on the Web.
... I'm not proposing a specific tech method
... It's kind of a meta problem in a way

kerry: That's what we want
... ny comments or should I start asking people specifically?

Frans: RRSAgent, draft minutres
... RRSAgent, draft minutes
... Last week I did a presentation about the current state of affairs about Linked Spatial data on the Web and did some thinking.
... It's still hard to do. Just publishing metadata is now more or less possible, especially if you look at the Geo_DCAT AP
... One story I'd like to see as a publisher is how you publish metadata about spatial datasets that might be useful to a WMS, WFS etc.
... The immediate advantage would be that the data would be crawlable and discoverable

joshlieberman: I'd like to mention some work being domne at ?? to catalogue WMSs
... The biggest problem is having links *to* services that provide spatial data
... for example, there may be links to map images or features in their Web pages, but going from that to the service is hard/impossible
... Decent metadata would help there
... that for me is the biggest challenge

kerry: is this any differnet to the first story from Ed?

eparsons: I would say that it is. It's a subset of my issue

<SimonCox> Particularly because spatial data comes in an un-enumerable set of resources (with an an un-enumerable URI set)

eparsons: We already have an established way using WCS, but the catalogue itself isn't very crawlable

joshlieberman: So you, Ed, defined the problem domain. There is definitely fruit at whatever level it may be

Frans: I think it's a change of perspective. Ed's story is mostly as a consumer (G as a consumer). My story is more as a producer
... It could apply to traditional data services. For e.g. if I wanted to record a stream from my ohone, that's spatial and I may want to publish metadata with that to make it discoverable

<SimonCox> Crawlability?

eparsons: This also highlights the differences between different communities. I'm looking at gthe broad mass market

<joshlieberman> 2-way likability leads to crawl-ability

eparsons: those people are not aware of catalogues etc. and just want a way of tagging
... the classic example is a store finder

<joshlieberman> I meant (of course) linkability. Likability is optional.

<SimonCox> There are a finite set of stores.

eparsons: how do they publish that content in a form that is better than a list of addresses? they're not going to use a 19115 catalogue

SimonCox: I was trying to tease out the tension between the Josh and Ed cases. My sense is that it's between continuous datasets when any request is a query cf. a set of stores
... We know that Web crawlers are good at following a finite set of links but they're not good at making sense of a DB where an infinite number of queries can be made

<joshlieberman> +1 Simon - links between a single reference to a spatial datum and larger collections / metadata records / services enhances that and is an important part of evolving OG RESTful service binding

eparsons: I think Simon's right. It's an issue we will need to deal with. Lots of spatial data sits in DBs that crawlers can't get to

joshlieberman: This is usefully a current issue. You have the collection of services, enumerated data...
... and then you have the means of getting at them, which is specific queries. How do you get from one to the other. A single map image or feature data

<SimonCox> Linked data does not play nice with queries

joshlieberman: info derived from that to get to the rest of it is the challenge

<Zakim> phila, you wanted to talk about LD API

joshlieberman: A proposal for WFS is that when you get a response that links to info about how to use the thing it came from
... perhaps via HHTP headers

phila: http://code.google.com/p/linked-data-api/

<Linda> s/perghaps/perhaps/



<eparsons> +1 to that !!!!

<joshlieberman> http://example.data.gov/schools/bbox then leads to more information about the collection, and is space-specific

phila: Goes on about URIs as query parameters

<kerry> ?q

<joshlieberman> LD API is presently SPARQL -specific, but is certainly being used as guidance in OGC efforts to support more links.

kerry: LD API isn't a formal standard

eparsons: Things like that are all well and good but, again, Starbucks isn't going to set uop a WFS for its stores. It's a spreadsheet

<Alejandro_Llaves> +q

kerry: I don't think we've got everything in our use cases from that discussion

Alejandro_Llaves: One of the problems that was highlighted at the workshop was which kind of coordinate definitions was expected
... so we presented there our Map4RDF application where we have to check which spec was the spatial data defined? geoSPARQL? Something else? That was a problem for our work
... So it would be good to know which spec spatial data is following

kerry: You want to encode your data in a way that a service will understand how it's been done

Alejandro_Llaves: If I develop a map client that shows spatial data, it would be good to know which encoding it follows rather than checking all possibilities

phila: (sounds like dcterms:conformsTo to me ;-) )

Frans: A differnet consumer story. I;m going to Naples in a few weeks. When I go somewhere strange, I want to know about my surroundings, so my basic question is...
... you have a need of location-based info. How do you get that? e.g. Find everything releant to me near where I am?
... perhaps from a profile

kerry: The flip side is how to publish that

phila: Suggests looking at CSV on the Web work for how to publish metadata for tables that adds in location data

<joshlieberman> Actually, Starbuck has a fairly sophisticated GIS and spatial data services. So maybe not the best example!

eparsons: That still sounds like too much. I'm hoping you only have to create a Web page with tags that helps interpretation
... Think village fete, not Starbucks
... Gives more detail. Then if I can crawl it and consume it

phila: Suggests tagging with things like schema.org is still pretty specialist.

eparsons: Yep, but we need to think non-specialist

phila: I agree

<SimonCox> schema.org definitely not DL :-)

Frans: I think it was interesting that Ed just mentioned, the distinction between publisher and consumer is one, we now also have expert and amateur
... that gives us 4 stories for a start, or is it 8?

kerry: Not sure all stories will fit into those categories but I like the idea

<Rachel_> will type instead

<SimonCox> Cat on keyboard?

<Rachel_> mic not working obs !

<Rachel_> lots of use cases regarding publishing scientific data

<Rachel_> so this could be a common narrative

<SimonCox> Scientific data often in tables ... see previous discussion

phila: Wonders if Rachel is thinking of ISA Tab?

<Rachel_> done for now!

<joshlieberman> Another issue (+1 Simon) is moving between links and tables - e.g. finding / following a link and retrieving a table that includes data "like" that linked to for further analysis.

kerry: I had a similar story in my head. Thinking of a scientific publisher who isn't necessarily publishing geospatial but want to link to it
... I'm going to call a close to this discussion but it's been a useful discussion, thanks

<eparsons> we can hear !!!

<joshlieberman> +1 to kerry's voice


<SimonCox> yes - you are loud and clear Kerry

<SimonCox> Numbers down today

kerry: Bemoans the shape of the Earth and its tilted axis

<Frans> I have already had my little vacation

kerry: we have warnings of BOP editors being off etc. Should we go into summer shut down? Will there be enough people participating in the coming weeks to start on other deliverables

<SimonCox> Keep up momentum

kerry: Ed and I keen to not stop for the summer

<eparsons> press on with bp

<Frans> I like the idea of continuing.

<Alejandro_Llaves> +1

<eparsons> but bp only

kerry: That's the otehr part of the question, do we stick to BP only?
... that seems to be the plan

<Frans> So pause UCR work?

kerry: or are there enough people who will be here to do the other things as well?

<Linda> +1 to pressing on with bp

kerry: No, Frans, we carry on with the UCR of course.

<joshlieberman> +1 to continuing

kerry: OK, we'll carry on with the BPs. Ed and I will do our best to carry on through July/August


<joshlieberman> +1 to BP momentum partly because I think it will stimulate other activities to recognize in the BP.

kerry: Please remember to register and let us know on the wiki whether you pkan to come, where you've registered or not
... A reminder that we'll spend a day on the BP doc to get it to FPWD
... and another day on the other 3 deliverables
... we hope to do some work before then on those but that's that's the plan
... if you can't come, but can dial in, again, please let us know on the wiki.
... remember it's 2 days, Min 26-Tue 27 October

<SimonCox> Thanks all for good discussion

<eparsons> thx to phila - super scribe !

<Alejandro_Llaves> thanks, bye!

kerry: Thanks everyine

<joshlieberman> thanks, bye

<eparsons> bye

<Linda> thanks bye!

<LarsG> Cheers

<Frans> have a good day or night!