[OSGeo-Standards] [Board] glossary discussion on osgeo-standards ....

[Cameron Shorter]

Rob, Reese, all,
I'm keen to see us focusing on quick wins first, an ensuring we have a 
simple and sustainable process that anyone within the OSGeo community 
can easily engage with.

0. Current state is that ~ half of the OSGeo projects have HTML 
glossaries, without any fixed guidelines or consistency between them.

1. Initial proposal from one of our tech writers (Felicity) was to 
aggregate into a master glossary. That would be easy, valuable, and 
could easily be linked into the existing OSGeoLive annual build process.

2. The next step which I'm hoping Reese and Ron can champion is to add a 
light approval process to this, which helps standardise terminology 
used. Ron and Reese have provided excellent recommendations in this 
regard. I think it can be light weight and sustainable with volunteer 
effort with existing tools proposed. THIS WOULD BE HUGELY VALUABLE AS 
IS. I think it should be the first milestone we aim for.

3. OSGeo terminology can be sourced from OGC and ISO terminology, and a 
process can be introduced to mature OSGeo terminology into OGC/ISO lexicon.

4. Rob has suggested taking this further, which I'm okay with if 
resources can be found, but I think it we should bed down step 2 first 
and focus on building a light weight and sustainable OSGeo Lexicon 
community.

On 24/10/19 5:21 pm, Rob Atkinson wrote:
> 
> Thanks Reese
> 
> very happy to give this group and ISO as much support as possible on 
> behalf of OGC. I've linked Gobe Hobona, Ingo Simonis and Martin Klopfer 
> into this loop as stakeholders in the OGC/ISO discussion (and my time 
> allocation).
> 
> Its been a while since I gave feedback on the ISO glossary I was asked 
> to review.
> 
> The key issue was that the same concept was given different URIs for 
> different language versions, and no relations between these alternatives 
> were present - whereas I recommended using the inbuilt RDF capability of 
> tagging different labels with the language - (and using things like SKOS 
> altLabel semantics if there are non-preferred versions of labels)
> 
> The second issue if the content is in good shape is the governance 
> arrangement and status OGC hosted content would have - expectation is 
> we'd want objects to have ISO namespace..
> 
> The third issue will be making ISO namespaces resolve so OGC machinery 
> can serve out all the different views of definitions - we want to 
> support applications accessing via JSON or RDF - with the HTML view 
> being a secondary consideration. (working with this group to improve 
> HTML views by understanding requirements for these is a valuable 
> opportunity for us)
> 
> In terms of capabilities:
> 
> I will be preparing an update for documentation for OGC infrastructure - 
> at the moment I'm updating it to support the W3C specification for 
> functional behaviour (how to find and ask for available flavours - aka 
> profiles).
> 
> Part of this will include documentation of the available profiles (and 
> feedback from groups such as this as to any useful additions 
> improvements to these).
> 
> The options for data management are varied - we are still working 
> through optimal patterns - in general most content is batched managed as 
> a result of it coming through a specification pipeline - but we have a 
> full open source CMS option (django) we could use for managing content - 
> mainly we just use it to register git controlled resources.  We support 
> SKOS standard - but have created some scripts for common forms such as 
> GML dictionaries, and accessing APIs into other parts of the OGC 
> infrastructure.
> 
> So, at this stage I would suggest we are not resourced well enough to 
> support a full term-by-term submission and registration process via good 
> enough UI - and other options should be considered for collaborative 
> editing and registration (including updating the open source modules we 
> use to support your desired workflows). If, for example,  the GeoLexia 
> offering can be extended to interoperate with the canonical content via 
> OGC Definitions Server then that fits in with OGC  focus on 
> interoperability of the published content and publishing static content 
> on behalf of its community (including liaisons as required)
> 
> 
> 
> Rob Atkinson <ratkinson at ogc.org <mailto:kstegemoller at ogc.org>>
> Senior Research Engineer
> Open Geospatial Consortium (OGC)
> http://www.opengeospatial.org/
> 
> The OGC: Making location count.
> 

-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254