Def Server Process: What Concepts?

[KathiSchleidt]

Continuing on from #138 -

Is there a definitive list of concepts/types that can be provided via the OGC Def Server? @ghobona pointed to Section 5.4 of the OGC-NA Charter, provides us with the following list:

• Documents: OGC publications such as standards, engineering reports and best practice documents. These will be registered by OGC staff during the publication process.
• Namespaces: A collection of uniquely-assigned identifiers [11].
• Controlled lists: A list of terms used to control terminology [2]. This may include codelists.
• Authority files: A set of established names or headings and cross-references to the preferred form from variant or alternate forms [2].
• Ontologies: A formal specification of concrete or abstract things, and the relationships among them, in a prescribed domain of knowledge (based on the definition in ISO/IEC 19763-1:2015 [4])
• Alphanumeric classification schemes: Controlled codes (letters or numbers, or both letters and numbers) that represent concepts or headings [2].
• Thesauri: A controlled and structured vocabulary in which concepts are represented by terms, organized so that relationships between concepts are made explicit, and preferred terms are accompanied by lead-in entries for synonyms or quasi-synonyms (based on the ISO definition in ISO 25964-1:2011[5])
• Normative elements in OGC standards, according to the provisions of the OGC modular specification policy and the associated name type specification [10].

Seems clear, but when we go on to the next step of understanding what technical artifact do we use to submit those definitions this clarity gets a bit lost. @ghobona has provide the following pointer: Section 7.2 of the OGC-NA Procedures policy describes how to submit proposals to the OGC-NA. Here proposers should select a resource type from http://www.opengis.net/def/type, in turn an empty list :(

Also, in the OGC-NA Procedures policy, there is no statement of the form in which the desired content is to be provided. In #138 there are then some statements that can be provided as TTL but sometimes RDF/XML. Some of the proposals we received in the past were CSV. Some of the proposals were GML Dictionaries. These should then be uploaded to GitHub, guess then we wait for a miracle to occur!

I tried to gain a bit of clarity by stepping through the O&M resources (home base), but that got me totally lost - see #140. I'll try and sort the historic confusion in that thread

Back to what (I think) we'd need: a simple but complete example for guidance in creating the necessary ingestion resources.

Ideally for each of the types supported by the def server, a simple example of the type of file (ttl, csv, fancy digital napkin!) that would best serve to ingest such a resource - any chance of getting something like this for Christmas???

[ghobona]

@KathiSchleidt Section 7.5 of the OGC-NA Definitions Policy states that "Each definition shall be described using the Simple Knowledge Organization System (SKOS) vocabulary of the World Wide Web (W3C) consortium. Other vocabularies may also be used in addition to SKOS."

Section 7.5 also includes an example of a concept represented using SKOS.

An alternative to using SKOS would be to use CSV, as shown here.

[KathiSchleidt]

@ghobona apologies for having missed that bit. However, throws up several further questions:

• based on the list of mandatory predicates for resources, does this mean that the following bits from om.ttl are historical overkill? Alternatively, is there also an example available for more structured resources?
  • rdf:type, currently linking to:
    • skos:ConceptScheme
    • skos:Collection
    • skos:Concept
  • skos:member
• naming conventions: While 6.1. OGC name schemes provides clear guidance, this unfortunately crumbles when you get to definition-type = segment-nz-nc ; a token from the register of OGC definition types1. This seems to reference http://www.opengis.net/register/ogc-na/def-type, that in turn resolves to http://www.opengis.net/def/def-type, that in turn, provides Definition | None

[ErikStubkjaer41]

As for @KathiSchleidt @dblodgett-usgs 'what technical artifact do we use', the 'Cadastre and Land Administration Thesaurus' which reflect the OGC LandInfra /InfraGML standard, was submitted in the SKOS format as an .rdf file. I use Altova XML Spy Professional (2017) for editing.

The exchanges at [/issues/41] informs

1. in @rob-metalinkage commented on Apr 6, 2020 that the .rdf file was converted to a .ttl file.
2. generally, that the available resources did not bring about the result, I intended.

