<div dir="ltr"><div dir="ltr">Inline...<div><br></div><div><br><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136)">Rob Atkinson <</span><a href="mailto:kstegemoller@ogc.org" style="color:rgb(17,85,204)" target="_blank">ratkinson@ogc.org</a><span style="color:rgb(136,136,136)">></span><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">Senior Research Engineer</span><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">Open Geospatial Consortium (OGC)</span><br style="color:rgb(136,136,136)"><a href="http://www.opengeospatial.org/" rel="noreferrer" style="color:rgb(17,85,204)" target="_blank">http://www.opengeospatial.org/</a><br style="color:rgb(136,136,136)"><br style="color:rgb(136,136,136)"><span style="color:rgb(136,136,136)">The OGC: Making location count.</span><br></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 8:50 AM Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com">cameron.shorter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Rob, Reese, all,<br>
I'm keen to see us focusing on quick wins first,\</blockquote><div><br></div><div>always an imperative</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> an ensuring we have a <br>
simple and sustainable process </blockquote><div><br></div><div>simple and sustainable are likely to be a source of tension... think Java dependencies - maven makes it sustainable because it does not force oversimplification - the cost is you have to invest in the machinery to keep simple pieces working smoothly together. (and any Java old-timers will know how painful it was when we had the "simple" solution of a few mega-libraries that changed every-single-freaking-day...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">that anyone within the OSGeo community <br>
can easily engage with.<br>
<br></blockquote><div>this is the right focus - making the engagement simple - and let the solution fall out the best way possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
0. Current state is that ~ half of the OSGeo projects have HTML <br>
glossaries, without any fixed guidelines or consistency between them.<br>
<br>
1. Initial proposal from one of our tech writers (Felicity) was to <br>
aggregate into a master glossary. That would be easy, valuable, and <br>
could easily be linked into the existing OSGeoLive annual build process.<br>
<br></blockquote><div>this is critical - the aggregation needs to be a modular and disciplined approach that allows updates to be automated. If you get this wrong now then "sustainable" becomes a pipe dream.</div><div>OGC manages this by "graphs" - each set of concepts is scoped in a ConceptScheme (what it is) that is treated as a Register (how it is managed) and has a Namespace (how it is accessed and concept identifiers are turned into URIs to access it). Graphs are also the unit by which sets of terms can be packaged - so for example getting the set of available status codes.</div><div><br></div><div>Each ConceptScheme has two related things - the metadata of the thing and the "collection" view - which is a hierarchical view of the contents bundled into Collections. </div><div><br></div><div>eg.</div><div><br></div><div>ConceptScheme : <a href="http://www.opengis.net/def/dataType">http://www.opengis.net/def/dataType</a><br></div><div>Collection View: <a href="http://www.opengis.net/def/dataType/">http://www.opengis.net/def/dataType/</a><br></div><div>Sub-collection: <a href="http://www.opengis.net/def/dataType/IETF-RFC-4646/">http://www.opengis.net/def/dataType/IETF-RFC-4646/</a></div><div><br></div><div>(ps this example shows a number of the things we need to improve in the UI and content - decent descriptions of all these top-level registers, seamless handling of sameAs relationships, better handling of nested properties and labels. If anyone has a student or intern wanting a Java Velocity project let me know :-) )</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. The next step which I'm hoping Reese and Ron can champion is to add a <br>
light approval process to this, which helps standardise terminology <br>
used.</blockquote><div><br></div><div>start with sets - registers - then a means to delegate individual term approvals to designated and documented set owners. Give me the set of metadata you want to have for each register and I will create a standard profile description for that metadata set, (including SHACL validation specification) and turn it into an interoperable RDF form (and derived JSON-LD form) I can host examples on OGC defs server dev environment - and look to update OGC metadata to follow this profile too - its on my todo list but great to have your needs folded into a solution.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Ron and Reese have provided excellent recommendations in this <br>
regard. I think it can be light weight and sustainable with volunteer <br>
effort with existing tools proposed. THIS WOULD BE HUGELY VALUABLE AS <br>
IS. I think it should be the first milestone we aim for.<br>
<br></blockquote><div>If it includes delegation to be sustainable - I would agree. (not delegation can be "virtual" the same people can act as Register Manager - but ownership of each set should be clear - and used to identify appropriate update policies.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. OSGeo terminology can be sourced from OGC and ISO terminology, and a <br>
process can be introduced to mature OSGeo terminology into OGC/ISO lexicon.<br>
<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. Rob has suggested taking this further,</blockquote><div><br></div><div>Not really further - I believe I am suggesting how not to fail before you start :-) The world is littered with random collections (trust me: I've looked into the Gazetteer problem which is a mess of "simple" point solutions - when it comes to UN disaster response it was estimated to add about three days to response times in emergencies.. )</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> which I'm okay with if <br>
resources can be found,</blockquote><div><br></div><div>I dont think what I'm suggesting takes any extra resources (if a technical solution is proposed that can't be made to manage content in separately and simply updateable subsets you need to walk away slowly , maintaining eye contact... ). I am able to fine tune OGC content and API interfaces to support your needs, and help with any design.</div><div><br></div><div>Note - i am not pushing a tech - but I am pushing for open and interoperable interfaces so such a lexicon can be integrated into any client software that needs it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> but I think it we should bed down step 2 first <br>
and focus on building a light weight and sustainable OSGeo Lexicon <br>
community.<br>
<br>
On 24/10/19 5:21 pm, Rob Atkinson wrote:<br>
> <br>
> Thanks Reese<br>
> <br>
> very happy to give this group and ISO as much support as possible on <br>
> behalf of OGC. I've linked Gobe Hobona, Ingo Simonis and Martin Klopfer <br>
> into this loop as stakeholders in the OGC/ISO discussion (and my time <br>
> allocation).<br>
> <br>
> Its been a while since I gave feedback on the ISO glossary I was asked <br>
> to review.<br>
> <br>
> The key issue was that the same concept was given different URIs for <br>
> different language versions, and no relations between these alternatives <br>
> were present - whereas I recommended using the inbuilt RDF capability of <br>
> tagging different labels with the language - (and using things like SKOS <br>
> altLabel semantics if there are non-preferred versions of labels)<br>
> <br>
> The second issue if the content is in good shape is the governance <br>
> arrangement and status OGC hosted content would have - expectation is <br>
> we'd want objects to have ISO namespace..<br>
> <br>
> The third issue will be making ISO namespaces resolve so OGC machinery <br>
> can serve out all the different views of definitions - we want to <br>
> support applications accessing via JSON or RDF - with the HTML view <br>
> being a secondary consideration. (working with this group to improve <br>
> HTML views by understanding requirements for these is a valuable <br>
> opportunity for us)<br>
> <br>
> In terms of capabilities:<br>
> <br>
> I will be preparing an update for documentation for OGC infrastructure - <br>
> at the moment I'm updating it to support the W3C specification for <br>
> functional behaviour (how to find and ask for available flavours - aka <br>
> profiles).<br>
> <br>
> Part of this will include documentation of the available profiles (and <br>
> feedback from groups such as this as to any useful additions <br>
> improvements to these).<br>
> <br>
> The options for data management are varied - we are still working <br>
> through optimal patterns - in general most content is batched managed as <br>
> a result of it coming through a specification pipeline - but we have a <br>
> full open source CMS option (django) we could use for managing content - <br>
> mainly we just use it to register git controlled resources. We support <br>
> SKOS standard - but have created some scripts for common forms such as <br>
> GML dictionaries, and accessing APIs into other parts of the OGC <br>
> infrastructure.<br>
> <br>
> So, at this stage I would suggest we are not resourced well enough to <br>
> support a full term-by-term submission and registration process via good <br>
> enough UI - and other options should be considered for collaborative <br>
> editing and registration (including updating the open source modules we <br>
> use to support your desired workflows). If, for example, the GeoLexia <br>
> offering can be extended to interoperate with the canonical content via <br>
> OGC Definitions Server then that fits in with OGC focus on <br>
> interoperability of the published content and publishing static content <br>
> on behalf of its community (including liaisons as required)<br>
> <br>
> <br>
> <br>
> Rob Atkinson <<a href="mailto:ratkinson@ogc.org" target="_blank">ratkinson@ogc.org</a> <mailto:<a href="mailto:kstegemoller@ogc.org" target="_blank">kstegemoller@ogc.org</a>>><br>
> Senior Research Engineer<br>
> Open Geospatial Consortium (OGC)<br>
> <a href="http://www.opengeospatial.org/" rel="noreferrer" target="_blank">http://www.opengeospatial.org/</a><br>
> <br>
> The OGC: Making location count.<br>
> <br>
<br>
-- <br>
Cameron Shorter<br>
Technology Demystifier<br>
Open Technologies and Geospatial Consultant<br>
<br>
M +61 (0) 419 142 254<br>
</blockquote></div></div>
<br>
<div style="color:rgb(34,34,34);font-size:small;background-color:rgb(255,255,255)"><a href="http://www.locationpowers.net/events/1911california/" style="color:rgb(17,85,204)" target="_blank"><i>Location Powers: Data Science</i></a><br>Be part of a discussion on how the core methods of data science can provide valuable insights when used with geospatial information.</div><div style="color:rgb(34,34,34);font-size:small;background-color:rgb(255,255,255)">13th & 14th November, 2019 | Google Crittenden Campus, Mountain View, CA | <a href="https://twitter.com/hashtag/LP_DS" style="color:rgb(17,85,204)" target="_blank">#LP_DS</a></div>