Meeting minutes
<roba> looking for goto meeting link - my calendar entry has a cancelled link..
we're on Teams Rob
1. OGC Registers & Definition Server
brinkwoman: we will record this part of the call, any objections
[no-one objected]
Gobe Hobona: [working through a slide show] OGC naming authority manages registers of resources under www.opengis.net/def
Gobe: OGC-NA develops policies on URIs and URNs for OGC resources and manages or delegates change control, liaising with external authoritative sources
… Types of resources in the registers: documents, namespaces, controlled lists, authority files, ontologies, classification schemes, thesauri, normative elements in OGC standards
… Registration process: follows ISO 19135
… ipmlemented in github
https://
… hand over to Rob for more detail on the definitiosn server
roba: there are two main facilities for managing content: through files in github or through a content management system
<jtandy> (we haven't got the queue bot running ... suggest to raise your hand in Teams)
roba: not yet using the content management system for a lot of things, but in the early stages still doing a fair bit of manual intervention to check all the important things are available
… working on improved automation
… There is a series of git actions implemented as python scripts
… We can serialise to multiple different formats
… The process is carried out per profile and per domain
… There is a web interface to the linked data representation, with links to all the various serialisations
roba: Domains might have different kinds of things in them of varying complexity. For example specifications have to follow the ontology for specifications.
… The resources are described as SKOS concepts and this is used to drive the user interface as well as machine readable views
… You can access the original forms, intermediate forms and the final forms. So you can work in whatever form that suits you best and the system can support the other aspects automatically
… These relationships between resources and ensuring interoperability seems to be very relevant to SDW. Trying to follow the FAIR principles
jtandy: Questions?
PeterR: what's the process for adding new records into the register, versus allowing specifications to interpret the meaning of a registered item?
roba: The policy framework describes a process. That includes checking the namespace is unique and follows a naming policy. So things are not overridden thanks to the governance approach.
… could still improve on the re-use of terms. Harmonisation of terms usage across different specifications could be better. Another project together with ISO and Ausgeo is looking at this
… The definitions server should help people decide if they are talking about the same thing or not. It's an ambition to support terminology harmonisation. At the moment we are concentrating on gathering the existing content.
ChrisLit: regarding the back catalogue, many popular standards predate the mod-spec. Will it be worth handcrafting older specs to get them into this system?
roba: There will be some handcrafting, to various degrees. There are lots of relationships between specs that the mod-spec doesn't cover. But it does cover the internal relationships and that should be quite relevant for SDW
… We'll give names to conformance classes and targets for old specs. Light touch but produces useful information
brinkwoman: is the SKOS profile described somewhere we can read it?
roba: not yet committed to the github repo, but will be soon. There will be formal descriptions and SHACL rules for each profile. There is one for vocpres already. Also an owl ontology for mod-spec with a couple of flavours of SHACL description
… expect to have a register of profiles in future.
… It would be great if this group could review relevant profiles to assess their usefulness.
jtandy: The automation involved in this looks great from the perspective of a spec producer and as a spec consumer, having URLs for everything will be very useful. Thanks to Rob and Gobe.
<PeterR> Echo the thanks Jeremy expressed to OGC NA for your efforts
[recording now stopped]
Best practice for defining geofences
jtandy: https://
brinkwoman: I'm not the owner of this, just wrote it down! But to summarise: different communities have a need for geofences and for standardisation in describing them
… We think we do have standards that could be used - generally just a polygon. But we lack a way to express the rules of what can happen inside or outside the geofence
… It would be useful to add to the best practices document. Scott and Clara have taken the action to write something
jtandy: There's a new piece of work - writing up for the best practices but also to develop a way of expressing the rules
Peter Parslow: The geofence is more than just a description of the geometry. It also has the aspect of expected difference in behaviour inside or outside the fence
PeterR: I raised an issue that the web itself (HTML, javascript etc) has no need for a description of features. (A geofence would be a kind of a feature). But browsers would need to understand feature semantics to process geofences on the client side
… there is a privacy danger to server side geolocation processing, which helps motivate understanding geolocation on the client side
ScottSimmons: This would be very interesting as a Best Practice. We can talk about the geometry, but it's the semantics of the geofence that makes it interesting. A great example of why we should have spatial data on the web. I volunteer to take a first stab at writing this up. OGC has had a go at a descriptor for one kind of geofence which could be more broadly applicable
jtandy: to confirm - getting a geofence into the BPs would be useful and there is OGC work that could act as a start
roba: current best practice is pretty much at the level of 'hasGeometry' but that doesn't tell you much about what it means. Relates to the HTTP-14 kind of issue
… there probably isn't a best practice yet, but having feature types that suit the end use and the ability to publish the feature types to describe the semantics of geometry properties would be part of any solution
jtandy: so in the OGC SWIG structure there is already work going on. Can SDWWG help? Coordination role?
Scottsimmons: certainly an early review would be good. And to get input from the experts in this group on how this could work in the SDW paradigm
PeterR: Accessibility for people with disabilities could be related to geofence semantics. Could provide extra information for people with particular needs.
jtandy: Scott, please add links to the work that has already been taking place as a comment on the GH issue
HTTP Redirect - with added semantics
https://
jtandy: The issue summarises a limitation of the web in its current form. It would be good for this group to produce a note on the problem and options to solve it
roba: We see a need for this in the OGC definition server, because of the need to distinguish different views of resources
… there are various ad hoc solutions out there, but the web itself doesn't work that well for a coherent 'web of data' that has any scalability
… There is definitely a problem. Maybe not a big driver on the interoperability
bill: have been trying to tackle aspects of this data interop problem, it comes up all over the place.
… I worry there would not be a community ready to consume a structured mechanism for this
… I recognize the importance of this problem
jtandy: so the community is not mature enough for solutions that might work
bill: yes. Not saying we shouldn't do it, but something to think about
Spatial Data on the Web 2022 - where next to drive impact from geospatial data
https://
jtandy: what big challenge(s) should we focus on in the next few years?
jtandy: early explorations indicated that interoperability of data could be a key part of this, so relevant to the previous discussion
PeterR: I'd like people to focus on Maps for HTML! It would be good to address how to get geo into the web.
… there has been a lot of effort and progress on geospatial data interoperability in the last 20 years and a foothold to bring this to the masses could be very important
<ScottSimmons> +1
<PeterR> +1
<jvanulde> +1
jtandy: are we interested in trying to write a discussion paper that addresses the challenges in this github document?
… please vote with +1/-1 in IRC
+1
Christine Perey: we haven't had much discussion of visualisation, which I see as missing from this list. Not just accessible on the web but also visible to people
<roba> +1
jtandy: we'll gather thoughts on this through the mailing list. And would like a workshop on this in the December 2021 face to face OGC meeting (west coast USA)
<roba> We should be looking systematialluy at the different user perspectives on interoperability..
jtandy closes the meeting
<jtandy> * billroberts - thanks for being scribe!
<PeterR> very good meeting, too short though.
<PeterR> !
<PeterR> billroberts thanks for scribing.
<jtandy> thanks PeterR ... length of meeting is sometimes a challenge; but noted.