As for '3. some pointer to how the technical artifacts that are required can be created' (continued from #138), I suggest the DefinitionsServer be extended with editing facilities intended for representatives of SWGs and other artifact providers. Likely, such editing has to take place in some 'sand-box environment', and checked by OGC staff before rendered as part of the DefinitionsServer content.

[rob-metalinkage]

Hi folks - first a big "shout out" for engaging - for many years we have be exploring different parts of this puzzle without a lot of user engagement, based on common sense and lack of other ready to use alternatives, so its a quite relief we are starting to see these concerns starting to generate questions!

There are quite a few different pathways - the ultimate principle is to make things as easy as possible to do this sustainably - and that means taking artefact types already well-managed by the community as a starting point. The second principle is flexibility without ad-hoc complexity - and this means grouping different types of resources and applying common behaviour/functionality by type.

So we have different types of information naturally with different starting points

• the original OGC-NA source is a minimally expressed register of URNs labelled and grouped in SKOS (but not yet adequately described or cross-referenced in the main)
• CaLaThe is an example of a community defined resource naturally expressed in SKOS/RDF
• Application Schemas are likely to come via UML-> OWL conversions
• Conceptual models may well emerge as a mixture of UML or OWL or some othert modelling paradigm
• Implementation models will be XML-schema, and more frequently JSON-schema
• Specifications will be AsciiDoc sources
• GML dictionaries for subject domains (e.g. PipelineML Codelists)

The emerging solution to this challenge is to make sure processes are repeatable and documented: group these by type in the OGC NamingAuthority github as a "register" paradigm, and post-process different data types according to emerging needs to add value through related forms, cross referencing etc. These "domains" reflect URI path patterns so that processing, cataloguing and redirection logic can all be kept in sync. More details about the processing here: https://github.com/opengeospatial/NamingAuthority/blob/master/scripts/README.md

Types supported will incrementally grow so I will add documentation here as types become supported: http://www.opengis.net/def/about/contenttypes

draft versions are here: http://defs-dev.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/about/contenttypes

All these require relevant technical skills for the type of artefact - which as we can see requires a lot of mentoring and support and doesnt scale well.

Finally - there is an alternative option we have never fully opened up which is a CMS with access control and some basic editing for SKOS content - from here we can publish to the RDF store - the near-term roadmap is to link this to the git domain based processing. Its not perfect, but has been used internally - and I use it for the About topics even though I eat, sleep and breathe RDF every day...

[KathiSchleidt]

@rob-metalinkage sorry for being confused here, how do the content types fit with the missing definition types?

And - while the page on processing is quite interesting, for those of us who don't eat, sleep and breathe RDF every day and are really just trying to get a resource online, it does get a bit confusing! ;)

I'm wondering if one shouldn't split the more experimental work on the def server from the day-to-day operational work? While I get the potential of all the cool stuff we could do, I'm get the impression that its gotten in the way of doing the more prosaic things we NEED to do!

[rob-metalinkage]

I recently commented elsewhere about the challenges of having versions in URIs. The content sources have some details here http://www.opengis.net/def/type/OGC-NA/0/def-type - so the issue is how to tie all these alternative versions together meaningfully..

rdfs:seeAlso http://www.opengis.net/def/def-type/ ;
rdfs:seeAlso http://www.opengis.net/doc/def-names-1 ;
rdfs:seeAlso http://www.opengis.net/doc/ogc-na-policies ;
owl:sameAs http://www.opengis.net/def/type/ogc-na/0/def-type ;
skos:altLabel "Definition type"@en ;

I'll have to do some digging here to find out what these actually mean in relation to each other and work with Gobe to update a definitive list and put more useful links in place.

[KathiSchleidt]

+1 on versions! While I keep hearing statements on how we don't need them, just seeing the current mess under O&M concepts proves to me that we do (otherwise we can never deprecate them!)

and +10^n on creating a definitive (non-empty) list!

[ErikStubkjaer41]

We now have contributions towards 'a definitive list of concepts/types', namely the list mentioned in the OGC-NA Charter (#142 (comment)) and some 'different types of information' as well as 'Content types' (#142 (comment)). I note also 'Current OGC document types' (http://www.opengis.net/def/doc-type) and wonder why the document type: 'OGC Standard' seems not explicitly mentioned, even in the doc-type list. After all, the about 75 OGC standards belong to the backbone of OGC, even if Abstract Specifications and Implementation Standards have occupied much attention recently. As occasional user of standards, I thought that the DefinitionsServer would provide easy access to the definitions stated in section 4 of each of the ~75 standards.

@rob-metalinkage Thanks for pointing towards 'a CMS with access control and some basic editing for SKOS content'. Your 'Content types' includes code lists. Could we take a step in that access direction by making code lists of OGC LandInfra available on the DefinitionsServer, as an OGC supplement to LandInfra (http://docs.opengeospatial.org/is/15-111r1/15-111r1.html): You provide the editing facilities and I extract data from the LandInfra standard?

[dr-shorthair]

@KathiSchleidt

seeing the current mess under O&M concepts proves to me that we do

I draw a different conclusion. We need to be able to retire or supersede definitions.
But, assuming that the successors are different, then they deserve different identifiers.

If the successors are intended to be the same - just maybe with an improved definition - then they should retain the same identifier.

Version numbers are a common pattern for 'changing the identifier' but should be used with great care. In particular, it is very unhelpful for the release number of a document, specification or standard to be used in the identifier of all subsidiary artefacts, since it then complicates their re-use in a subsequent release.

[rob-metalinkage]

NB /def-types/ is actually just a Collection to provide a starting point to other collections of vocabularies organised by "definition type" -

At the very least i shall rename it - its not a registered name so is not needed for stability.

SKOS makes the relation between Collections and ConceptSchemes a little awkward - it doesnt support heirarchies of ConceptSchemes at all - hence the superposition of hierarchies of Collections spanning multiple ConceptSchemes.

The only solution I can see is to get the UI to expose a common pattern of a top level collection per concept scheme, and to expose concept scheme metadata for top level collections so they kind of look the same in practice whilst being semantically consistent with the SKOS model.

[ghobona]

Closing this issue because it has been answered by:

#142 (comment)

#142 (comment)