Spatial Data on the Web Working Group Teleconference -- 26 Oct 2015

<eparsons> trackbot, start meeting

<trackbot> Date: 26 October 2015

<eparsons> Meeting: SDW WG TPAC Meeting Day 2

<eparsons> Morning everyone... starting soon

<LarsG> scribe: LarsG

<scribe> scribeNick: LarsG

Notes from yesterday

BartvanLeeuwen: Problem is that featrure services choose their properties freely
... has created standardised properties using URIs
... is that out of scope for this WG?

jtandy: Canadian service stores its data in a special database but offer a web interface

BartvanLeeuwen: I want a standardised way to access the data.

eparsons: The feature service can offer RDF

BartvanLeeuwen: Is it in the scope of the WG to make a best practice for pulishing data from feature services?

<phila> Meeting: Spatial Data on the Web, TPAC F2F Day 2

eparsons: There is none, but we can say: Add this element to your data and you'll be fine
... Adding a URI is pretty straightforward, but making it webby is harder

BartvanLeeuwen: Ambulance example again. The web feature service might not tell good enough what it is, but linked data with reasoning might help

eparsons: WFS doesn't play well enough with Linked Data, catalogue servers need to expose the information well enough. There is a piece missing

BartvanLeeuwen: Catalogue service is not that necessary, but you need a standard way of doing things

eparsons: Right, but there still is no best practice

Linda: It will be in our testbed

BartvanLeeuwen: Where do we write it if it isn't a best practice?

phila: Turning a feature service into something more discoverable, you want to automate that process
... that is what Linked Data API is about
... ELDA is an implementation
... the API is there to expose the database as LD doing dereferencing etc

BartvanLeeuwen: assumes that there is a webby version of the feature service
... but how do I link them together?

eparsons: You might not just linkify the WFS, but you can create new service

BartvanLeeuwen: Right, but we should encourage people to webify their data

Linda: new document about discoverability added to the BP

ahaller2: Can we say that there is no best practice?
... we can use the LD Platform etc, that is a best practice

eparsons: We need to identify best practicesa for spatial data

ahaller2: In Linked Data clould there are examples of spatial data that are webified

eparsons: there are different APIs (spatial and webby) where do they meet?
... Can they meet at all?

BartvanLeeuwen: Will put this discussion in the API section

<scribe> ACTION: BartvanLeeuwen to put API discussion into BP document [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action01]

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

Identifiers

<BartvanLeeuwen> ACTION: BartvanLeeuwen to write up a BP around properties in WFS to link a feature to its linked data version [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action02]

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

<BartvanLeeuwen> ACTION: Bartvanleeuwen to write up a BP around properties in WFS to link a feature to its linked data version [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action03]

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

jtandy: PROV-O is based on events. Do we need to discuss how to record time and location for prov events?

<scribe> ACTION: Bart to write up a BP around properties in WFS to link a feature to its linked data version [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action04]

<trackbot> Created ACTION-85 - Write up a bp around properties in wfs to link a feature to its linked data version [on Bart van Leeuwen - due 2015-11-03].

jtandy: We don't write about BP for prov, but when it comes how to express temporal data, we might use a prov example

kerry: that might not match what we do and we do that in owl:time anyway
... prov adds no extra value here

eparsons: We can revisit that later when it comes to best practices for time

<Zakim> BartvanLeeuwen, you wanted to introduce SEM

jtandy: it's too early to pick an ontology for events. Let's see what people use and how it works for them

ahaller2: We don't need specific identifiers to solve the fuzzy event problem, it's not inherently spatiotemporal

jtandy: It's different from fuzzy places (fuzzy extent)
... we'll revisit that later

Linda: Will we have fuzzy time as a best practice?

jtandy: yes
... relationship between versions of information resources
... that describe spatial things
... DWBP has BP for versioning
... suggests to use the versioned-thing ontology
... since there is nothing specifically spatio-temporal

phila: This group should write to the DWBP and ask them to do that

eparsons: Important, since we need something to point to

jtandy: We should cite that in our BP

eparsons: Does that fit with our time frame

hadleybeeman: don't know.

jtandy: We'll revisit this after coffee

<phila> Data versioning section in DWBP

jtandy: We need to make people aware that it's OK that representations change over time
... we need an example in the "expressing data" section
... e. g. areas for police data

eparsons: Right, and we should synchronise our document with DBWP

phila: There is an example in DBWP that uses memento
... good if jtandy could check that

<scribe> ACTION: jtandy to check the BP for versioning given in DWBP [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action05]

<trackbot> Created ACTION-86 - Check the bp for versioning given in dwbp [on Jeremy Tandy - due 2015-11-03].

hadleybeeman: don't cite work in progress normatively

Linda: I've added that to the expressing data section

<phila> DWBP's doc is ahead of the SDW work and should be at CR by Jan 2016 (it's Rec Track)

