<div dir="ltr"><div><br></div><div><div>question for the list - Are you aware of any interest or overlap between OsGeo and CKAN?</div><div><br></div><div>this is oldish: <a href="https://wiki.osgeo.org/wiki/Location_in_CKAN">https://wiki.osgeo.org/wiki/Location_in_CKAN</a></div><div><br></div><div>lots of mentions of CKAN and OsGeo in the community - but not much clarity of whether there is a formal link?</div><div></div></div><div><br></div><div>CKAN profiles reference controlled vocabularies -
(AFAIK these are informal condigurations at this point - but they should be identified and shared and interopeable)
and linking CKAN to your OsGEeo lexicon concept seem relevant to consider. My colleague (from my other job) Nick Car has been working on CKAN implementation of "Content Negotiation by Profile" [1] and may be able to get some time to look at standardising and implementing interoperable access to vocabularies.</div><div><br></div><div>[1] <a href="https://www.w3.org/TR/dx-prof-conneg/">https://www.w3.org/TR/dx-prof-conneg/</a></div><div><br></div><div></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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 11:49 AM Rob Atkinson <<a href="mailto:ratkinson@ogc.org">ratkinson@ogc.org</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"><div dir="ltr"><div dir="ltr">Inline...<div><br></div><div><br><div><div><div dir="ltr"><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" target="_blank">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" target="_blank">http://www.opengis.net/def/dataType</a><br></div><div>Collection View: <a href="http://www.opengis.net/def/dataType/" target="_blank">http://www.opengis.net/def/dataType/</a><br></div><div>Sub-collection: <a href="http://www.opengis.net/def/dataType/IETF-RFC-4646/" target="_blank">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>
</blockquote></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>