Spatial Data on the Web IG F2F - Day 1/2

06 June 2018

Meeting Minutes


eparsons: member of original SDWWG, here to catch up with the work of the SDWIG

ClemensPortele: member of the SDWWG, too, mostly active / interested in the Best Practice work

Percivall: OGC, supporting the work of this group

JoshLieberman: new to OGC and the group, interested in publishing datasets

tom_hunter: same as Josh

ChrisLit: member of the original SDWWG, e.g. on the Time Ontology

PeterR: working on MapML

Joseph: new to the group

MichaelGordon: also new to the group, leading the work on the Best Practices now

jtandy: co-chair of this group, editor of the published Best Practices

brinkwoman: same as jtandy

<MichaelGordon> https://‌www.w3.org/‌2017/‌sdwig/

tidoust: W3C staff supporting the group

Rob_Smith: working on WebVMT

Recap scope, activities and deliverables of SDW IG

Link to interest group homepage and deliverables

jtandy: As an introduction, let's list the deliverables of the previous SDWWG

ChrisLit: Time Ontology - now a recommendation

eparsons: Best Practice - not another standard, but guidance for publishing spatial data on the web, complements the W3C Data on the Web Best Practice

jtandy: CoverageJSON, QB4ST - still drafts, work for an expert audience, has not yet progressed to a mature state

ChrisLit: One result was that a lot of data will never be published as triples, but for metadata make use of linked data

brinkwoman: a new work item is a Best Practice on statistical data, in early status, collecting use cases

jtandy: for publishing census data, capturing approaches from around the world

jtandy: SSN - Sematic Sensor Network Ontology, a recommendation, too

eparsons: When we go through the deliverables it is important to be clear why we discuss it here and not just in OGC or just in W3C

eparsons: The key thing is that we want to make spatial data more web friendly

jtandy: In our charter we say we will work on a Geospatial roadmap. We will discuss this later, including the trends identified by OGC (but from a Web perspective)

jtandy: In addition there is the Strategy Funnel

jtandy: Operating as a joint group of W3C and OGC. We are using the W3C infrastructure and processes

jtandy: (walks through the Strategy Funnel)

<josephabhayaratna> JWOC

Working practices for the IG

jtandy: different work items, quite fragmented, but under the umbrella of the IG, difficult to make teleconferences work, also because of time zone issues. The idea now is to have "focus days" where we work on specific topics, with a quicker turnaround

jtandy: How does sound in principle?

<josephabhayaratna> +1

<Rob_Smith> Sounds good

MichaelGordon: Sounds good in principle, but we need to test it out

PeterR: In Testbed 14 we have weekly calls, but this activity does not show up in the Strategy Funnel

Percivall: Could this IG act like a DWG to connect the work of the testbed to this group?

MichaelGordon: at this stage it may be difficult because of the need for observer agreements

Percivall: There is a range of approaches in Testbed 14, including development in public

Rob_Smith: I am missing the group calls to have wider discussion and feedback. Maybe the focus days could work.

jtandy: We have the general tools to keep track (issues, etc). We are now trying to use "project" capability of GitHub.

jtandy: This can be used to document the status of an activity up-to-date

jtandy: This should also drive the work for the focus days for a project

jtandy: Leaders of an activity should update their information regularly

jtandy: How does that sound?

(nodding in the room)

<Rob_Smith> Sounds good. I'll update the summary

jtandy: We will update the information during the meeting

PROPOSAL: Use GitHub projects to manage and communicate the status of the work items of the group

<jtandy> +1

<MichaelGordon> +1

<Rob_Smith> +1

<ClemensPortele> +1

<eparsons> +1

<josephabhayaratna> +1

<brinkwoman> +1

<tidoust> +1

<Percivall> +1

<tom_hunter> +1

<PR> +1

Resolved: Use GitHub projects to manage and communicate the status of the work items of the group

jtandy: We also use Gitter for chats, not much in use so far

ClemensPortele: Should be helpful during the focus days

