Publish "minimal ontologies" for GWML2, GeoSciML, and HY_Features as experimental.

[dblodgett-usgs]

The SELFIE team -- @afeliachi primarily -- created three "minimal" ontologies for the domain feature models GWML2, GeoSciML and HY_Features. See files: hyf gwml2 and gsml.

In https://github.com/opengeospatial/NamingAuthority/issues/16 and https://github.com/opengeospatial/SELFIE/issues/67 we determined the best course of action would be to publish these as experimental ontologies in the same fassion as was already done for part of the HY_Features conceptual model (e.g. https://www.opengis.net/def/appschema/hy_features/hyf/HY_CatchmentAggregate).

@rob-metalinkage pointed to the need for RDF/OWL, XMI, and xsd schema -- at this point I am only aware of .ttl representations of the RDF/OWL as created by @afeliachi.

Apologies for my naiveté here, but are these artifacts that can be created automatically and are not needed from us or is this something we need to create in addition?

One final note -- these "minimal ontologies" are feature-classes and associations from approved and published data models. In a sense they are a format conversion of existing schema and, since it is not a change to the standard, does not need to be reviewed and voted on by the SWGs for initial publication. We do want to publish these with status "proposed" (as is the status of existing HY_Features classes) or another appropriate status such as "experimental". The expectation is that, once published, we will work with the SWGs to finalize these and come back to finalize their status to an accepted published state.

[dr-shorthair]

In a sense they are a format conversion of existing schema

They are a lossy conversion. The object-properties do not have domain and range (global constraints); there are no class-scoped restrictions on range-types or cardinalities (local constraints). I fully understand why the implementation is limited in this way, but they are not just a format conversion.

[dblodgett-usgs]

That's a fair point. I'm the wrong person to be making this proposal, apologies, but trying to move this forward for the SELFIE group.

Does NA policy require a SWG vote to get these selective conversions posted in a "proposed" status?

[dr-shorthair]

I am being really really picky here - having the basic class and property names established is incredibly important. Everything else is much harder. I was just pulling you up on the claim that it was just re-formatting.

But as the names are the key claim here, then I guess an approach to the NA would be timely.

[ghobona]

@dblodgett-usgs I have created PR https://github.com/opengeospatial/NamingAuthority/pull/36 to address the requirement in this issue.

The minimal ontologies have been copied into the incubation folder.

The namespaces of the minimal ontologies have been modified to be consistent with the OGC-NA policy on "Name type specification – ontology resources".

Please have a look and confirm whether you are happy with it.

[dblodgett-usgs]

The changes are fine with me as long as they are permenant. Does this mean that we are going to take the ones like: https://www.opengis.net/def/appschema/hy_features/hyf/ down and replace with https://www.opengis.net/ont/hyf# ?

[ghobona]

Since the two are not the same, for example one being an ontology and the other being a concept scheme, then there is no need to bring the concept scheme down.

[dblodgett-usgs]

OK -- can you chime in here, @rob-metalinkage ? I thought we were extending the same set of resources with this work.

[rob-metalinkage]

This is actually an instance of OWL "punning" - the definition is defined using OWL classes, but exposed as a set of concept instances. There are several reasons for this, including that OWL has nested horribleness that Linked Data cant really support..

so we actually create a third view - an FeatureModel view that specifies the properties attached to Feature Types - and join it to the SKOS view - but we can create more sophisticated renderings.

So they all use the same URIs - because they are the same things view through different content models..

We do need to resolve this - making a call something is "an ontology" isnt simple - every app schema and code list and specification has "an ontology".

/ont resources cant be resolved by the definitions server and # based URIs dont make sense in a Linked Data environment - only batch loading of containing documents is supported and clients need to find the #29

Suggest Gobe and I have a tech deep dive - then come back with a proposal

IMHO however I think following the HYF pattern is the path of least resistance, most flexible and most consistent with a broader view of OGC processes. There is a reason it converged on this pattern when i tried to publish the thing...

