Spatial Data on the Web IG F2F - Day 1/2
06 June 2018
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
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
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
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
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
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.
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.
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
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
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