Closed KathiSchleidt closed 9 months ago
ghobona
commented
2 years ago @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
commented
2 years ago @ghobona apologies for having missed that bit. However, throws up several further questions:
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
commented
2 years ago 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
commented
2 years ago 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 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
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago +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
commented
2 years ago We now have contributions towards 'a definitive list of concepts/types', namely the list mentioned in the OGC-NA Charter (https://github.com/opengeospatial/NamingAuthority/issues/142#issue-1021060499) and some 'different types of information' as well as 'Content types' (https://github.com/opengeospatial/NamingAuthority/issues/142#issuecomment-939652527). 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
commented
2 years ago @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
commented
2 years ago 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
commented
9 months ago Closing this issue because it has been answered by:
https://github.com/opengeospatial/NamingAuthority/issues/142#issuecomment-938671885
https://github.com/opengeospatial/NamingAuthority/issues/142#issuecomment-941054390
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:
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???