Context Navigation

← Previous Version
View Latest Version
Next Version →

Version 1 (modified by simonp, 16 years ago) ( diff )
--

Proposal number : Proposal title : Profile Support for GN

Date	2008/06/20
Contact(s)	Simon Pigot
Last edited	Timestamp
Status	draft, under development
Assigned to release	2.3
Resources	Available

Overview

GN supports different metadata standards eg. Dublin Core, ISO, FGDC etc based on XML Schema Definition (XSD) files. To suit the needs of different communities, jurisdictions and organisations, these standards (particularly the ISO standards) can be profiled – typically this means extending and restricting the types of elements and introducing (or relaxing) conditions based on content. For example, the spatial council for Australia and New Zealand, ANZLIC, profiled the ISO metadata standard with one of the changes being to make the gmd:fileIdentifier element mandatory. The Australian Marine Community profiled the ISO standard by adding new elements and changing the conditionality of others.

GN needs to adopt a set of XSD procedures for describing profiles and implement support for profiles that re-uses as much of the underlying standard as possible. This proposal outlines:

1.the XSD procedures supported by GN for describing a profile – extension, restriction and substitution groups 2.the components needed to describe a profile in GN 3.how profile support is implemented

National profiles will be included as optional installation packages. The template for this will be developed using BlueNet supported profiles for Australian use.

Although other standards can and have been profiles, this proposal relates to profiles of the ISO iso19139 standard.

A future proposal will describe support for profiles as dynamic plug-ins.

Proposal Type

Type: Module changes, Guidelines change, Installer change
App: !Geonetwork
Module: XSLT layer, DataManager, CSW (later)

Voting History

No history yet

Motivations

See overview.

How to Add a Profile under this Proposal

An implementation can be found in the BlueNet MEST version of GN – here: http://anzlicmet.bluenet.utas.edu.au with source code here: http://geonetwork.svn.sourceforge.net/viewvc/geonetwork/sandbox/

This proposal describes this implementation.

1 - Where are profiles stored and what are the XSD procedures can be used to define a profile?

Profiles live in web/geonetwork/xml/schemas with the other standards. They are named according to base standard with an extension after a '.' to indicate the profile eg. Marine Community Profile (MCP) of iso19139 is named iso19139.mcp, so the full path to that profile would be web/geonetwork/xml/schemas/iso19139.mcp. The XSD files are held in the schema directory. The layout of the XSD files in the schema directory is not fixed.

The idea underlying profile support is that the XSD files of the base standard are not modified, instead, a new namespace is introduced and elements in the base standard are extended to contain new elements or restricted to change cardinality using the XSD mechanisms: xs:extension, xs:restriction and substitution groups.

So for example, in the MCP we add mcp:MD_CreativeCommons as an additional gmd:MD_Constraint as follows:

<!-- ================================================================== -->
<!-- Add MD_CreativeCommons as a substitute for MD_Constraints          -->
<!-- ================================================================== -->

 <xs:element name="MD_CreativeCommons" substitutionGroup="gmd:MD_Constraints" type="mcp:MD_Constraints_Type"/>      

  <xs:complexType name="MD_Constraints_Type">
    <xs:annotation>
      <xs:documentation>
        Add MD_CreativeCommons as an extension of gmd:MD_Constraints_Type
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="gmd:MD_Constraints_Type">
        <xs:sequence minOccurs="0">
          <xs:element name="jurisdictionLink" type="gmd:URL_PropertyType" minOccurs="1"/>
          <xs:element name="licenseLink" type="gmd:URL_PropertyType" minOccurs="1"/>
          <xs:element name="imageLink" type="gmd:URL_PropertyType" minOccurs="1"/>
          <xs:element name="licenseName" type="gco:CharacterString_PropertyType" minOccurs="1"/>
        </xs:sequence>
        <xs:attribute ref="gco:isoType" use="required" fixed="gmd:MD_Constraints"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

The extension process for adding this new type of constraint, begins with the definition of the new element (gmd:MD_CreativeCommons) and the element it can substitute for (gmd:MD_Constraints).