publishing with clear semantics

https://www.w3.org/2015/spatial/wiki/BP_Consolidated_Narratives#publishing_data_with_clear_semantics

BartvanLeeuwen: There is no way to make a feature service explain that the thing is an instance of e. g skos:Concept

eparsons: The spatial component is secondary here, so it's flipping the view around

BartvanLeeuwen: Most software tools construct hugh URIs for the features

eparsons: So what is the best practice for using SKOS in our domain?

BartvanLeeuwen: We use that for open data for fire service

eparsons: that might be fine. We need to establish a BP, is there anytihing about spatial data that breaks skos?

kerry: people use QB and thus SKOS for publishing sensor observations

Linda: uses skos for publishing their information model, but there is nothing spatial about that.
... we might not need to have SKOS as part of our BP

BartvanLeeuwen: skos is mostly good enough for our purposes
... if you're fine with simple semantics, skos is fine

jtandy: evolving case
... several types of differently typed information, no top level governance
... you try to reconsile this into a single service
... all of that is spatial data
... so our BP needs to say that publishers should also publish definitions of what their elements mean
... WFS doesn't do that out of the bos

eparsons: that information might be in a catalogue but not in the WFS itself

jtandy: the WFS will serve GML data and might use a specific XML schema that might have that information (if it's online)
... but if it's online you can look that up in the schema data that might refer to a UML model ...
... there is a schema for GML that serves as a basis for application schemas
... that every one publishes themselves (or not)
... ... so we have JSON, feature data and hopes that someone has published an XML schema
... and linked data. Those who use linked data should publish their vocabularies
... with JSON it's just a name (so we don't know what it is)
... we can put a context on top, JSON schema is another way
... this is a set of examples we can use to show people how to publish their definitions

BartvanLeeuwen: but this is what DWBP says, too
... GML is XML, so publish your schemas
... and that doesn't say anything about semantics
... and XML holds the geospatial community back (quoting Simon Cox)

hadleybeeman: There is text in DWBP, is that enough?

<hadleybeeman> This is the Data on the Web BP doc; we're talking about BP 4 on structural metadata http://www.w3.org/TR/dwbp/

jtandy: SDW to work with DWBP to ensure that our needs is covered by their work

<eparsons> danbri are you visiting us ?

jtandy: Is there a way to say that this concept is similar to that concept?
... how can we help the mashing-up process?
... Can SKOS help with that?

<danbri> eparsons yes, are there any particular sessions it'd be useful for me to join? multi-tasking somewhat…

ahaller2: This is similar to the sameAs-discussion from yesterday

jtandy: We're trying to match the semantic concepts

phila: is ambulance a concept or a type

<eparsons> danbri anytime... we are pb bashing all day

phila: concept is not a panacea
... everyone will do it differently
... so just using semantics doesn't help

eparsons: how can traditional geospatial data publishers use SKOS to give access to their catalogue?

jtandy: There is work that converts the general feature model and creates a skos version of it
... currently not online
... this is a gap

BartvanLeeuwen: not sure that is a best practice
... a spatial thing is only one property of linked data representation
... many people started to use skos instead of literals
... you have feature services for all kinds of fire trucks, ambulances, etc.

eparsons: we get most value from using skos for non-spatial things

ahaller2: They use skos in DCAT with a dcat:theme property

BartvanLeeuwen: so then we have a best practice

hadleybeeman: is this about drawing the line betwenn SDW and DWBP or is it about vocabulary selection?
... we don't want the spec to be overly restricting

eparsons: in a feature database about fires, there is a property about the location of the fire

<ahaller2> +1 for hadleybeeman not restricting to specific vocabularies in the BP document

eparsons: can we concentrate on the spatial aspect or do we have offer BP for the other information, too?
... there are more complex use cases behind this

BartvanLeeuwen: spatial semantics are not covered by skos

eparsons: we need a spatial vocabulary, e. g. nearby
... is there a defined vocabulary for this

BartvanLeeuwen: but then it's spatial semantics about a specific feature
... we need to split the semantics into two: spatial and the semantics/properties of the feature

eparsons: that might be a solution

jtandy: thematic vs. spatial semantics

hadleybeeman: assumes that relationships between precise spatial data are precise, too. What about "nearby"? Should those be dropped in favour of only precise relations?

kerry: we had this yesterday and decided that those relations are topological and social, too

jtandy: We meet in "trafalgar square". If we see it as a monument or a meeting place, doesn't matter, it's the same place

ahaller2: foaf has basedNear

kerry: there are three relations in geosparql
... if we need a bp, that might be best for our community

jtandy: getting everyone to agree on one vocabulary is impossible. That is more for intended audience and case-specific

hadleybeeman: that's much work but you'll get feedback immediately if it works or not

BartvanLeeuwen: people might ignore the document if they don't think their case is not in there

