Applicable policy / procedure for additional classes and associations behind https://www.opengis.net/def/schema/?

[dblodgett-usgs]

The HY_Features SWG and other environmental domain feature model SWGs need to publish definitions of classes and associations for use in structured data. This is a well documented need that has been in "experimental" status for years. At a minimum, a URL that resolves to a text document containing a name is required and would be sufficient for initial use.

The content currently published here: https://www.opengis.net/def/schema/hy_features/hyf is in status "experimental" and -- as far as I know, there is no policy for governance of that or additional content there.

Am I missing a policy for publishing additional definitions?

How should we go about establishing such a policy / procedure?

[dblodgett-usgs]

@ghobona -- do you have any response here? We have an email thread going with the HY_Features SWG to discuss whether the defs server is the appropriate place to publish URIs for the concepts of HY_Features and all and could use some input.

[ghobona]

@dblodgett-usgs The 'experimental' label meant that the definitions were the subject of an on-going Innovation initiative. Now that the initiative(s) have ended, please ask the relevant DWG or SWG to pass a motion approving the definitions for registration. OGC-NA will then mirror the vote and change the status of the definitions to 'valid'.

Since we are a couple of months away from the next OGC Members' Meeting, I would suggest asking the Chair of the DWG or SWG to run an email vote. I will mirror the DWG/SWG vote with an OGC-NA vote once the DWG/SWG has approved the definitions. We can complete the whole process within a month.

[dblodgett-usgs]

Thanks @ghobona -- what about the "additional" and "procedure" part? It's not entirely clear to me what artifacts are required and what get autogenerated etc.

The existing content is here: https://github.com/opengeospatial/NamingAuthority/tree/master/definitions/schema/hy_features/hyf but that's only about half of the HY_Features model. From what I recall, the original content was just a single ttl file generated by shapechange -- how do we generate the rest of this content?

Maybe @rob-metalinkage needs to weigh in as he's the one who's been working the content?

[lieberjosh]

There seems to be a policy issue here. The HYF conceptual model (and UML) are an adopted standard. Any OWL or other implementation of the conceptual model is, well, an unapproved implementation. Is there an automated procedure sufficient to uniquely define an encoding such as OWL based on adopted UML, or should such an encoding still go through an adoption process? There has certainly been discussion of the need for judgement in creating ontologies from UML, even if it doesn't involve filling out a logical / physical model with properties, etc.

[ghobona]

@dblodgett-usgs My recommendation would be to register what is already there, even if it is half of the HY_Features model. The SWG (not the OGC-NA) would then incrementally build the rest of the ontology over a period of time.

@lieberjosh OGC-NA policies allow for ontologies and definitions of concepts to be registered on the Definitions Server. Neither the ontologies nor the definitions have to be adopted standards prior to registration.

[dblodgett-usgs]

Thanks @ghobona.

So then additional definitions would be contributed by modifying all the artifacts here: https://github.com/opengeospatial/NamingAuthority/tree/master/definitions/schema/hy_features/hyf ?

This html, for example, looks like it's auto generated by something? https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/schema/hy_features/hyf/hyf.html

[ghobona]

@dblodgett-usgs Yes, additional definitions would be contributed by modifying the artifacts there.

I can create a branch in this repository for the SWG to work from. Then when the SWG is ready to do a major update, the SWG can create a Pull Request and endorse the Pull Request through a SWG Motion. I or @rob-metalinkage can then review the Pull Request and recommend approval by the OGC-NA.

[dblodgett-usgs]

OK. Does the defs server rely on all the pyLODE outputs (assuming that's what those are) that are in there? I don't see those artifacts elsewhere in the repository and am struggling to get pyLODE running.

[ghobona]

The Definitions Server has an RDF4J Workbench underneath it. That is where it gets content from. RDF4J Workbench is a SPARQL Server. I'm not sure about pyLODE's role.

[dblodgett-usgs]

@rob-metalinkage -- do you mind removing the artifacts that are not required from this directory? https://github.com/opengeospatial/NamingAuthority/tree/master/definitions/schema/hy_features/hyf

[KathiSchleidt]

@ghobona picking up a relevant comment by @ingosimonis in the related mail threads:

What we have not really worked out is the process for Definition Server updates.

Unfortunately, from my experience, I can only confirm this! While I'm most thankful to @rob-metalinkage for reaching out and helping me navigate the def-server jungle, nice would be a clear process for provision and update of def server concepts, not requiring support from "native guides" ;)

Any chance of somehow splitting the more experimental work that Rob is doing under the innovation program from the more pragmatic day-to-day concerns of getting resources published? I know one of my issues is seeing the forest for all the (experimental) trees in the way! I'd much appreciate a clean page somewhere detailing:

1. what concepts can be provided via the OGC def server
2. how these concepts are to be provide for ingestion (following which ttl, provided where?)
3. a simple but complete example for guidance in creating the necessary ingestion resources

I appreciate the lack of resources at OGC for such work, but I'd also like some appreciation for all the work SWG members are doing (on their own resources) trying (and in many cases failing) to get essential content provided (I know I've lost weeks on this to date, still failing :( )

Any outlook on remediation of this core OGC issue? We'll also be investigating options via the newly instated Conceptual Modelling Group running under the Architecture DWG

:)

