Meeting minutes
Intros
Jeremy: anything besides the agenda?
Linda: expecting Responsible Use of Spatial Data publication soon
Range-14 / HTTP redirect discussion
Josh: want to discuss what Range-14 means in reality, adapt for disaster pilot and keeping public informed through search engines
[Josh presenting]
@@slides
Josh: HTTP request takes information representation/resource
… you can receive a 303 redirect and response that it isn't the physical resource but description
… since it is not an actual representation of the physical resource
… there are a number of problems with that. this solution is a hack, compromise that seems to have been struck by Tim Berners-Lee to end a debate
… this 303 redirect is used in many places, if you are doing an 'other' what are you doing an other to
[(S)ELFIE and Navigation resources]
Josh: GLN number and registered resources act as a switchboard, needs to be maintained including defining types of relations to the physical resource
… why do this? why not just use the navigation resource uri?
… what is the definition of a thing? an asset of the physical world could have state, description or other attributes
… typically people look up a name for a resource but that can be ambiguous or not link to the thing itself
… OGC disaster pilot 2021 is creating an ecosystem about location and occurrence of disasters, impacts etc
… goal is to make information available to public in a timely manner
… unique identifier for a feature is required
[Feeding the search engines]
Josh: you want top ranked resource available with pertinent and authoritative information
[JSON-LD structured data example]
Josh: I know what a given page is about from the JSON-LD and can put details in search results themselves
RobA: there are basically two questions
@@slides2
[Rob presents]
"Are we talking about the same thing?" and "or is this just a representation?"
RobA: depends if there is actual connectivity, what information is exposed
… there are a few things happening under the hood, do we proxy or redirect?
… what does a context document describe using JSON-LD, what does it look like in OWL?
… all of that can be handled by content negotiation or profile using mime types
[Ted thinks we need context negotiation]
Josh: HTTP 303 - best of a bad bunch of options
… reality is there can be a bunch of different resources about a thing
… any API will need canonical view capabilities
… beauty of the W3C approach is it is possible to have a URI have information about what it means
… support easy on client, complexity on server
… server might want to promote a format
… onus should be on the server
… anybody can say anything about an object
… an open challenge is after you redirect, you don't have the original uri. typically not kept by browser
… we need to discourage clients from storing unstable links
[caching directives?]
Jeremy: I want to focus discussion on what we need to work on
… is there interest in pushing this forward, what should we do and what is the proper venue?
… Josh was in favor of a switchboard resource, I heard registration of resources
… content negotiation another pie of the pie
Bill: my immediate feel is this is a can of worms, that we may spend considerable time without making a meaningful difference
… does a new HTTP status code help... how do we help clients understand machine readable data?
… there are few clients capable of processing more complex content types
… we could have a schema.org predicate that would let search engines better understand the resource
… there are likely other mechanisms to do so
… I would start with trying to leverage existing mechanisms
Rob: I agree we should not implement something new unless we have to
… similarly skeptical about a new status code
… hypothesis is do we need to do anything at all?
… it might be useful to systematically test that hypothesis, see if there are circumstances we can do something better
<jtandy> * yep
Rob: you can embed equivalent meaning. an ad-hoc resources page may be more useful than a canonical version
Jeremy: we are just at the starting point of a useful discussion but have time constraints
… what I propose is we capture information from Rob and Josh and steer conversation to github
<billroberts> thanks Rob - I'll try to formulate my thoughts more coherently and discuss further outside of the meeting
<billroberts> on a GH issue sounds like a good option
Geofencing
<ScottSimmons> https://
Scott: at OGC we have looked at ANSI effort around geofencing
… there is a collaborative around it. we have lots of experiences around geofences
… we look at these geofences from different perspectives: what is its function, how do you define it and what do you do when you encounter one
… re 1 they are usually inclusionary or exclusionary
… example could be ankle monitors for conditioned release (awaiting trial)
… no fly zones... etc
… re 2 representations can be complicated and three dimensional
… you can have radius around a point, polygons, corridors
… geofence around Kennedy space center differs when they are preparing for a launch
… temporal extents matter
… fence could be following a moving object
… it gets really complicated quickly
… last aspect we have been considering is the behavior: what happens when you encounter the fence? what can you do or are other actions necessary
… could be a command an control issue
… or merely noting entry or exit
… one is line of sight for drones - how do you describe that in an operational fence with various obstructions (eg trees)
… conclusion we've come to with ANSI to date is we have appropriate suite of standards and knowledge, what we lack is ways to have relatively simple set of rules for behavior
… this is centered more on aircraft
ted: from automotive context a geofence concept is useful
… there are privacy considerations
… would be helpful to share insights
… some people in auto group are doing geofences
https://
ted: prototyping, moving into production, using an open source library
… polygons, circles are easy to represent
… have behaviour rules based on use cases, agree with Scott that would be useful to represent
… ideally, keep it simple (polygon, circle)
… a lot of fences will follow geographic boundaries, rivers etc.
Peter: idea of a geofence is a specialization of simple features model in the keeping it simple vein
… we are doing so in Maps4HTML
… web has no native method for representing them
Christine: we have done lots of use cases in AR with geofencing examples
… echo what Scott said, more important of what happens when you encounter a fence than the representation of it
… the user is typically alerted, secondary to authoritative entity when appropriate
Jeremy: this sounds like a great topic for Spatial Data on the Web Best Practices and developing a mechanism for connecting behavioural elements to the definition of the geofence
Clara: need to figure out where to include in the document, seems like a mature, substantive topic than identifying a gap
Maps4HTML
Peter: I can defer due to time constraint until next month
Best Practices update
Clara: we have had a couple of meetings, they have come up with some good suggestions. main thing is making the content more accessible, examples easier to understand
… we want to include ethics, drawing from Ed's work. interest in updating API section
… we are looking for update from Chris on CRS ontologies, understanding how mature they are
… there are specific examples to update around JSON-LD, schema.org etc
… we are looking at what to get from implementation reports
<jtandy> * will do ted
<roba> will do - send slides and send notes re FAIR to Clara
Jeremy: when is your next meeting so you can plug it?
Clara: start of next week, will share with the group
Jeremy: you looking for more help?
Clara: welcome more participants and we will also be reaching out for specific expertise
Jeremy: please share any notes with the mailing list
Jeremy: thanks all, sorry for the crunch. these are meant as conversation starters, please look to mailing list and github issues
https://
Linda: I see Responsible use of Spatial Data note has been updated
… congratulations to the editors