ahaller2: we could keep it generic and refer back to ontology patterns

eparsons: there might be no best practice (gap)

kerry: if we apply that test for BP, we cannot write anything

hadleybeeman: sometimes diversity is helpful
... BP has to be testable, so we cannot just use defaults

phila: BP is not to make any mistakes

jtandy: summary: there is much we can say about spatial semantics
... e.g. helping people to find the right vocabulary for the task
... at 2014 workshop the community said they didn't know what vocabulary to use
... and they need tools in order to support all of them

hadleybeeman: is this more about methodology?

jtandy: Possibly. We need external feedback on "do we do this or that"
... Do we provide a methodology to provide the right vocabulary or do we tell them what to do.
... The first is does not age.

phila: We should offer durable advice

jtandy: we want to provide a methodology to find the right vocabulary

eparsons: primary use case is to help people that have a database to publish that on the web and make it mashable

kerry: people that only have informal locations are left out by that

jtandy: like those that just want to publish about their village fête.
... their methodology is different

BartvanLeeuwen: So we do spatial semantics and DBWP the thematic semantics?

jtandy: Yes, we don't want to give this advice

phila: common question: how do I refer to a location?

jtandy: thematic data is a broader problem

hadleybeeman: let us know if you find any exceptions to that hypothesis

jtandy: cross-border fire operations is a thematic problem. Only the location part is spatial

hadleybeeman: the location might be what glues it together

BartvanLeeuwen: but that's only for the location. The rest is thematic

eparsons: sometimes we don't want to use GIS coordinate matching but just to say it's in the same village

BartvanLeeuwen: just using the spatial component is too narrow, you need to use adminstrative info, too. Example being evacuating children to the nearest day care centre instead of to one that belongs to the same organisation

hadleybeeman: discovering data is different from data use.

jtandy: part of discovery is finding related information

hadleybeeman: we haven't discussed links between datasets

jtandy: we can provide input to a new WG trying to solve that problem

<BartvanLeeuwen> scribe: BartvanLeeuwen

<scribe> scribeNick: BartvanLeeuwen

Formalizing relation between SDW-WG and DWBP-WG

<kerry> https://www.w3.org/2015/spatial/wiki/BP_Theme_-_BPs_to_hand_over_to_other_WGs_in_W3C_or_OGC#structural_metadata

eparsons: updates yaso_ what the WG scope is.

<danbri> q about https://en.wikipedia.org/wiki/Bitemporal_data

jtandy: explains the breakdown of themes
... of the BP document

we are now looking where these themes actually meet some of the work that has been done in the DWBP WG

scribe: kerry made a list where we feel they are happening in the DWBP : https://www.w3.org/2015/spatial/wiki/BP_Theme_-_BPs_to_hand_over_to_other_WGs_in_W3C_or_OGC#structural_metadata
... we need to figure out how we can work together on these subject
... and if the DWBP has some spatial issues

yaso_: I can't remember that we have encountered any specific spatial questions
... we should setup a meeting between the editors to see where we could be complementary

kerry: there is a Web of Things breakout tomorrow, DWBP people should attend.

yaso_: I'll go there
... we didn't cover anything around machine learning and discovery of data

eparsons: what would be the methodology to work together with the DWBP editors

jtandy: we have cited about 8 BPs from the DWBP already
... we need to be sure that DWBP is aware that we are citing them
... people read our spec and will be forwared to the DWBP documents
... we need to make sure that what you have written makes sense for our BP's as well
... and see wheter we need aditional requirements in the DWBP

eparsons: what would be the process ?

yaso_: we have CR in march

jtandy: we need to be aware of that we cannnot change after that

eparsons: it will be normative so it will be solidified so we need to prioritize the work that relates to DWBP

jtandy: in early december we need to have a touchpoint to see if what we have written down matches the DWBP documents

danbri: how does this group + DWBP relate to LDP ?

yaso_: for DWBP it is not a focus for our group

<eparsons> action eparsons Arrange meeting with DWBP editors to discuss citations in early December

<trackbot> Created ACTION-87 - Arrange meeting with dwbp editors to discuss citations in early december [on Ed Parsons - due 2015-11-03].

<danbri> subtext: if neither WG end up endorsing it as a best practice for (linked) data publication, this is important feedback to W3C w.r.t. any future rechartering of the LDP effort. c.f. https://www.w3.org/wiki/Linked_Data_2015_Final_Report

hadleybeeman: we are aiming for REC date early July

kerry: there is a mention of the OGC in the DWBP document

hadleybeeman: there is a difference in our best practices
... the spec editors here are pointing to where others have possible solutions

kerry: to me the citation is to vague
... talking about: http://w3c.github.io/dwbp/bp.html#MetadataStandardized

jtandy: we want to make sure that you are aware that we are citing your work
... and at some point we want to make sure that we have communicated our changes early december
... our BP is a NOTE not a REC

