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

[Rob Atkinson]

Inline...


Rob Atkinson <ratkinson at ogc.org <kstegemoller at ogc.org>>
Senior Research Engineer
Open Geospatial Consortium (OGC)
http://www.opengeospatial.org/

The OGC: Making location count.


On Fri, Oct 25, 2019 at 8:50 AM Cameron Shorter <cameron.shorter at gmail.com>
wrote:

> Rob, Reese, all,
> I'm keen to see us focusing on quick wins first,\


always an imperative


> an ensuring we have a
> simple and sustainable process


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...



> that anyone within the OSGeo community
> can easily engage with.
>
> this is the right focus - making the engagement simple - and let the
solution fall out the best way possible.


> 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.
>
> 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.
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.

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.

eg.

ConceptScheme : http://www.opengis.net/def/dataType
Collection View: http://www.opengis.net/def/dataType/
Sub-collection: http://www.opengis.net/def/dataType/IETF-RFC-4646/

(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 :-)  )





> 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.


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.


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.
>
> 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.


> 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,


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.. )



> which I'm okay with if
> resources can be found,


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.

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.


> 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
>

-- 
*Location Powers: Data Science* 
<http://www.locationpowers.net/events/1911california/>
Be part of a 
discussion on how the core methods of data science can provide valuable 
insights when used with geospatial information.
13th & 14th November, 2019 
| Google Crittenden Campus, Mountain View, CA | #LP_DS 
<https://twitter.com/hashtag/LP_DS>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20191025/56c5c7f0/attachment-0001.html>