MichaelGordon: Will the focus days be synchronous or asynchronous?

jtandy: I would think the latter

<ChrisLit> +1

jtandy: Let's try to use Gitter for the communication in the focus days

brinkwoman: When will be the next focus days?

jtandy: The first days of each month

<ChrisLit> +1

<Rob_Smith> +1

OGC Technology Trends review

OGC Technology Trends

jtandy: Intro to technology trends - hands over to Percivall

jtandy: Things that are relevant to w3c of particular interest

Percivall: Describes diagram above...

Percivall: Leaf nodes are trends - updated frequently

Percivall: Blue blobs take you to docs hosted on github for each topic

Percivall: Trends now also github projects - 3 categories - Identification, Characterisation, Take Action

jtandy: What if trend goes away...

Percivall: They go away :-)

jtandy: Useful to have scrapyard...

<Rob_Smith> +1

Percivall: Scrapyard could explain why trend was binned

jtandy: Numbering issues identified in list - needs to be iterated linking funnel to tech trends not always leaf level

Percivall: Map projections clearly a topic that needs best practice

jtandy: Asks MichaelGordon is current SDW BP good enough ? for CRS advice

ClemensPortele: Edge cases avoided in BP

ChrisLit: Things in funnel may be mainstream, tech trends forward looking ?

Percivall: Tech trends not work items - funnel is ?

PR: Maps for html align existing web technology - not a technology trend as such...

MichaelGordon: Bringing spatial & web together - not always one to one so OK for trends and funnel not to completely overlap

jtandy: trends don't have "go to person" funnel is about work so have people associated which each topic

Percivall: Trends not taskable

Percivall: will come make with suggestions of overlaps

ClemensPortele: Trends managed by Gobe - can we contribute issues ?

ClemensPortele: Can only add comments to issues... how can we contribute other info

Percivall: Developing process on asciidocs need to update this

jtandy: Mail OGC staff to add comments until pull requests or different mechanism established

MichaelGordon: Just create issues...

ClemensPortele: Then projects don't works

Percivall: Will work on new process to update sdw branch

MichaelGordon: Trends cutting edge / emerging topics

MichaelGordon: Stats & Big Data ML also need to be linked

jtandy: asks MichaelGordon to email Gobe with these

Rob_Smith: 2 others UAVs and AR linked to WebVMT

jtandy: MichaelGordon will add these to gobe email

jtandy: How do we provide this input before TPAC in October

josephabhayaratna: Will contribute linked data stuff

jtandy: ad-hoc telcon to address this to be arranged

jtandy: After Percivall reworks current work - 1 month from now

jtandy: Percivall will arrange telcon

Action: Percivall to arrange telcon and send out details

jtandy: who would be interested?

<brinkwoman> +1

<jtandy> +1

<MichaelGordon> +1

<Percivall> +1

<tidoust> +1

<josephabhayaratna> +1

<ChrisLit> +1

<Rob_Smith> +1

<PR> +1

<jtandy> -1

<jtandy> +1

jtandy: Please read up before telcon ;-)

<jtandy> Aim for 5/6 July for the Tech Trends ad-hoc teleconf

jtandy: Short break end of Tech Trends/Funnel topic

jtandy: Resume in 20 mins

<josephabhayaratna> @jtandy: pull request created for addition of references to the SDW README.md file

Geospatial Web Roadmap

Analysis, List & group features issue

brinkwoman: Roadmap overview of work we are doing but also broader relevant stuff happening elsewhere

brinkwoman: w3c use roadmaps often

brinkwoman: example - www.w3.org/2018/01/web-roadmaps/mobile

brinkwoman: Drill down from icons to specific topics document - table of building blocks, specs etc

brinkwoman: For this roadmap browser support is important, could be relevant for us with map html

brinkwoman: Text for us and grouping with maturity info would be most useful

brinkwoman: In summary short document providing overview

brinkwoman: We need to decide on features of our roadmap, how to group features (1 or many ?)

brinkwoman: I have done a first attempt at this on github