hadleybeeman: it is good to know, a NOTE is more flexible.

danbri: is there a chance that the charter will be redrafted

kerry: absolutelly not

danbri: e.g. time ontology is too late
... I've heard you are not doing the time ontology

jtandy: there is a proposal by Simon Cox to update the W3C Time ontology

kerry: we didn't start before we have something tangible around the BP
... a updated timeline is on the group homepage, as stated in the charter

jtandy: shall we talk about the touchpoints now ? or should we coordinate a meeting when the issues arrive

hadleybeeman: if we have clear feedback you can pass it now, although we should not be the intermediars

eparsons: maybe you should inform the group about this call, and they are aware that these questions might come up

<jtandy> https://www.w3.org/2015/spatial/wiki/BP_Theme_-_BPs_to_hand_over_to_other_WGs_in_W3C_or_OGC

jtandy: these are also reachable from our main wiki page
... anything the DWBP wants to address now ?

yaso_: we are covering some issues they are covering as well
... we have not touched e.g. IOT, maybe we can also give SDW some feedback
... and cite the work on Sensors
... we can explain publisher of sensor data that the SDW has BP's around of this type of data.

SVG Presentation

presenter: Satoru Takagi

SVG and CRS

<stakagi> http://www.slideshare.net/totipalmate/crs-and-svg

stakagi: in charge of the SVGWG standarization of mapping
... focus on map content as graphics
... the presentaiton is about the GAP between SVG and spatial

SVG coordinates are unrelated, called user coordinate sytem

stakagi: explains how the user CRS can be mapped on a map based on the SVG 1.1 spec
... by including metadata in the SVG header

issue, nobody is using in SVG2 it will be removed

re-examintion: markup should be simpler, browsers should support CRS, concept of CRS should be generalized

kerry: stakagi thank you
... about slide 13, CRS is highly controversial
... we have talked about a 'General' CRS
... it has been a long discussion inside the OGC
... although we are spatial data on the web we have use cases where are not just talking about earth reference
... we are not sure we will have a answer in your timeframe

jtandy: the challenge we face is that we want Spatial data easier to use on the web
... most people assume that spatial data works in Google Maps
... but they don't because they don't know about CRS
... geospatial people are more picky on CRS choice
... in our group we are aware that a CRS is important part of the data
... but we discuss a default
... when we talk about publishing spatial data we talk about explicit mentioning CRS, or a general default

kerry: you still should be able to process the default CRS

LarsG: there are technologies that have a default CRS already e.g. GeoJSON and WGS84 vocab is WGS84 CRS
... the problem is the vocabularies which don't express the default explicitly

jtandy: we could use that as a selection criteria
... if you don't care about CRS, use a vocab that has a default. Otherwise use a vocab where you can supply

stakagi: we need to be able to say in SVG if it is a map, or a illustration

kerry: CRS is not just geospatial, for us it is clear that CRS can be used for documents as well

jtandy: one of our examples is Microscope slides, not spatial

eparsons: in OGC they call this a unprojected CRS

stakagi: is the naming for such a CRS acceptable
... is it acceptable that other none spatial applications talk about CRS ?

jtandy: when the spatial people talk about specific CRSs they talk about a Spatial Reference System SRS

eparsons: different communities have slightly different definitions what a CRS system is, we don't have a problem with that

kerry: there is a transformation question as well

eparsons: projections are very hard to transform

Linda: ogc describes how to describe transformation services

yeonsoo: is SVG about 2d or 3d ?

stakagi: currently is talking about 2d

jtandy: CRS in spatial are 3D mostly
... we might publish data which has elevation, SVG renders just the 2D
... but this is a transformation that needs to be done by the rendering engine
... we don't standardize those services

<Zakim> danbri, you wanted to ask about SVG + CRS in http://www.w3.org/TR/sdw-ucr/

stakagi: SVG is only 2d, but css supports 3D already
... it could also be done with a CSS transformation

danbri: how much use cases do we have on this ?

jtandy: the charter explicitly says putting things on maps is out of scope

yeonsoo: how many people are from industry

jtandy: we have 50 uses cases from government, academia and industry

yeonsoo: we develop applications for egovernment
... how can I supply use cases and requirements

kerry: be aware that mapping, putting elements on a map is out of scope
... go to our UCR FPWD and see if it matches any of your uses cases

<jtandy> use case editors draft: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html

kerry: if you have comments please add them to the comments list

yeonsoo: is weather radar data in scope ?

jtandy: YES !

<kerry> scribe: kerry

<scribe> scribeNick: kerry

===returned from lunch====

jtandy: we talked about publishing data with clear semantics
... with dwbp guests we concluded that we will focus on spatail semantics and other "thematic" semantics will be referred to DWBP
... we will check with wider sdw membership
... spatial semantics is the kind of semantics you would express in a gazetteer
... recognise that there is other but that is out of scope for us
... this is a proposal unless ...

