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

Thu Oct 24 20:48:32 PDT 2019

question for the list - Are you aware of any interest or overlap between
OsGeo and CKAN?

this is oldish: https://wiki.osgeo.org/wiki/Location_in_CKAN

lots of mentions of CKAN and OsGeo in the community - but not much clarity
of whether there is a formal link?

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.

[1]  https://www.w3.org/TR/dx-prof-conneg/

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 11:49 AM Rob Atkinson <ratkinson at ogc.org> wrote:

> 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/3d65c39f/attachment.html>