Register HY_Features content

[ghobona]

Publish content updated by https://github.com/opengeospatial/NamingAuthority/pull/151

[ghobona]

@rob-metalinkage I have uploaded the new HY Features turtle files to the Django CMS and pressed the 'publish' button. The system reported that the content had been published. However, the new content is not showing on VocPrez. The content that was there is displaying as skos:Concept instances.

So am I right in thinking that the VocPrez UI can only display skos:Concept instances?

[dblodgett-usgs]

Looking at this, https://www.opengis.net/def/schema/hy_features/hyf does not show all the featuretypes or any of the properties?

e.g. https://www.opengis.net/def/schema/hy_features/hyf/HY_HydroLocation can be retrieved but is not listed here: https://www.opengis.net/def/schema/hy_features/hyf

e.g. https://www.opengis.net/def/schema/hy_features/hyf/referencedPosition can not be retrieved but is declared here: https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/schema/hy_features/hyf/hyf.ttl#L391

[ghobona]

@dblodgett-usgs The Definitions Server is configured to publish definitions that are encoded as SKOS. Clause 7.5 of the definitions policy also states that the definitions have to be skos:Concept instances. So we were not able to publish the revised HY_Features definitions. So we will need to modify the HY_Features definitions to ensure that each owl:Class is also a skos:Concept.

I have taken an action to prepare the modified HY_Features file. However, it will be a couple of more weeks before I can complete it.

[dblodgett-usgs]

Got it - I could likely take care of it sooner, or is this something you kind of need to do?

[ghobona]

@dblodgett-usgs Ok, please proceed to update it. Thanks for volunteering.

[rob-metalinkage]

Hi I have been doing some tweaking of the entailment - the python and Jena behave differently and default labels wasnt working.

hyf:HY_HydroLocation a owl:Class, skos:Concept ; rdfs:label "ReferenceLocation"@en ;

• i.e. this shows up but as "ReferenceLocation" - not sure why this one case has a label when nothing else does..

It should not be complete - and Features even have links to the properties they define.

VocPrez has been upgraded to allow in-line images too - so could drop in diagrams - but this will take a bit of thinking about who and how the diagram links are added to the model. Probably a separate turtle file with the links is required as an annotation - the scripts allow annotations to be added during entailment.

https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment

Lets review this further and decide what to do about the random label thing...

[dblodgett-usgs]

Thanks Rob -- if it would make sense to do some manual intervention here, I'm willing to take that on. I think this is something with how the UML was converted in the first place. If I remember correctly, there was some manual modification after the shapechange run... so we may just be on a wild goose chase.

[rob-metalinkage]

Hi - I think we can close this now - pending review - and raise specific issues for the content conversion in a separate HY_Features project perhaps? Specific problems with the UI or entailment can be raised here as new issues.

[rob-metalinkage]

PS - also checked in relevant entailment code updates

[sgrellet]

I remember correctly, there was some manual modification after the shapechange run

Indeed that's what @afeliachi did to remove traces of UML "artefacts" from the generated file

raise specific issues for the content conversion in a separate HY_Features project perhaps?

I am fine with this. Should we do this in https://github.com/opengeospatial/HY_Features ? Happy to work on this as well. Easier beginning of 2022 for me I think

[dblodgett-usgs]

That seems right, @sgrellet

[rob-metalinkage]

under review by HY_Features SWG

[ghobona]

@rob-metalinkage Has the HY_Features SWG completed the review?

[dblodgett-usgs]

@ghobona -- members of the SWG have not formally convened a review, but the content that is there is satisfactory for our current baseline needs.

[ghobona]

Thanks @dblodgett-usgs .

@rob-metalinkage The last time I tried to publish the HY_Features definitions (in November 2021) I encountered problems with the publishing mechanism. Could you please publish the HY_Features definitions?

[dblodgett-usgs]

One thing to note -- We've noticed some concepts are "experimental" (e.g. https://www.opengis.net/def/schema/hy_features/hyf/HY_HydrometricFeature) -- will these become final when we get them published?

[rob-metalinkage]

Hi all

I'd like to revisit the "one file for all packages" vs one file per package. IMHO each package probably needs its own namespace and we can add more packages incrementally - testing each one as we go.

I'd also like to capture the exact generation methodology and shapechange configurations from BRGM as metadata - and see if there is a pathway to not hand-editing any pieces.

[ghobona]

@dblodgett-usgs As soon as the SWG approves the definitions, the "experimental" label can come off.

[dblodgett-usgs]

We approved them via email vote some time ago. I guess I'm confused as some definitions are not experimental already.

[ghobona]

@dblodgett-usgs In that case then, I will initiate an OGC-NA email vote today proposing that the status of the HY_Features definitions be changed to 'valid'.

[sgrellet]

I'd like to revisit the "one file for all packages" vs one file per package. IMHO each package probably needs its own namespace and we can add more packages incrementally - testing each one as we go.

@rob-metalinkage : should we understand that you plan to adjust the URI patterns applied to take into account the packages names ? I wonder whether in the context of HY_Features the packages are just UML artefacts or actually have an importance in structuring the semantics ? For example in GeoSciml we have 'Basic' and various extensions which I'd prefer leaving out of the ontology discussion.

I'd also like to capture the exact generation methodology and shapechange configurations from BRGM as metadata - and see if there is a pathway to not hand-editing any pieces.

I need to do some computer archeology here. Will keep you posted. Pretty sure @afeliachi already did some manual edit straight from ShapeChange

[ghobona]

@dblodgett-usgs If the namespaces are going to change, then we should hold off removing the 'experimental' label because changing the namespaces of resolvable URIs would move them to a different location. Do you agree?

[sgrellet]

indeed @ghobona : I agree, we should wait for @rob-metalinkage answers to my questions

[ghobona]

@sgrellet Ok, thanks for confirming.

[dblodgett-usgs]

I don't agree. The current URIs are fine and have been approved by the SWG. Further, some are already listed as approved. e.g. https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment

[ghobona]

@dblodgett-usgs You are right. Since the SWG has already approved them, we should proceed with the definitions and namespaces as they currently are.

I'll proceed with the OGC-NA email vote.

[rob-metalinkage]

Ok.. I think we are in the territory of translating a conceptual model to a logical model to a physical.model here and that translation involved namespace mapping. At the moment there us no link back to the conceptual model package.. but we could look at formalising a canonical pattern for metadata attributes for ontology elements. It's a swings and roundabouts case I guess. I'll try to find time to write up the implications later and push a status update asap.

[sgrellet]

Everyone, I was more willing to wait for Rob's feedback not to change those URIs the SWG validated! -> I'm ok proceeding as planned as we have several UseCases needing those URIs to move on.

I was more in the idea of trying to refine more the process with Rob. -> that's not the only standard we have awaiting to be published like this. So the cleaner the work sequence, the easiest it will for us all.

[rob-metalinkage]

Re refining the process - is it possible to run the conversion, keeping the same URIs but adding a link to the containing package (each package will need a URI) - then at least users can follow that link for a given definition and find a path to the specific package in case some implementation needs package specific artefacts, or people want the original UML?

If we can have a spreadsheet matching elements URIs to relevant diagrams from here https://github.com/opengeospatial/HY_Features/tree/master/figs I can add these to the definitions server to improve presentation.

[dblodgett-usgs]

Understood @sgrellet -- I'd like to keep this particular issue on track though. @rob-metalinkage Can you open a new issue to discuss the packaging nuances?

[ghobona]

Content published.