Next the type of this element (gmd:MD_ConstraintsType) is defined as an extension of gmd:MD_Constraints_Type (xs:extension). The new elements that we are extending this type with are then shown in a sequence. Finally, following the ISO guidelines, we define the name of the element that this element can replace (gmd:MD_Constraints) as a fixed value, mandatory attribute (gco:isoType=”gmd:MD_Constraints”) of the new element MD_CreativeCommons.

A good reference on this type of profile definition can be found on the Australian SEEGRID site: https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/MetadataProfiles

To load the extensions plus the base iso19139 schema, we include the file containing the extensions in the schema directory and in the schema.xsd file. An example from the MCP is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace="http://bluenet3.antcrc.utas.edu.au/mcp" elementFormDefault="qualified"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp"
        xmlns:gmd="http://www.isotc211.org/2005/gmd"
        xmlns:srv="http://www.isotc211.org/2005/srv">
  <xs:include schemaLocation="schema/extensions/mcpExtensions.xsd"/>
  <xs:import namespace="http://www.isotc211.org/2005/srv" schemaLocation="schema/srv/srv.xsd"/>
</xs:schema>

A good way of beginning to define a profile is to copy one of the existing profiles to a new directory and make changes to that.

Depending on which elements you have extended, you will need to:

modify the XSLTs: extract-thumbnails.xsl, extract-uuid.xsl, index-fields.xsl, set-thumbnail.xsl, unset-thumbnail.xsl, update-fixed-info.xsl
modify the help file: loc/en/labels.xml – note you need only include in here help strings for the new elements you have added to your profile or any from the base standard that you would like to override. GN looks in the base standard help file for anything it can't find here. You will also need to add this file to the <gui> element of web/geonetwork/WEB-INF/config.xml and add your namespace to web/geonetwork/scripts/editor/tooltip.js.
add any new rules to the schematron file for the base standard (see the schematrons directory in your install) and regenerate the schematron.xsl and schematron_xml.xsl files.

2 – XSLT sheet for Rendering

GN uses metadata-iso19139.xsl to render iso19139 schema specific elements in HTML. Your profile will continue to use this because the bulk of the elements in your profile are the standard ones that GN already renders.

Following on from the naming convention given earlier, you would name your profile specific XSLT for rendering elements to HTML with the name of the profile included. So for the MCP profile of iso19139, you would use metadata-iso19139.mcp.xsl (this is not mandatory? - needs checking in profiling rules and GN).

In this XSLT you define templates to render:

any specific elements of your profile
any elements in the base standard that you want to override with different behaviours and
any profile specific tabs

You define the templates for your elements using the same mode as the base standard (in this case iso19139) and you use the namespace you adopted in your extension XSD. You will need to edit metadata-iso19139.xsl to include callbacks to profile specific tabs and to tell GN which tab is the 'simple' tab.

You need to include your profile specific XSLT renderer in metadata-utils.xsl.

You don't need to tell GN anything else here because GN assumes that any profile that starts with iso19139 (eg. iso19139.mcp) is iso19139 and you will have defined namespace specific actions for the new elements in your profile in your XSLT.

Proposal

Modifications to GN

in XSLT – altering schema= to schema.startsWith etc – done – need a profile_to_ISO XSLT that will process each element, convert back to iso19139 (using gco:isoType) and throw away elements belonging to the additional namespaces – result is iso19139
in Java – chase down all the schema guessing code – too often this is of the form (schema == 'iso19139') etc – doesn't take note of the fact that a profile may actually be supported locally. CSW and harvesting should apply a profile_to_ISO XSLT (one for all: uses gco:isoType attributes and drops elements with other namespaces) so that the record can be harvested etc

Installer packs for National Profiles

Why? Shouldn't be necessary to create a branch for profile support. Should be reasonably straight forward to create – maintenance (for maintainers) will be an overhead until callbacks for tab display are removed from metadata-iso19139.xsl under the EditorEnhancements proposal here: http://trac.osgeo.org/geonetwork/wiki/EditorEnhancements.

Backwards Compatibility Issues

Earlier versions need to be supported when harvesting from 2.3 by applying profile_to_ISO XSLT

Risks

Participants

As above

Note: See TracWiki for help on using the wiki.

Download in other formats:

Plain Text