[dr-shorthair]

Indeed - the /ont/ pattern has only been used once AFAIK, for GeoSPARQL. And for the reasons given by @rob-metalinkage /def/ would be preferable in future - i.e. OWL ontology is a view or implementation of resources which may also be presented with other alternative views. /def/ comes with no implementation baggage.

However, we can't break URIs that are already in use, so for GeoSPARQL /ont/ it is, forever I'm afraid, for all the GeoSPARQL elements. It'll probably have to be special-cased.

[ghobona]

@dblodgett-usgs Are you happy with the proposal (https://github.com/opengeospatial/NamingAuthority/pull/36) for GWML2 and GeoSciML minimal ontologies?

[dblodgett-usgs]

Based on @dr-shorthair and @rob-metalinkage's points here, no, I would like to see these all follow the /def/ pattern -- or whatever you and Rob cook up in the mean time.

[ghobona]

@dblodgett-usgs Understood. Please note that the GroundWaterML standard specifies a number of definitions in requirements under the http://www.opengis.net/def namespace.

We are still bound by the Policy on Name Type Specification for Ontologies.

@dr-shorthair Are you proposing that the Policy on Name Type Specification for Ontologies be retired? If so, an OGC-NA motion is needed, followed by a TC motion.

[rob-metalinkage]

I think we are also struggling to decide "what is an ontology" and therefore goes under that policy. If the thing exists before an ontology is built to describe it in a canonical way, it may have an identifier and other forms of resource - and a skos:Concept as a bare minimum ontology. I think we probably should retire that policy because we dont know how to decide if it applies, and its not an ideal technical pattern anyway.

FYI we set up the definitions server so if the mime type is OWL, then a complete OWL file is delivered for any element in the namesapce, as if it was a # URI, (redirect to a # URI) so we dont lose anything by forcing ids to be / based namespaces and resolvable as individual definitions for other formats.

[dr-shorthair]

@dr-shorthair Are you proposing that the Policy on Name Type Specification for Ontologies be retired? If so, an OGC-NA motion is needed, followed by a TC motion.

Yes, I think I am. But interested in views.

[ghobona]

@dr-shorthair Ok, I'll add the topic to the next OGC-NA meeting (for the June TC virtual meeting).

[ghobona]

I discussed this issue with @rob-metalinkage this today. Here is what we agreed.

• HY_Features will be treated as an Application Schema, with concepts using the http://www.opengis.net/def. The Definitions Server is able to export the app schema in SKOS. This means that from a policy perspective, it is governed through the Name Type Specification (NTS) for Definitions. In the short term, I will use 'app schema' instead of 'ontology' when referring HY_Features to avoid implying the relevance of the NTS for Ontologies.

• @rob-metalinkage will review the proposed HY_Features app schema to check how it relates to the one he previously published.

• @rob-metalinkage will propose edits to the GeoSciML definitions, specifically the namespaces. He will not publish them until the GeoSciML SWG has approved the proposed edits.

• @ghobona will request the GeoSciML SWG to approve the proposed GeoSciML definitions.

• @ghobona will compare the proposed GWML definitions to ensure that they do not conflict with the ones declared in the GWML standard. Note that there are 21 URIs, with a http://www.opengis.net/def namespace, in the GWML 2.3 standard that is due for release.

• @ghobona will update the proposed GWML definitions and request the GWML SWG to approve them.

[rob-metalinkage]

Big question is why HYF is duplicated here, when it exists already in the defs server:

e.g. https://www.opengis.net/def/appschema/hy_features/hyf/HY_CatchmentAggregate

If you want a trimmed down packaging of it we should derive it from the richer model - the same way we extract a SKOS version

I intend to derive JSON schema and JSON-LD contexts from it too. (scripts to do this are on a separate project plan that funds my OGC work)

[dblodgett-usgs]

I think duplication is probably some miscommunication. The intention was to add the rest of the HYF defs with this work not duplicate.

[dblodgett-usgs]

Checking back on this -- are we on track with these or does something else need to be done?

[rob-metalinkage]

OK - I will take the rest of the HYF packages and publish them. We are also onboarding some document generation tools soon and will use that for the HTML rendering which will improve the outcome. I need to update the gsml example still.

[ghobona]

@sgrellet @afeliachi @dblodgett-usgs @rob-metalinkage

The GeoSciML SWG has pushed back on having 'borehole' in the namespace. So we need to drop 'borehole' from the namespace.

Since I got the 'borehole' term from the value of the Ontology's skos:definition , we also need to revise the definition of the Ontology.

Proposal 1

So we would delete the triple below

<https://www.opengis.net/def/appschema/geosciml/borehole> rdf:type owl:Ontology ;
                                 skos:definition 
                                                 "The GeoSciML Borehole package contains model elements for representing Boreholes. This is primarily through re-use of standard components from the (external) Observations and Measurements package."@en .

Proposal 2

We would also change the namespace of all of the contents of the file from https://www.opengis.net/def/appschema/geosciml/borehole to just https://www.opengis.net/def/appschema/geosciml/basic

@rob-metalinkage If there is no objection to the proposals above from @sgrellet @afeliachi @dblodgett-usgs , shall I update the file or do you prefer to do it?

[rob-metalinkage]

OK - i also looked at the definition too - and assumed "b" = borehole not basic

take the versions from the Naming Authority - I'll; update now

[rob-metalinkage]

So any update on the other HY features appschema packages - we only have hydro_feature published

[afeliachi]

The GeoSciML minimal ontology content is a mix of basic and borehole, as it was requested in SELFIE. I used gsmlb just as a place holder.

The skos:definition of the ontology has two values inherited from the two packages. I agree that the definition should be revised by somehow aggregating the definitions of the two packages.

The goal was to have one simple ontology with no packaging artefact as mentioned by @sgrellet here .

The same applies to HY_Features minimal ontology that is a mix of the content of the three packages HYdroFeature, SurfaceHydroFeature and HydrometricNetwork. There are three skos:definition for this ontology inherited from the three packages that should be ultimately aggregated.
The http://opengeospatial.org/def/hyf# is also a placeholder. No package artefact was intended neither for this ontology.

[ghobona]

@afeliachi Thanks for the reply.

Based on your reply, I think Proposal 1 is still valid.

Proposal 2 is updated to: Shall we just revise the namespace to https://www.opengis.net/def/appschema/geosciml to remove any mention of basic or borehole?

[sgrellet]

Could you clarify why 'appschema' appears in the URI here ? I think I was more expecting to see a base URI like https://www.opengis.net/def/geosciml . When we discussed the topic during ELFIE it never poped up in the discussions. (See https://docs.ogc.org/per/18-097.html#_naming_policy).

Maybe I missed something

[ghobona]

@sgrellet The first segment after the /def is the 'definition type'. Please see Section 6.2 of https://docs.opengeospatial.org/pol/09-048r5.html

[rob-metalinkage]

The defs server is able apply different rules for "registers" - so given we want all "model" objects to have access to resources such as the OWL, JSON-LD contexts we have a top level register for these.

register = governance domain - and ApplicationSchema have their specific governance processes.

options for naming considered were

ont - everything is an ontology model - we have other types of models appschema - matches OGC abstract specification for a frame-based model and this definitely applies to HY_Features and GSML

HY_Features has been published this way for over a year. OGC suffers from everyone doing their own approach, we need to standardise.

Apropos of this - I dont see why we need "minimal" as new things at all - why dont we publish the complete set (not a new "minimal set" mixing concerns) - and if necessary just provide minimal detail per object. Publishing and packaging new things (and every set is a new thing) just adds layers of complexity and obscures the underlying interoperability intention. If the community is willing to have this level of engagement around a temporary solution couldnt we get it applied to a longer term option - and only fall back if there is a specific blocker identified?

The hardest part by far is settling on the URIs and the definitions of the things - we have our models with definitions, so its only finalising the URIs then filling in the artefacts matching the current model package boundaries you need behind these. We stand ready to deploy.

PS. If I can have the other packages for HY_Features I can put them up right away. What state are they in?

[dblodgett-usgs]

My understanding was that the rest of HY_Features were included in: https://github.com/opengeospatial/HY_Features/blob/master/ontology/minimal/hyf_minimal.ttl

@afeliachi did the work -- I'm just a messenger.

Re "minimal" that was just a reference to only including class and property names. I thought there was some complications in turning the rest of the UML details into ttl but that's all I know.

[rob-metalinkage]

OK - hard to look and see intent when stuff is duplicated and mixed up.

I suggest you sketch out a roadmap between this 'minimal" approach and some desired future state, and the same for publishing the models using the established pipeline, which extracts minimal OWL, SKOS and a FeatureType centric view of FeatureType/Property containment automatically, and aiming at a stable URI location.

I personally fear the work involved in unpicking the hack and disambiguating published temporary copies.

[dblodgett-usgs]

I'm going to have to recuse myself -- I think my naiveté here is just making things worse.

[rob-metalinkage]

Can we have a go with the full ontologies in a potentially stable target namespace and a statement of what you actually need to achieve?

If the requirement is collating a simple JSON-LD context for a profile of a suite of these combined we can do that consistent with the stable URIs. I am happy to implement an OWL -> JSON-LD converter driven by profiles of the OWL (i.e. a graph like the one you have published where the artefact becomes a named graph and inclusion within the named graph means it is part of the profile. )

I think this is actually what people need to do and we're going round in circles for want of a simple piece of infrastructure to handle relatively trivial job.

Seriously - I can deliver such a tool next week if we have:

"Actual" complete OWL for each package, with appropriate import statements Confirmation these "composite profiles" reflect a profile for a JSON-LD context output. statements about profiles required (the existing "minimal" graphs?) There is a question as to whether just having JSON-LD for each application schema with the same import structure is not sufficient however? Do we need the intermediate profiles at all?

[dblodgett-usgs]

The requirement is resolvable URIs for these feature types and associations.

"Actual" complete OWL for each package, with appropriate import statements

Seems to the sticking point and where I'm out of my depth. I thought the ttl files linked at the top here would suffice but if not, I think we need to step back and discuss why they are not what's needed.

[ghobona]

@dblodgett-usgs Does that mean that the minimal ontologies are returning to SELFIE for further discussion and revision?

If that is the case, I would suggest that we close this issue and reopen it when we receive the new proposal from SELFIE.

[dblodgett-usgs]

Yes, unfortunately, I think so -- except I do not think we will be reopening anything as part of SELFIE.

If this issue can't go forward as is, we will write the findings in the SELFIE ER: That the community is not capable of publish resolvable identifiers for features types and associations from existing standards without further technical maturation, and let future activities take up the charge.

[afeliachi]

The need is not only for JSON-LD contexts, but also resolvable OWL classes and properties. The Skos representation of the models is not suitable for the Linked Data use cases that were discussed in SELFIE. Generating JSON-LD Contexts would be trivial if we have the OWL versions, but would have no meaning without the resolvable formal ontologies behind.

If the only obstacle here is to have many OWL ontologies following the packaging artefact and thus multiple namespaces, then this is something that we can work out from our side. It would be a pity if we don't publish the ontologies now.

[dblodgett-usgs]

I agree, @afeliachi -- would you be willing to lead the charge here? I'm just not technically prepared to communicate the requirements.

[afeliachi]

@dblodgett-usgs thanks, yes I'll do. @rob-metalinkage @ghobona , If I understand well , is following the packaging pattern (+ correct imports) is the only obstacle here ?

[rob-metalinkage]

The obstacles dont seem to be technical, but process: 1) I have published the core HY_Features package a long time ago - but as far as I'm aware SELFIE didnt update references to use it, test it or review it. as far as I'm concerned its done and canonical 2) I havent (as far as I can tell) received either the other packages converted, or the conversion tools packaged for re-use with the relevant configurations - ideally using the same namespace patterns but I can update. 3) artefacts generating that repiublish concepts in different packaging or namespaces violate the core policies of OGC-NA to have a single, consistent source of identifiers. So we pushed back against that packaging pattern in favour of supplying the original packages as OWL.

