Esri / geoportal-server-catalog

Esri Geoportal Server is a next generation open-source metadata catalog and editor, based on elasticsearch.
https://www.esri.com/en-us/arcgis/products/geoportal-server/overview
Apache License 2.0
95 stars 60 forks source link

Custom Metadata Profiles #325

Closed lewjc closed 1 year ago

lewjc commented 4 years ago

Hi,

I have been attempting to create my own custom metadata profile. I have created a profile and enabled it in metadata-editor.js, however when I go to upload my custom XML, none of the custom tags are recognized. I was unable to find any information in the wiki regarding advanced metadata customization, other than where the 'My Profile' example is in the source code. Could you point me in the right direction?

Thanks

mhogeweg commented 4 years ago

hi Lewis. Perhaps best to do a webcast sometime.

Editing a profile in geoportal essentially starts with selecting a base implementation. for example ISO 19115/19139. Your metadata type 'extends' that base with your specific XML elements, attributes, domains, defaults, validation rules, etc.

Think of the XML as being built up of classes (like the UML diagrams in the typical ISO/OGC/INSPIRE documentation). The editor code follows that approach. So you may have a class for a free text field or a class for contact information, etc. A good example is the contact info. This returns in metadata in various areas (point of contact, owner, distributor, etc). You'd define the contact info class once for the editor and then reference it from other parts of your editor.

When you reference a class, in the HTML template you can specify what the target XML element needs to be, whether the class is optional and/or can be repeated, etc.

Example:

  <div data-dojo-type="esri/dijit/metadata/form/iso/ObjectReference"
    data-dojo-props="target:'gmd:distributorContact',minOccurs:1,maxOccurs:1,
      label:'${i18nIso.AbstractMD_Identification.pointOfContact}'">
    <div data-dojo-type="esri/dijit/metadata/types/iso/gmd/citation/CI_ResponsibleParty"></div>
  </div>

Here you'll see esri/dijit/.../CI_ResponsibleParty. This means this is one of those classes that exist, but is actually not local to your metadata style. It is automatically fetched by the JS API. If you want to reference a local class you'd have something like this: app/gxe/types/yourtype/.../CI_ResponsibleParty

For the UI there are other types of classes that result in free text fields (esri/dijit/metadata/**form**/iso/GcoElement), drop-downs, date widgets, etc. They will be referenced using the form path.

lewjc commented 4 years ago

Hi,

Thank you very much for the thorough and detailed explinaiton, I came across this when delving further into the source, but you have tied it all together very well for me.

Where can I find the webcasts? It may be handy for me to go through them to further increase my understanding. One more question that would help me fit all the pieces together:

When I create these classes, how does the editor know to generate my custom xml? Say my namespace is xyz and I have a specific schema for the types and I would need to have it generate something like

`

**NAME** ` How would it know to generate the xml in that way? Apologies if this is blatantly obvious and I am missing the mark; I am quite new to all of this. And is there also a way to extend the existing HTML templates that exist on the js.arcgis domain? is it a case of copying them and extending them and referencing them locally?
mhogeweg commented 4 years ago

hi, we don't have pre-recorded webcast. I would be happy to get on the phone.

the XML structure is derived from the HTML templates while they also define the structure of the editor. so, the editor follows the XML structure. for example, if your XML has multiple sections at the same level, you could use tabs to separate them in the editor:

    <div data-dojo-type="esri/dijit/metadata/form/Tabs">

Within such div you could have nested tab divs, etc.

you'll also see these types of divs:

<div data-dojo-type="esri/dijit/metadata/form/Element" 
     data-dojo-props="target:'gmd:version',label:'${i18nIso.MD_Format.version}'">
  <div data-dojo-type="esri/dijit/metadata/form/iso/GcoElement" 
       data-dojo-props="target:'gco:CharacterString'"></div>
</div>

this declares a single editor element gmd:version that will result in an XML structure like this: <gmd:version><gco:CharacterString>...</gco:CharacterString></gmd:version>

the target attribute includes the namespace prefix to use

mhogeweg commented 4 years ago

You'll also have something like the MyProfileDocumentType.js that is the basis. In this you would define namespaces (only ones that are not inherited from the parent specification) for your metadata style.

the ISO base profile includes the following snippet:

var oThisClass = declare(DocumentType, {
...
initializeNamespaces: function() {
  this.addNamespace("gmd", "http://www.isotc211.org/2005/gmd");
  this.addNamespace("gco", "http://www.isotc211.org/2005/gco");
  this.addNamespace("srv", "http://www.isotc211.org/2005/srv");
  this.addNamespace("gml", "http://www.opengis.net/gml");
  this.addNamespace("xlink", "http://www.w3.org/1999/xlink");
},
...

If you add an additional namespace with prefix xyz you'd add:

  this.addNamespace("xyz", "http://mydomain/mynamespacepath");

and then in the HTML templates use the target dojo property like so: data-dojo-props="target:'xyz:mynewelement',label:'My New Element Label'"

Note: only change name spaces and prefixes if absolutely needed. If you stay within the base specification namespaces (like ISO ones above) I would not change their namespace.

mhogeweg commented 4 years ago

While you're in the DocumentType.js you may see functions like these:

These get called when the editor builds for a document. They allow you to override for example the multiplicity of an element, implement that fun 'conditional' requirement (if the value of that element is such, then this element is mandatory), or set default values.

lewjc commented 4 years ago

Hi Marten,

Thanks for all of the Info! everything makes a lot more sense now, hope to speak further next week

andreiste commented 4 years ago

Hi,

Regarding the conditional requirement and the functions available in the DocumentType.js is it possible according to a selected value from a InputSelectOne element to offer distinct options for a InputSelectMany element? The user selects an option from the InputSelectOne element and according to that selection you than have distinct options for the InputSelectMany element.

mhogeweg commented 4 years ago

I suggest checking out one of the existing profiles. You'll see some approaches where a select one choice is turned into a set of tabs and then within the tab you have the elements specific to that choice.

Before coding this in JavaScript I'd look at using the template approach first.

andreiste commented 4 years ago

Thank you so much for the response. I've seen the ChooseElement but unfortunately I have a lot of options for the Choose one element and it would mean to create many tabs... Is there any other option?

mhogeweg commented 1 year ago

We added documentation on creating a custom profile here: https://github.com/Esri/geoportal-server-catalog/wiki/Customize-Metadata-Profiles. closing this ticket.