Kathi

PS: something is also going strangely sideways in the official def server content - PipelineML types seem to have taken over the world, all concepts listed individually?

[ingosimonis]

Hi Kathi,

the current plan is that individual groups will be granted editing rights for Github repos. The DefServer dynamically from these repos. So we need a 1:1 relationship between SWG/DWG and repo for all resources that go beyond elements that are part of the Standards. This includes in particular application schemas.

In the long run, there should be exploration capabilities so that SWGs can ask questions such as "what do I break if I change this thing?".

But turning the question around:

• What concepts do you like to see supported by the Def Server?
• How can you provide these concepts to the Def Server? What is your preferred format?

Thank you for your help, Ing

Kathi Schleidt wrote on 07.10.21 13:50:

@ghobona https://github.com/ghobona picking up a relevant comment by @ingosimonis https://github.com/ingosimonis in the related mail threads:

|What we have not really worked out is the process for Definition Server updates.|

Unfortunately, from my experience, I can only confirm this! While I'm most thankful to @rob-metalinkage https://github.com/rob-metalinkage for reaching out and helping me navigate the def-server jungle, nice would be a clear process for provision and update of def server concepts, not requiring support from "native guides" ;)

Any chance of somehow splitting the more experimental work that Rob is doing under the innovation program from the more pragmatic day-to-day concerns of getting resources published? I know one of my issues is seeing the forest for all the (experimental) trees in the way! I'd much appreciate a clean page somewhere detailing:

1. what concepts can be provided via the OGC def server
2. how these concepts are to be provide for ingestion (following which ttl, provided where?)
3. a simple but complete example for guidance in creating the necessary ingestion resources

I appreciate the lack of resources at OGC for such work, but I'd also like some appreciation for all the work SWG members are doing (on their own resources) trying (and in many cases failing) to get essential content provided (I know I've lost weeks on this to date, still failing :( )

Any outlook on remediation of this core OGC issue? We'll also be investigating options via the newly instated Conceptual Modelling Group running under the Architecture DWG

:)

Kathi

PS: something is also going strangely sideways in the official def server content http://defs.opengis.net/vocprez/vocab/ - PipelineML types seem to have taken over the world, all concepts listed individually?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-937717673, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ3DWBOSRTMVU6MRJUKOWLUFWCRNANCNFSM5EKOKDXQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- https://www.ogc.org/webinars

[dblodgett-usgs]

I will second what @KathiSchleidt suggests above and appreciate your bigger-picture direction here, @ingosimonis.

I'd much appreciate a clean page somewhere detailing:

• what concepts can be provided via the OGC def server
• how these concepts are to be provide for ingestion (following which ttl, provided where?)
• a simple but complete example for guidance in creating the necessary ingestion resources

I remain a bit uncertain exactly what content the defs server actually expects as there are a lot of artifacts in the directory in question....

I'm going to close this issue as @ghobona did answer the original question here. https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-936880047 and here https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-936961408

@KathiSchleidt -- your latest comment diverged quite a bit from the original issue topc but I think it needs to be captured. Do you want to open one or two new issues to make sure we keep focus on this?

[ingosimonis]

Hi Dave,

again, let me turn the question around. What resource types do you want to be supported?

It is not the OGC staff taking the decision here what will be supported and what not. We have just started with the documents we found in the register that was made available to us. We then added elements we found left and right our path. Getting clear requirements from the user community would help tremendously!

Cheers, Ingo

David Blodgett wrote on 07.10.21 15:02:

I will second what @KathiSchleidt https://github.com/KathiSchleidt suggests above and appreciate your bigger-picture direction here, @ingosimonis https://github.com/ingosimonis.

I'd much appreciate a clean page somewhere detailing:

  * what concepts can be provided via the OGC def server
  * how these concepts are to be provide for ingestion (following
    which ttl, provided where?)
  * a simple but complete example for guidance in creating the
    necessary ingestion resources

I remain a bit uncertain exactly what content the defs server actually expects as there are a lot of artifacts in the directory in question.... image https://user-images.githubusercontent.com/1492803/136389048-b3ae4241-11d5-4679-bba9-18268020a68a.png

I'm going to close this issue as @ghobona https://github.com/ghobona did answer the original question here. #138 (comment) https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-936880047 and here #138 (comment) https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-936961408

@KathiSchleidt https://github.com/KathiSchleidt -- your latest comment diverged quite a bit from the original issue topc but I think it needs to be captured. Do you want to open one or two new issues to make sure we keep focus on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-937770450, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ3DWGXBULOPARWQB33IJLUFWK55ANCNFSM5EKOKDXQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- https://www.ogc.org/webinars

[dblodgett-usgs]