There is a misconception about SKOS - we publish the OWL - but we also entail SKOS view (all elements are "Concepts" - this is natural enough use of OWL "punning" - and the definition server allows either OWL or SKOS (or other) views of the model. Hit a URI asking for OWL and you get the OWL package that contains it)

So it seems to be an issue that we have simply not exercised the publication->use cycle to do the final test, and simply pushed all the content up once into a final form.

[rob-metalinkage]

P.S. point me to the rest of the packages in OWL and I will complete the publication process - and test the def server to make sure its working. I have just done an update and I need to reinstate the rule so that asking for RDF redirects to the OWL file.

[dblodgett-usgs]

On point 1, SELFIE (elfie-2) draft contexts do point to the https://www.opengis.net/def/appschema/hy_features/hyf/ namespace here: https://opengeospatial.github.io/ELFIE/contexts/elfie-2/hy_features.jsonld

The namespace was a moving target during ELFIE and some artifacts may still exist pointing to an old namespace but efforts were made to keep up.

[rob-metalinkage]

@dblodgett-usgs cool - they should work then (I never really saw anything following the links - such as a client retrieving the definition and showing it in a mouse-over or something - i didnt really have bandwidth to follow everything closely enough to spot it.

We should also make the contexts directly accessible via the namespace - i.e. publish them as part of the application schema publication process. I dont think I've seen this come through as a request.

[dblodgett-usgs]

You didn't miss anything -- that level of testing was never done. I have found great utility in just being able to google for and discover the concepts on the defs server and am sure others have as well. -- I agree that it would be good to have the contexts available from the defs server -- no idea what the right path to get that done would be though. -- which is really to your point about not having exercised this. Hopefully @afeliachi can help us get this across a first finish line and pave the way for the future.

[rob-metalinkage]

@afeliachi - can you point me to the OWL generated from the other HY_Feature packages using the same config as you used for HY_HydroFeature as a starting point. After any namespace tweaks these should be ready to publish canonical versions. Can you do the same for GWML2 or will it be a very temporary version? If so we probably need to publish to an obviously temporary namespace and stick in some metadata to warn people.

[afeliachi]

Having the context on the def server side could be absolutely useful, yes, but IMHO I don't think that it should be considered as format or a view of a schema, it's more of a contextualisation based on one (or many) schema(s). I am regenerating the OWLs for the HY_features packages rigth now.

[rob-metalinkage]

If JSON context documents are packaged in ad-hoc aggregations and only used to map ad-hoc JSON schemas back to the conceptual model, then they are not views of the schema I agree - they are actually mappings between schema.

If on the other hand JSON contexts map to canonical JSON schemas derived from the model, then they reflect a view of the schema - defining all the element names that may be used, but not their structural arrangement.

So we are really talking about a "special type" of JSON-context that provides an implementation view of the schema in JSON-LD, and is to be combined with the same imports logic that the conceptual packages have. Reflecting on this, I think we should mint a special name for this "profile" of JSON-LD so we can declare what rules it conforms to in its metadata. I'll mint a URI for this and add it as an annotation, and make it resolve to an explanation in the defs server.

[rob-metalinkage]

Actually I'll create two profiles of JSON-context - so SELFIE can explicitly declared it is choosing not to use canonical JSON-LD encodings of models. (Not that it had a choice, but when future implementations do i think it will be useful to have a means to declare this.)