.ed: it is that thematic semantic language that is important, but we need to handle the geospatail to add to that.

jtandy: we will provide how to recognise that two datasets are talking about the same place but we do not concern with the validity or compatibilty of thematic elements

linda: captured this associated with sameas relation yesterday

jtandy: addition is that once you have determined sameplace we will not do anything about reconciliation of the ambulances

linda: so we are not addressing thematic reconciliation

propose: that we do not address thematic reconciliation , ie, we deal with semantic reconciliation of spatial concepts only

<BartvanLeeuwen> +1

<eparsons> +1

<jtandy> +1 ... thematic reconciliation is a problem, but not in our scope

<LarsG> +1

<danbri> +1

<Linda> +1

jtandy: eg we do not help with reconciling air quality and No2

danbri: but can you help with weak paris and precise paris?

jtandy: yes, that is our job
... if you have air quality and traffic counts in a commen spatail region -- we can help with joining the space pat, but not the air quality and traffic counts

resolved: that we do not address thematic reconciliation , ie, we deal with semantic reconciliation spatial concepts only

<phila> RESOLUTION: that we do not address thematic reconciliation , ie, we deal with semantic reconciliation of spatial concepts only

jtandy: what about sensor data?

eparsons: we might have to create best practice there

jtandy: do we want to say these terms are equivalent --e.g. (missed this)

eparsons: yes

jtandy: if we publish some statements that this terms is equivalent to that term we are not tellingthem which vocab to use

ahaller2: the authors of that vocab might not like this

LarsG: if the vocabs are poorly documented we should not recommend using it at all -- noone can make sense of it

<Zakim> BartvanLeeuwen, you wanted to propose a NOTE for geo vocab comparison

jtandy: if we find something widely but inconsistently used we might advise avoiding it

danbri: but we could say here is a good way of using it

bart: geonames has a mapping

jtandy: we want to community of practice to tell us what you use and we could publish this

linda: yes this is useful

jtandy: is this our BP or a complementary note as suggested by Bart

bart: note could be done quickly as several already exist eg. geonames to schema.org -- should be nicer than this

<BartvanLeeuwen> http://www.geonames.org/ontology/mappings_v3.01.rdf

jtandy: useful discussion about enabling reconciliation with other vocabs issue
... moving on to "which vocab should i use to describe my data anyway"
... we know we are going to provide amethodolgy to help people choose which geospatial vocab to use

