<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi,<br>
<br>
CKAN has been using pycsw (OSGeo project) and OWSLib (OSGeo
Community Project)for many years now.<br>
<br>
On 10/25/19 6:48 AM, Rob Atkinson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAByWqWO-7t=WftAgDz9i5SUn8w9fvg7qMusAiHRchCWZpy+DXQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">question for the list - Are you aware of any interest or overlap between
OsGeo and CKAN?
this is oldish: <a class="moz-txt-link-freetext" href="https://wiki.osgeo.org/wiki/Location_in_CKAN">https://wiki.osgeo.org/wiki/Location_in_CKAN</a>
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] <a class="moz-txt-link-freetext" href="https://www.w3.org/TR/dx-prof-conneg/">https://www.w3.org/TR/dx-prof-conneg/</a>
Rob Atkinson <<a class="moz-txt-link-abbreviated" href="mailto:ratkinson@ogc.org">ratkinson@ogc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:kstegemoller@ogc.org"><kstegemoller@ogc.org></a>>
Senior Research Engineer
Open Geospatial Consortium (OGC)
<a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/">http://www.opengeospatial.org/</a>
The OGC: Making location count.
On Fri, Oct 25, 2019 at 11:49 AM Rob Atkinson <a class="moz-txt-link-rfc2396E" href="mailto:ratkinson@ogc.org"><ratkinson@ogc.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Inline...
Rob Atkinson <<a class="moz-txt-link-abbreviated" href="mailto:ratkinson@ogc.org">ratkinson@ogc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:kstegemoller@ogc.org"><kstegemoller@ogc.org></a>>
Senior Research Engineer
Open Geospatial Consortium (OGC)
<a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/">http://www.opengeospatial.org/</a>
The OGC: Making location count.
On Fri, Oct 25, 2019 at 8:50 AM Cameron Shorter <a class="moz-txt-link-rfc2396E" href="mailto:cameron.shorter@gmail.com"><cameron.shorter@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Rob, Reese, all,
I'm keen to see us focusing on quick wins first,\
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
always an imperative
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">an ensuring we have a
simple and sustainable process
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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...
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">that anyone within the OSGeo community
can easily engage with.
this is the right focus - making the engagement simple - and let the
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">solution fall out the best way possible.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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 : <a class="moz-txt-link-freetext" href="http://www.opengis.net/def/dataType">http://www.opengis.net/def/dataType</a>
Collection View: <a class="moz-txt-link-freetext" href="http://www.opengis.net/def/dataType/">http://www.opengis.net/def/dataType/</a>
Sub-collection: <a class="moz-txt-link-freetext" href="http://www.opengis.net/def/dataType/IETF-RFC-4646/">http://www.opengis.net/def/dataType/IETF-RFC-4646/</a>
(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 :-) )
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">4. Rob has suggested taking this further,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.. )
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">which I'm okay with if
resources can be found,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">alternatives
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">were present - whereas I recommended using the inbuilt RDF capability
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">of
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">tagging different labels with the language - (and using things like
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">SKOS
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">-
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">as
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">-
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">good
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 <<a class="moz-txt-link-abbreviated" href="mailto:ratkinson@ogc.org">ratkinson@ogc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:kstegemoller@ogc.org"><mailto:kstegemoller@ogc.org></a>>
Senior Research Engineer
Open Geospatial Consortium (OGC)
<a class="moz-txt-link-freetext" href="http://www.opengeospatial.org/">http://www.opengeospatial.org/</a>
The OGC: Making location count.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Standards mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Standards@lists.osgeo.org">Standards@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/standards">https://lists.osgeo.org/mailman/listinfo/standards</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
<a class="moz-txt-link-freetext" href="http://users.ntua.gr/tzotsos">http://users.ntua.gr/tzotsos</a></pre>
</body>
</html>