I don't think we are communicating clearly here. See the screen shot I put in my last comment. There are various html, rdf, jsonld, ttl, png, and css artifacts in that directory.

What Kathi and I are asking is:

1. what is allowable in terms of kinds of concepts for which we could register definitions according to current policy?
2. what technical artifact do we use to submit those definitions?
3. some pointer to how the technical artifacts that are required can be created.

I understand that it's not the OGC Staff's role to decide what will be supported -- but as the designers and implementers of the register, you do possess knowledge that needs to be communicated if the community is going to engage with the register at all.

[ingosimonis]

Even though I risk going in circles here: We really need your input in what you want to be supported. I don't know how these resources found their way into the DefServer. It is easy to remove them.

David Blodgett wrote on 07.10.21 18:37:

I don't think we are communicating clearly here. See the screen shot I put in my last comment. There are various html, rdf, jsonld, ttl, png, and css artifacts in that directory.

What Kathi and I are asking is:

1. what is allowable in terms of kinds of concepts for which we could register definitions?
2. what technical artifact do we use to submit those definitions?
3. some pointer to how the technical artifacts that are required can be created.

I understand that it's not the OGC Staff's role to decide what will be supported -- but as the designers and implementers of the register, you do possess knowledge that needs to be communicated if the community is going to engage with the register at all.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/138#issuecomment-937966656, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ3DWE4RLSTKGDZFBY64QLUFXEF7ANCNFSM5EKOKDXQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- https://www.ogc.org/webinars

[dblodgett-usgs]

OK -- yeah, in my ideal world, we would submit a ttl file containing definitions we want supported akin to https://github.com/opengeospatial/HY_Features/blob/master/ontology/minimal/hyf_minimal.ttl and the other artifacts would be built for us. If there are other "features" that we could take advantage of by submitting additonal content (png for example) I would want to know about those, but have no preconceived notions.

I also don't know how those artifacts were created or what they do in the defs server!

[ghobona]

what is allowable in terms of kinds of concepts for which we could register definitions according to current policy?

Section 5.4 of the OGC-NA Charter lists the resources that can be registered by the OGC-NA.

what technical artifact do we use to submit those definitions?

Section 7.2 of the OGC-NA Procedures policy describes how to submit proposals to the OGC-NA.

Once a proposal is received, I usually advise the SWG/DWG to create an Issue on the GitHub board. Sometimes I create the Issue myself.

I then ask the SWG/DWG to place the artifact in the 'incubation' folder. Typically the artefacts are TTL but sometimes RDF/XML. Some of the proposals we received in the past were CSV. Some of the proposals were GML Dictionaries.

some pointer to how the technical artifacts that are required can be created

If all that is being proposed for registration is a series of codelists (or a flat register), then it is best to just submit a CSV file like this one.

If what is being proposed for registration is a domain ontology, then it requires domain knowledge. The resources to create an ontology that is acceptable to the majority, even from an existing logical model, are enormous. That is why OGC Staff and the OGC-NA rely on the SWGs and DWGs to design the ontologies.

[rob-metalinkage]

Sorry I didnt get to this earlier.

1. an update to the documentation to make things clearer in progress - i have a stub already will flesh out at http://www.opengis.net/def/about/modelresources

2. Kathi and O&M is talking about 4 different sets of information which is probably why everyone is confused: registering codelists, the modspec view of O&M 3, the linkages between O&M and other specs and publishing the UML schema itself... I need to work out how to get the publisher viewpoint compartmentalised - started by publishing Use Case descriptions .. see progress so far at http://defs-dev.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/about/usecases

3. Only the TTL representation of the OWL artefact is required - the set of resources show the set of options which may make sense - its a straw man. Diagrams and other views of the model could be automatically generated but can be provided directly. A version of vocprez and pyLode that incorporate these automatically into HTML views will be configured to run on TTL file commit.

4. remember the repository is not the public facing restaurant menu - that is via ?_profile=alt parameter on any URI - the repository is the chef's larder and its organised to support the cooking process, and may be re-organised at any time. Obviously the chef needs to inform the suppliers what goes where in the larder - I will add labels to the shelves.. (README in each "domain")

5. all this has been on the backburner pending user interest and feedback - now this has emerged we can pivot to spending some time organising it all and briefing the new suppliers (providing publisher-centric docs)

[KathiSchleidt]

I've tried to pull the relevant points on how to move forward over to #142

[sgrellet]

Thanks @rob-metalinkage for the clarification

Just need an extra element from you to get started cross-checking the content VS the spec. From Dave comment :

'The existing content is here: https://github.com/opengeospatial/NamingAuthority/tree/master/definitions/schema/hy_features/hyf but that's only about half of the HY_Features model. From what I recall, the original content was just a single ttl file generated by shapechange -- how do we generate the rest of this content?'

=> @rob-metalinkage : which ttl did you start from to feed https://github.com/opengeospatial/NamingAuthority/tree/master/definitions/schema/hy_features/hyf ? Which one from those here : 'https://github.com/opengeospatial/HY_Features/tree/master/ontology' ?