text: 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>
  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)
  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 -
  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:]
  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:]
  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
  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