brinkwoman: Scope geospatial, Standards, any level of maturity , beyond OGC/W3C

brinkwoman: Easy based on SDO's eg. OGC SDWWG/IG

jtandy: Discussion of SSN/SOSA level of components with Josh - constellation of items

jtandy: brinkwoman would like to separate SSN / SOSA for presentation

<tidoust> [Practically speaking, SOSA and SSN can easily be mentioned in the roadmap as two features of the same spec]

brinkwoman: would be useful to include other alignments with others

JoshLieberman: OM lite replaced by SOSA

JoshLieberman: SSN extensions ?

JoshLieberman: connected to sensorthings

jtandy: List of things - set of observations, O&M data streams aligned by collections etc

jtandy: List of work to do highlighted in project on Github Progress card

jtandy: MichaelGordon has added Data Cube, tiling etc as features

JoshLieberman: Cloud Optimised Geotiffs (COG's) could be useful

MichaelGordon: contributions in issue above

brinkwoman: Should we just list all the WxS standards ?

eparsons: Perhaps not useful if not mainstream

ChrisLit: Usecases might be useful to identify features

ChrisLit: Usecases from Stats ChrisLit to add below

JoshLieberman: move georss to OGC

jtandy: scope should be web native/friendly

JoshLieberman: http as transport vs http as interface

jtandy: http as an interface in scope, transport not in scope

jtandy: Roadmap cant point to things we will not cover

PR: But... getmap is an api , wfs will be popular because the result is JSON

PR: Should not exclude based on location of ? in url

jtandy: WPS is a better example, impossible for a web developer to use, WMS is possible, WFS 2.0 you need to understand data model..

JoshLieberman: Hard to be too prescriptive in simplicity

PR: WMS is out there part of geoweb, maps html to allow new clients for this...

JoshLieberman: Geohash's way of identifying local data

jtandy: Back to should we list all standards ??

JoshLieberman: Makes sense to give you a view to where you are coming from

brinkwoman: Did not add all - too many filtered based on relevance to web

brinkwoman: Not encoding

PR: speak up for the ones you want

jtandy: Can you explain the criteria for filtering - should we try to run the filter now ?

jtandy: For example is O&M useful to a web dev - should they not look at SOSA ?

jtandy: Criteria here was that O&M has been replaced by a web friendly feature

<ChrisLit_> sdw/stats-bp/draft-use-case-list.md points to UC for partitioning/tiling ontology. Cannot find a URL.

jtandy: IndoorGML is emerging as a web friendly feature so it would be relevant

jtandy: Not GML but will have JSON ???

JoshLieberman: Is there an excepted way to go from GML to JSON ??

jtandy: Audiences might want different products complex needs - GML for complex needs / JSON for simpler ..

<tidoust> [I note a valuable outcome of the roadmap exercise is also to list features not covered by ongoing work or not web-friendly enough, as in: http://‌w3c.github.io/‌web-roadmaps/‌media/‌processing.html#features-not-covered-by-ongoing-work]

brinkwoman: Candidate for roadmap if there are plans to simplify to make web friendly

jtandy: Let OAB know what's missing from roadmap - useful intelligence for future work of OGC TC

jtandy: will be subjective - can we get on future OAB agenda

jtandy: When can we do this ?

JoshLieberman: Early July

tidoust: Added IRC comment, outcome of roadmap is to id features not friendly enough. Should be a section of the roadmap

jtandy: Categories - Not Ready, Becoming Ready, Ready...

Rob_Smith: Comment on classification - tagging might be useful

Rob_Smith: Different reasons could be captured using the tags as part of the process

brinkwoman: Will update roadmap other input welcome - add issues to the project on github

jtandy: If we have spare time we can whiteboard ideas later

Strategy funnel update - MapML

MapML strategy issue

PR: I work at Natural Resources Canada. Created the Maps for HTML CG a few years ago. I'm very proud of the work we've been doing on standards in Canada Journey is not over. We created SDI standards to help people use maps When we share a URL to a WMS, the person that receives it must be a programmer. These days, social networks on the Web are magic when it comes to link sharing: you share, it works. There's a missing media type for maps MapML is like HTML but for maps. Doing something similar without MapML can take days [Demo of MapML mashup, copying URLs of Web maps to combine them] Map represent features of interest. The browser understands geospatial data. It knows where you are and what is around you thanks to MapML

eparsons: You're talking about an extension to HTML, right?

PR: Yes. SVG and MathML are part of HTML nowadays. In a map, you can refer to a layer through a URL or put that content directly in the map. On the one hand, it's a separate media type. On the other hand, if it's embedded in HTML, it's regular HTML.

ChrisLit_: How do you see this being adopted in HTML. Example of SVG which was modularized, and then split to CSS specs and others.

PR: With maps, you need a well-defined coordinate systems. Web Mercator is the default on the Web but some others are being used.

jtandy: What I've appreciated this time around is that, what seems to be a challenge for the time being, is to be able to drag a map source into another map, and for the browser to figure out that this is not another page, but a map.

PR: Yes. You want to be able to reuse URLs in a different context. Geospatial information is most useful in context.

JoshLieberman: Any other example of things you can drag and overlay?

PR: I'm not aware of any. The semantics of maps is layers.

JoshLieberman: The semantics of audio is tracks. What I'm saying is you may be looking at something more generic.

[Looking at MapML code, extending the <map> element, which has layers]

PR: You could overlay geometric layers on an image with a <map>.

JoshLieberman: What I'm suggesting is that it may not be unique to maps

ChrisLit_: Photos, you could view as cross-section of 3D scenes.

brinkwoman: Is there currently a browser implementing this?

PR: No, there is a Custom element, controlled by JS. Supported across browsers as proof of concept.

jtandy: The MapML that you're trying to standardize is just the content of the <map> element. You're not trying to standardize the implementation.

PR: One of the benefits of this architecture is that browsers can implement it the way they see fit.

Rob_Smith: That's a great demo, Peter. I understand it better. You need a shared data format and a Web reader. Have you broken that down in that way?

PR: Essentially, yes. The DOM specification for MapML would be part of HTML ideally. And that DOM could then be used as an "API" to control maps in libraries. [Example of changing zoom and coordinates, features need to change at the same time]

tidoust: How do we gather interest from browser providers ? Could it be that we let the browser manage the underlying map while only allowing overlays?

[Example of MapKit JS: https://‌developer.apple.com/‌documentation/‌mapkitjs]

PR: I don't like the idea of being able to impose the map provider depending on the system.

eparsons: There is space for this approach. It does not address the more advanced cases such as routing.

PR: I plan to go to the Lyon meeting to catch some browser developers.

jtandy: A breakout session on Wednesday would be a good thing. Have you tried to engage with WICG?

PR: Yes, no real feedback there.

jtandy: The point here is to be able to take URLs and being able to stack layers one of top of the others, using a coordinate system under the hood to align layers. We'll try to support you at TPAC. Co-sponsorship to get other people involved would be ideal.

Strategy funnel update - Linked Building Data

Linked Building Data strategy issue

Presentation on Linked Building Data

Presentation on Linked Building Data (short version)

jtandy: What we're trying to do here is to find stuff at OGC that might complement or overlap what you've been doing

pipauwel: Background is Building Information Modelling (BIM). Every information about each system. There's an industry standard "ifc". Not very web-friendly. There's an OWL version, but it's very very very big. And there are a few things that make it hard to use. Big impact on 3D geometries as well. Key findings is that we want to make it more modular, simple, and web-friendly. We created a CG to that effect. There's a companion WG in buildingSMART (LDWG). Both groups are very active. Split into elements that are part of a building (walls, floors, etc.) that we try to represent. Different ontologies to capture different properties. We're trying not to focus on geometry because that's complex. We have a GitHub repository, a page that describes what we're doing. Upcoming F2F Going through the current status. Goal is Web-based, decentralised, modular, simple. Building topology starts simple. From there, we go to a product ontology. Property ontologies that capture properties of the product data (heating transition values that come from vendors for instance) We try to link to Geospatial domain as well. [showing the key ontologies and relationships] Ongoing discussion to separate data properties and object properties We're trying to stabilize the different parts to be able to transition these works to a Working Group at W3C. We also make alignments, kept separately (including SSN/SOSA) [going through spec examples and Protégé example of the product ontology] Brief indication of implementations that we have. Trying to have industry-driven or user-driven examples. We have a tool to convert from IFC to LBD. Second example with Forge (viewer of Autodesk) to look at specific elements in a building We have a SPARQL visualizer app to visualize any data on building data One railway station example with underground cables. Combines with spatial information Also infrastructure as linked data to convince people to use linked data. [showing the tools] Live sensor data in the Open Smart Home Data example

jtandy: Thank you very much for the comprehensive presentation. It would be useful to add a link to this presentation to the strategy funnel issue.

<jtandy> IDBE Integrated Digital Built Environment

JoshLieberman: Subcommittee is looking at connecting OGC and buildingSMART. Includes IFC. CityGML. Probably soon PipelineGML. Haven't heard about ifcOWL in that list, but could be interesting

pipauwel: Yes, I'm aware of these groups. Converting to OWL is doable. But the result does not look like OWL. Same thing with XML. Result does not look like XML. That's the reason why we're looking at it differently.

[Josh mentions upcoming meeting of the subcommittee]

JoshLieberman: It may be that the only hope to align standards is to have something at a more general level.

jtandy: New work on serialized geometry that can be expressed as OWL. Is there something we could contribute to?

brinkwoman: Have you looked at the current version of GeoSPARQL?

pipauwel: Not sure what the latest version of GeoSPARQL is, but yes. There's also a BIMSPARQL. I like the idea. It's very detailed.

<SimonCox> @pipauwel GeoSPARQL does not convert geometry to RDF

pipauwel: We have the full semantics in IFC. Simple use cases would rather use a mesh. People in our group typically use a mesh

JoshLieberman: what about CESIUM?

pipauwel: Not familiar with it.

JoshLieberman: Would be useful to produce 3D geometries in the browser.

pipauwel: Many of the editors have their own geometry mechanisms.

<jtandy> Cesium ... see https://‌cesiumjs.org

pipauwel: The main proposal I'm putting forward in that group is to put geometry elsewhere, and focus on representing buildings semantically

[Discussion on CESIUM to render 3D models for the browser]

jtandy: Cesium 3D tiles may be the thing to look at then.

pipauwel: The idea would be to make a separate CG that tackles this. We're also coming to TPAC, so maybe something we can discuss then.

jtandy: CityGML also describes objects. We're also looking at a JSON serialization with CityJSON. There seems to be an overlap there.

JoshLieberman: It's not an overlap except for physical space. Cesium is for rendering. CityGML is for analysis.

jtandy: So, we have an action to meet at TPAC and put you in touch with OGC standardization work around Cesium 3D tiles.

Projects update - SSN extensions

SSN Extensions spec

SimonCox: Some things that we didn't get to when finishing SSN because other work took longer than expected

SimonCox: Proposal wrapped up two of the issues that were described ahead of time Semantic Web Journal last year but were publicly available two years before that

SimonCox: Two topics are the separation of the feature of interest

SimonCox: In OGC we refer to the approximate feature of interest (sample) and the ultimate feature of interest first example is when the ultimate feature of interest and the approximate feature of interest are the same second example is where there is a chain of samples

SimonCox: proposal is to add hasUltimateFetaureOfInterest

SimonCox: Steve shows that we may have multiple samples which might be related to different ultimate features of interests where tracing back using isSampleOf may not work in the specification, there are rules for how to derive the ultimate feature of interest using example SPARQL this example shows tracing back through samples only if there is no ultimate feature of interest

jtandy: Please add more detail to the project in github and use the description to provide/update highlights

SimonCox: all of the classes and properties except those in red are in the SOSA namespace except hasProperty, which relates an observable property to a feature of interest. The proposed modification is to move or reflect the hasProperty in SOSA namesapce the other topic is homogeneous collections of observations. Observations rarely occur as a singleton. The set of observations may be a time series e.g., the set of pixels in an image observations almost always occur in series observed property is held the same, but other features of interest are varied proposal is to add one class and one predicate to the ontology to allow collections.

<JoshLieberman> Can be used for timeseries, or a timeseries result could be used alternately

SimonCox: ObservationCollections can be nested

<JoshLieberman> ObservationCollection also useful for alignment with SensorThings API Datastream

SimonCox: proposed extension hasMember (property) and ObservationCollection (class) examples show tracing back through hasMember. If an observation doesn't have a feature of interest, use the feature of interest from the ObservationCollection SPARQL concepts are implemented in SPIN

<Zakim> jtandy, you wanted to ask if ObservationCollection can / should be used for timeseries?

jtandy: ObservationCollection makes it easier to store repeated information

JoshLieberman: adding ObservationCollection makes it easier to harmonise the observation model with the service

SimonCox: it's constructed axiomatically using OWL but provides a much more compact encoding

jtandy: seems coherent and well thought out. What help do you need to get to the next stage

SimonCox: needs help with SPARQL and a set of extra eyes for testing nested ObservationCollections trying to understand the relationship with data cubes not sure this can be expressed axiomatically anyone on the call that is familiar with data cubes

JoshLieberman: Rob Atkinson

jtandy: Dave Reynolds? he wrote the data cube spec, so if anyone knows its him

JoshLieberman: I'll take a look and see if I can contribute Kathi Schleidt

SimonCox: also examples. Kathi may be able to help there too

JoshLieberman: Can I add SensorThings as an exapmle

SimonCox: Sure pushing directly into the head of gh-pages

jtandy: fine for you to, but if others are making changes they should create pull requests for Simon to approve Josh to create an issue to add an example for SensorThings

SimonCox: Little unclear on what the prospects for the proposal is. Interested in what the process is moving forward to get this issued to OGC/W3C

jtandy: The IG can vote to approve a NOTE

tidoust: depends on whether you'd like to take it to a new edition of SSN in which case we'd need to charter a new working group

SimonCox: Should I hijack the existing namespace or put it into a new namespace can package it up as an ontology that simply imports SOSA, etc., but if this hasn't gone through a working group and gone through a vote for recommendation/standard, is it appropriate to make up new things in the existing namespace

jtandy: it makes sense to keep it separate

SimonCox: Understand that from a governance point of view, pain from the usability perspective Should it be an NS namespace or a data one

tidoust: NS is fine. But if there's enough support a working group would be beneficial that requires a lot more work

SimonCox: interested in other peoples opinions, but in the short term it makes sense to get the proposal out as a note to enable testing

jtandy: once people are testing it, we can demonstrate desire to move it forward. Publish it as a note with a reasonably light review

SSN Primer

jtandy: Armin said, we have received acceptance notification of our SSN paper in the SemWeb journal. This could be the basis of an SSN primer, but given the length of the paper I'm not entirely sure if it's needed?

SimonCox: The paper is not a primer. it's an overview and a more digestable overview for those that don't want to look at the REC.

jtandy: In that case, the work on the primer hasn't yet start

SSN/SOSA Ontology Amendments

SimonCox: issue 1006

jtandy: this issue is still open

SimonCox: issue 1022 has been responded to by Maxime. Still awaiting a response from the issue creator as to whether the workaround is acceptable

jtandy: will take the Time update via email

Summary of Action Items

  1. Percivall to arrange telcon and send out details

Summary of Resolutions

  1. Use GitHub projects to manage and communicate the status of the work items of the group
Minutes formatted by Bert Bos's scribe.perl version 2.41 (2018/03/23 13:13:49), a reimplementation of David Booth's scribe.perl. See CVS log.