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

Fri Oct 25 04:12:13 PDT 2019

Hi,

CKAN has been using pycsw (OSGeo project) and OWSLib (OSGeo Community 
Project)for many years now.

On 10/25/19 6:48 AM, Rob Atkinson wrote:
> 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
>>>
>
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/standards

-- 
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20191025/86453cf2/attachment-0001.html>