<danbri> ..ooO(is a Village Fete a http://schema.org/Festival ?)

jtandy: we have the "data liberation" for the SDI market and the "village fete" for content/app developers

<danbri> cf http://www.w3.org/TR/ld-bp/

jtandy: next is "how should i publish my vocab"
... want to say these exist, here are some you can use, please don't make nay new ones

ahaller2: in ssn and maybe time we need to link to other vocabs -- how do we publish the link to other ontologies?
... or is this in the description of the ontology?
... jtandy is this best practice or is it rec track for ssn deliverable?
... here we are not making a recommendation about relationships to other vocabs

phila: charter allows us to create new vocabs if we wish

jtandy... this is about applying in some context, a spcial realationship, that some tool might parse

ahaller2: refer back to linked data best practisesfor the first one...

linda: we (audience) know how to build a vocab but we do not know how to link and how important that is

phila: you write a w3c note that says we thing these terms are the same? is this helpful?

<danbri> (saying if/when http://www.w3.org/TR/skos-reference/#mapping is useful would be great imho)

eparsons: it not just the mappings, thyere is also advice as linda said. We should focus on this

phila: we are proposing to do this , not to advise people to do it

danbri: maybe we should use skos mapping realtions for this

jtandy: suggest we included a statement about some useful mechanisms to map
... here we have done some already, have a look at these and try to reuse

LarsG: rdf vocabs or controlled vocabs? skos not much use for linking between classes and properties -- this is owl

jtandy: browsing semantic mappings this morning discussion , and discovering them -- starting a new group was suggested, it is too hard for us

LarsG: aboutness -- what is this data set about the thematic part -- skos is about what things are about , skos is not solving relationships beween classes

eparsons: can we say which approach to use

LarsG: yes -- depends on the use

linda: <reads from bp doc record here> but we will need to expand on this

jtandy: keep the scope quite narrow -- agreed?

agreement

<eparsons> +1

jtandy: "different views on same resources" issue
... not my problem

BartvanLeeuwen: like this morning covered this

jtandy: there is nt a great deal of best pratice here --- could be a job for that other new group
... "mapping data in multiple formats" that's about thematic data

eparsons: agrees

phila: agrees

jtandy: so we will not make any statements as not special for us

Linda: so this clear semantics
... is quite small now

jtandy: so now this "clear semantics" couold be folded into "expressing geospatail data"

eparsons: but expressing a feature is different to the realtionships bewtween the things

Linda: but that is also in this section

jtandy: pub data with clear semantics section should be about the meaning of the spatial relationships we need
... and we put examples in the "expressing" section

eparsons: no -- expressing will talk about loch ness geometry but the relationships (eg inside) will go here

jtandy: ok, so we still have these 2 sections, one for representating the object and the other (here) for relationships with other objects

ahaller2: sounds like a data binding issue -- do we have a way of linking to the semantic description from e.g. kml (like csv on the web does)

eparsons: not sure... armin wants to add an identifier to some data say in kml, but id does link here because whatever the encoding is we will be saying you need to add this bit

jtandy: we said yesterday a bout a table of formatds and what bp will work in that format
... side discussion about status of geojson-ld

<danbri> nearby: Geo JSON-LD github community's issue list: https://github.com/geojson/geojson-ld/issues

jtandy: ok we keep this section on publishing with clear semantics for the later type problem

<ahaller2> s/sidew/side

jtandy: summarise issues covered so far

<danbri> @phila - specifically for where they are blocked see https://github.com/geojson/geojson-ld/issues/32 "Yes, it's a known issue. RDF applications are going to have to treat the coordinates as a blob, like it was imagery or audio. I can't see any way around that. I also can't see any benefit to exploding a complex multipolygon into triples."

eparsons: lets do the ones that need a tighter scope

"enabling discovery"

Linda: what is special about spatial

eparsons: sdis are taking the role of (censored) like shiny photographs that you cannot touch

linda: agrees

eparsons: complex metadata requirements that separates the content from the discovery process -- metadata portal may not be accurate
... as long as sdis exist you will not have linkable goepsatail data

jtandy: we want discovery at the entity level

eparsons: we need a different approach

LarsG: but we need to rescue the data first

jtandy: we need discovery of the spatial things and the datasets
... DWBP deals with datasets alright already

phila: see also geodcat-ap

<danbri> https://joinup.ec.europa.eu/node/139283/

Linda: they have spatail and temporal coverage (spatial extent)

jtandy: we want to tell people how to describe the spatial aspect of the data set
... geocat-ap says how to do this (or we could recommend iso19115 metadata)

<phila> What DWBP says about dataset discovery

eparsons: if you want to discover at individuals features you could describe the data set by noting all the features
... postboxes in amsterdam + 3000 urls of postboxes in amsterdam

jtandy: made assumption that you use the dataset description to find the service endpoint and then you get to the thing

eparsons: i dont want to talk to the endpoint

phila: we would like wfs et al to generate lots of web pages that could be crawled -- can we do this to those standards?

eparsons: if we do not they will not work

<Zakim> danbri, you wanted to discuss z39.50 analogy

phila: will this group say wfs should do this?

jtandy: yes -- we will say this is how it has to be done --- this 2-step stuff has to go

danbri: like the libary community and z39.50 --lots of commitment to this but you don't aks them to do this
... you create alternatives like websites wrapped around it

eparsons: a change will have to happen

phila: if our result is wrappers to create crawlable wrappers -- great, but we cannot tell the ogc to change their spec

various: yes we can, we are an ogc group

linda: there is the testbed, with a deliverable that is a wrapper tool over w*s for this purpose

phila: this sounds bigger than a section in a bp doc

eparsons: yes
... this is what nanaimo did

danbri: this is what the libraries are doing too -- avoid words like deprecate

jtandy: we are saying this is what you have to do.... not that you should not do what you arelady do

kerry: does this conflict with our ssn objectives?

jtandy: no, it is consistent --- we will showw what the "web" interface should look like

ben: does this make a difference if behind a paywall?

jtandy: no--- same approach

enabling discovery: discovery of datasets and the features/attributes they contain

jtandy: we want to summarise all the objects the dataset talks about -- makes crawling easy but maintenance might be hard

eparsons: the collectionlevel entity should be created from individual components -- is not separate from the entities
... otherwise it will not get done
... manage the entities themselves and aggregate to collection

lars: is there a bp for publishing link sets
... talked about a joint note with dwbp for this

phila: answering for hadley.... a note it would be good to have people outside spatial world, suggests people from pacific nw and lawrence berkely labs

<scribe> ACTION: phila to write to us labs to get participation in the joint linksets note [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action06]

<trackbot> Created ACTION-88 - Write to US labs to get participation in the joint linksets note [on Phil Archer - due 2015-11-03].

eparsons: one of the big concerns -- how can we know who is using our data? this backlinks will help a lot

jtandy: (shows demo) of linked resources and sets of spatial things and sameas relationships -- this is a gnon demo
... identifier matches to relatedd resources, uses link sets to summarises at dataset level -- and says to go looking into a service to get the individual detail
... i think they are called technical features -- here i s some practice we can show but not completely

<LarsG> https://gbv.github.io/beaconspec/beacon.html

LarsG: beacon file format is like this
... mapping sets of identifiers to each other
... has a header and prefixes and a csv-like format. header says what is relation between pairs of identifiers
... this is kind of a link set

jtandy: linkset says go here to find more -- but this is a way of representing the links

<jtandy> http://www.w3.org/TR/void/#describing-linksets

jtandy: describing linksets in void
... is similar
... beacon could express links outside of data that does not do it itself

lars.... they curate the link in the wikipedia page which is then exported to beacon format

eparsons: like the simplicity

jtandy: if we want to find ifo about a particular place

.s/info/info/

jtandy: datacube uses placenames as a dimension... can quickly find related thematic data

eparsons: does constrain you to the scope of the gazetteer

linda: summary of enabling discovery: i have very little
... <reads from bp doc>

eparsons: should say that some ogc services will need to be modified for discovery
... we need to make a statement that the current wxs services need another layer on top to expose their content
... is this discoverability or apis?

Linda: why do we need this? to make it more discoverable and linkable

jtandy: bp is to make a crawlable page for each spatial thing
... you might want to layer this over the top of a wxs to achieve this

eparsons: you might need more -- for identifiers and merging in extra data that was not here

jtandy: this should go in exposing APIs section

Linda: for discovery one solution is to make crawlable pages

jtandy... and to make it linkable you ned uris for each resource, then the next step is to generate a crawlabe page for each of these

s/cralabe/crawlable/

eparsons: you need more than just a wrapper over wxs for the identifiers

jtandy: linksets or beacon format...

Linda: i have this in linking data -- should i move it? \

jtandy: this is needed for backlinking

eparsons: also give a mechanism to measure data usability

Linda: will move that stuff to discovery then

jtandy: datacube to describe datasets that could be described as a set of places
... this place is described in that daset which is bound to that datacibe dimension thatis ... (missed)

<scribe> ACTION: jtandy to write how this datacube/gazeteer/foreign key works [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action07]

<trackbot> Created ACTION-89 - Write how this datacube/gazeteer/foreign key works [on Jeremy Tandy - due 2015-11-03].

armin: the gazeteer here could be a simple named graph/graph uri

phila: beacon looks interesting -- now wildcards? you have to name every thing . would be good to have regular expressions

armin: would break the url?

phila: browser would interfere with you

jtandy: use rfc6750

enabling discovery: summary records (metadata) - spearate metadata records?

eparsons: publishing grou metadata is the linkset thing

LarsG: might be a need .... behinf the paywall

eparsons: e.g.wiki sitemaps

enabling discovery: where do i discover what is available for use based on current context (space and time)?

jtandy: how can you do this in a search engine?

danbri: search engines do not have this product

jtandy: e.g i type in sapporo
... gogle knows i am talking about the place

eparsons: the bit on the side comes from the knowledge grapg
... the knowledge graph part knows that sapporo is a place

ahaller2: you want to query for sapporo is a type of place

jtandy: yes -- you want spatial and temporal context for the search

eparsons: there is a chicken and egg -- a lot of this thematic data is not avail to search engine-- eg behind inspire geoportal

<danbri> e.g. https://developers.google.com/structured-data/testing-tool/?url=http://travel.cnn.com/tokyo/sleep/hokutosei-sleeper-train-tokyo-sapporo-905418

<danbri> has a City named Tokyo

<danbri> via a google custom search restricted to pages describing a (schema.org)'City' https://cse.google.com/cse/publicurl?cx=013484121852858951051:_k8pkh6pfio

eparsons: we sugested people put kml arounf the wms endpoint to provide a spatail extent that was open to google parsers

jtandy: so the linking is still text based matching -- google knowledgegraph might get this

eparsons: that is already there
... usong knowledge graph only -- e..g. "and when was he born?"

LarsG: can we query danbri about sameas in schema.org

danbri: dealing with anchoring a blank node against a well known page
... it does not have to be an html page, couild be pdf or anything
... its just a url that can be used to join data
... itcould be a mailto: url

jtandy: and on to basic geo spatial thing

danbri: was cyc-influenced-- may be too all-encompassing
... we did not think about it too much

jtandy: do we want to subtype this for objects with fuzzy or unknown boundaries?

<ahaller2> kerry: proposes that considering that SpatialThing does not say much, we need a stronger statement

eparsons: is this causing confusion now? if so we could tidy it up, if not -- its ok to reuse

break now, and meet back at 4:15

<ahaller2> scribe: ahaller2

<scribe> scribeNick: ahaller2

BartvanLeeuwen: Question: Kerry proposed to define something else than SpatialThing, what do you mean?

kerry: only the spatialThing

BartvanLeeuwen: on the Web there is a lot of geo:lat and geo:long, we should not alienate the community

eparsons: we should definitely not do that

kerry: geo lat and long should stay

BartvanLeeuwen: don't throw out the baby with the bathwater

ahaller2: I thought kerry was suggesting to have a subclass of SpatialThing that is more precisely defined

jtandy: our resources are member of multiple sets, we can live with SpatialThing

eparsons: we can document why you may need other things in special cases

jtandy: in expressing geospatial data we may need to include some statement about the limitations if there are any of the SpatialThing

next agenda item

eparsons: what to do next?

next agenda item

kerry: go through the BP document in our next telco

phila: should we meet in Washington D.C. at the next OGC meeting

kerry: we can make a poll to decide if we go to this OGC meeting or to the AC meeting in Boston

Linda: another possibility is to host it in the Netherlands

LarsG: netherlands sounds very good

BartvanLeeuwen: who is from the US in the working group?

phila: Josh Liebermann

BartvanLeeuwen: Dublin is the next OGC meeting in June
... is June too late?

jtandy: we need to think about timescales?

eparsons: we need to think what we do first?

kerry: time seems easiest, then SSN and the coverage will be the hardest
... but we could do Time and SSN simultaneously

phila: the chinese crowd may want to participate in the coverage part

eparsons: bill roberts would be the editor for the coverage deliverable

jtandy: maik reichardt and jon blower from reading university are also interested in the coverage work
... Australian geoscience data cube is another interesting thing

eparsons: we can't handle four things simultaneously

phila: other groups do that by alternating the topics in the weekly phone calls
... in order to get the extension next year we need a lot more to be done by end of next year

ahaller2: I don't think that there will be much overlap in terms of people interested between SSN and time, apart from probably Simon

jtandy: we also need the input from the SSN working group for the BP
... I would not mind to start both in the next couple of weeks

eparsons: if we only do the BP every three weeks, do we get enough feedback in the weekly meetings

jtandy: weekly meetings should be a report card

kerry: what if we do half BP every meeting and the other half either SSN or Time

jtandy: in the weekly meetings we propose resolution

eparsons: so how comfortable are we with coverage
... to start when next year?
... we are kick-starting Time and SSN in the next couple of weeks

kerry: next week is all about updating group about this meeting
... the week after is then BP and kick start Time
... and the week after BP and SSN kick start

Linda: are we not talking about UCR anymore in the weekly meetings?

kerry: i am happy to pause on the UCR

eparsons: can we have a call next week between the UCR and the BP editors

phila: timeline for first working draft of BP?

jtandy: end of november

phila: we need a static version for the OGC
... 21st of december to 2nd of January we can not publish
... latest date for us is 17th december, need to have a static version of the document on the 18th of November

jtandy: not going to happen
... why can't we put it up on the W3C site in early december, and then do the OGC process

ahaller2: can't we have a version that we consider stable as a working draft and hand it over to the OGC and then continue on in the group

jtandy: they do not have the concept of an interim draft
... i believe we can get to a reasonable editors draft by the end of november (and I mean end!)
... we may miss the W3C deadline for publishing before december

kerry: first week in december will be the phone call when we resolve that

jtandy: i don't mind the 2nd of december

phila: why not have a stable version before Christmas

kerry: let's aim for the 9th of December

eparsons: approximately 30 days from the 9th will be the publishing deadline

kerry: so we are looking at the 12nd of January for the publication date

eparsons: back to the F2F

Linda: we can host any time

eparsons: 8-10th of February

<Linda> ACTION: Linda to find out if we can host a meeting 8-9-10 february in the Netherlands. [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action08]

<trackbot> Created ACTION-90 - Find out if we can host a meeting 8-9-10 february in the netherlands. [on Linda van den Brink - due 2015-11-03].

<scribe> ACTION: phila to send an email to OGC to fix the Thursday publishing deadline issue [recorded in http://www.w3.org/2015/10/26-sdw-minutes.html#action09]

<trackbot> Created ACTION-91 - Send an email to ogc to fix the thursday publishing deadline issue [on Phil Archer - due 2015-11-03].

LarsG: does it matter for the W3C if the comments are on the BP doc in github or published version

phila: it would be better it is an immutable version

next agenda item

jtandy: discussing the two potential approaches in Bill Roberts email on ease of publishing versus machine readability

- DRAFT -

Spatial Data on the Web Working Group Teleconference

26 Oct 2015

Attendees

Contents

Notes from yesterday

Identifiers

publishing with clear semantics

Formalizing relation between SDW-WG and DWBP-WG

SVG Presentation

SVG and CRS

"enabling discovery"

enabling discovery: discovery of datasets and the features/attributes they contain

enabling discovery: summary records (metadata) - spearate metadata records?

enabling discovery: where do i discover what is available for use based on current context (space and time)?

Summary of Action Items

Scribe.perl diagnostic output