Adding New Schemas to Metadata101.org

Hi everybody,

I would like to create new schemas and share them with the community through metadata101.org.
Could you please direct me to the correct “Doc” if any exists on how to do that ?
If nothing particular is required, could you give me the rights" to create a Repo for my schema ?

Cheers,
Sebastien

Hi

Can you share the name of the schema to create the repository and the GitHub users that need to access this new repository?

As far as I know, we have to create the repository for the new schema and a team with the maintainers of the schema.

Regards,
Jose García

Hi,
The schemas we need are iso19139.che and iso19115-3.2018.che
We need it for the git users sebr72 and cmangeat.
Could we get the rights to add other commiter to our repos ?
Or do we need to send requests in some other manner for other people ?

Thanks,
Sebastien Riollet

Hi

I have added a new team and the 2 repositories, you should have an invitation. Please accept it and I will check to add you as maintainer, so you can invite new developers.

Regards,
Jose García

Thanks.
I accepted the invitation.
Please let me know when I can invite new developers.
Best Regards,
Sebastien Riollet

Hi @sebr72 chat indicated you needed some assistance with metadata101, I am sorting though communication to figure out what you are stuck with?

I found this chat from GN5 meeting; is there anything more specific I can help you with?

The issue comes from the release process.
We created GitHub - metadata101/iso19115-3.2018.che and as you can see it cannot build This is due to missing feature or bugs in core-geonetwork

So we came up with the following process

  1. we create our geocat war overlay project which has the core-geonetwork as one of its sub-mode
  2. we fork the core-geonetwork into our own repo where we put our fixes GitHub - sebr72/core-geonetwork: GeoNetwork is a catalog application to manage spatially referenced resources. It provides powerful metadata editing and search functions as well as an interactive web map viewer. It is currently used in numerous Spatial Data Infrastructure initiatives across the world.
  3. to enable our schema to access these transient fixes (in test context) we added the repo https://maven.pkg.github.com/sebr72/core-geonetwork inside iso19115-3.2018.che/pom.xml at main · metadata101/iso19115-3.2018.che · GitHub
  4. to authorise github to build GitHub - metadata101/iso19115-3.2018.che using the fixes from GitHub - sebr72/core-geonetwork: GeoNetwork is a catalog application to manage spatially referenced resources. It provides powerful metadata editing and search functions as well as an interactive web map viewer. It is currently used in numerous Spatial Data Infrastructure initiatives across the world., I created the “Fine-grained token” giving read access to GitHub - sebr72/core-geonetwork: GeoNetwork is a catalog application to manage spatially referenced resources. It provides powerful metadata editing and search functions as well as an interactive web map viewer. It is currently used in numerous Spatial Data Infrastructure initiatives across the world.
  5. the token is given access through this setting iso19115-3.2018.che/settings.xml at 4c236cdcb44b189e7ca3fc58411aba92fb97f1df · metadata101/iso19115-3.2018.che · GitHub

@josegar74 added the key

So now our repo is successfully building.

@jive This solution does not allow other devs to build from their repo. Because the key is specific for each dev-repo pair. But is is sufficient for the moment.

Hi @sebr72

In the step 2, you indicate

using the fixes from GitHub - sebr72/core-geonetwork:

May I ask whether these are general fixes or custom changes that do not apply to the open source version? If they are general fixes, please consider submitting pull requests to the GeoNetwork open source code, thanks.

Regards,
Jose García

I echo that please submit fixes to core-geonetwork and do not maintain a fork (especially since you are familiar with war overlay to mitigate the need to fork for custom war).

Do you have links to specific commits that are maintained by your fork?

One tip that has been used by other region specific scheme modules is to introduce configuration options for “core” that otherwise need a fork. You can see that HNAP schema has different ideas about how layers are represented as online resources (encode layer name in url query) than most of the ISO19139 schemas (encode layer name as title / description). This low-level change shows up as a configuration option rather than forcing a fork.

Jody

@josegar74 Yes, we have fixes which are intended for the core-geonetwork and we will be creating PRs for them. We are in a complex situation with old fixes that cannot be tested without some dev on our new schema (hence we cannot created all the PRs immediately.) But our first one is created and we are in the process of making mergeable.

@josegar74 @jive our first PR is now mergeable. (FYI it was longer than anticipated because we had no test environment for the changes requested by @josegar74)
@antoniocerciello has requested 3 reviews, 2 of them are still pending.
The ball is on your side :wink:

Thanks for keeping this moving, it looks like the PR has some conflicts to resolve before it can be merged (and backported?)

@jive , @josegar74 Conflicts resolved :grinning: . Ready for you guys