[GeoNetwork-devel] proposal for change to schema detection logic

Stephen_M_Richard · February 3, 2010, 6:13pm

Dear Geonetwork team–
We are testing a modification of the GeoNetwork schema detection algorithm to use the ISO19139 metadataStandardName and version information to identify use of a conformance level one profile. We would like to see this logic added to the trunk build.

The logic will not break the currently used approach; it will add some additional tests, and its use will depend on adding an annotation/appinfo element in the schema.xsd schema that is in the root of each profile configuration directory in %geonetworkroot%/web/geonetwork/xml/schemas. The design would allow for profiles of other base metadata schema as well, if the profile provides a means of self identification. The attached document describes the logic in more detail, and a flow chart for the logic is shown below.

Dominic Owen, who has been posting some here recently, is working with our project (USGIN http://lab.usgin.org) is doing the programming, currently working in a local sandbox.

We will research the procedure for a formal request, but wanted to get the idea out for consideration now…

thanks
steve

schema detection logic flow diagram

(attachments)

schemaAndProfileDetection.doc (59 KB)

···

-- 
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone: 
Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: [steve.richard@anonymised.com](mailto:steve.richard@anonymised.com)

sppigot · February 3, 2010, 11:04pm

Hi Stephen et al,

Thanks for the document and description - looks like it covers most of the stuff I know about in conformance level 1 - adding the appinfo stuff to the schema.xsd (ie. GN only, leaves base xsds untouched etc) seems like a good idea and workable - also should work for other schemas apart from ISO as well.

Do you have an example of a conformance level 2 profile (ie. root element known but its namespace uri is not the standard namespace uri)?

I'd like to integrate this into the trunk after testing it - we have a profile test case that would be nice to try out.

Cheers and thanks,
Simon
________________________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 5:13 AM
To: GeoNetwork-devel@lists.sourceforge.net; dominic.owen; Wolfgang Grunberg
Subject: [GeoNetwork-devel] proposal for change to schema detection logic

Dear Geonetwork team--
We are testing a modification of the GeoNetwork schema detection algorithm to use the ISO19139 metadataStandardName and version information to identify use of a conformance level one profile. We would like to see this logic added to the trunk build.

The logic will not break the currently used approach; it will add some additional tests, and its use will depend on adding an annotation/appinfo element in the schema.xsd schema that is in the root of each profile configuration directory in %geonetworkroot%/web/geonetwork/xml/schemas. The design would allow for profiles of other base metadata schema as well, if the profile provides a means of self identification. The attached document describes the logic in more detail, and a flow chart for the logic is shown below.

Dominic Owen, who has been posting some here recently, is working with our project (USGIN http://lab.usgin.org) is doing the programming, currently working in a local sandbox.

We will research the procedure for a formal request, but wanted to get the idea out for consideration now..

thanks
steve

[cid:part1.04080002.09050108@anonymised.com]

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com<mailto:steve.richard@anonymised.com>

Stephen_M_Richard · February 3, 2010, 11:26pm

Simon--
the MEST-Blue Net profile schema from the BlueNet GeoNetwork branch is the exemplar we were looking at for a conformance level 2 profile, with root element MD_Metadata with a different namespace URI xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp" as served from http://mest.ivec.org/geonetwork/srv/en/main.home. You're familiar with this project, I believe?

Glad to hear you'd like to integrate into the trunk; we're still debugging, but we'll keep you posted.
thanks
steve

On 2/3/2010 4:04 PM, Simon.Pigot@anonymised.com wrote:

Hi Stephen et al,

Thanks for the document and description - looks like it covers most of the stuff I know about in conformance level 1 - adding the appinfo stuff to the schema.xsd (ie. GN only, leaves base xsds untouched etc) seems like a good idea and workable - also should work for other schemas apart from ISO as well.

Do you have an example of a conformance level 2 profile (ie. root element known but its namespace uri is not the standard namespace uri)?

I'd like to integrate this into the trunk after testing it - we have a profile test case that would be nice to try out.

Cheers and thanks,
Simon
________________________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 5:13 AM
To: GeoNetwork-devel@lists.sourceforge.net; dominic.owen; Wolfgang Grunberg
Subject: [GeoNetwork-devel] proposal for change to schema detection logic

Dear Geonetwork team--
We are testing a modification of the GeoNetwork schema detection algorithm to use the ISO19139 metadataStandardName and version information to identify use of a conformance level one profile. We would like to see this logic added to the trunk build.

The logic will not break the currently used approach; it will add some additional tests, and its use will depend on adding an annotation/appinfo element in the schema.xsd schema that is in the root of each profile configuration directory in %geonetworkroot%/web/geonetwork/xml/schemas. The design would allow for profiles of other base metadata schema as well, if the profile provides a means of self identification. The attached document describes the logic in more detail, and a flow chart for the logic is shown below.

Dominic Owen, who has been posting some here recently, is working with our project (USGIN http://lab.usgin.org) is doing the programming, currently working in a local sandbox.

We will research the procedure for a formal request, but wanted to get the idea out for consideration now..

thanks
steve

[cid:part1.04080002.09050108@anonymised.com]

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com<mailto:steve.richard@anonymised.com>

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com

sppigot · February 3, 2010, 11:42pm

Yep - definitely familiar with that The algorithm might need a bit more work then as we have different versions of this profile and would need to check the profile and version numbers.

Cheers and thanks,
Simon
____________ ____________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 10:26 AM
To: Pigot, Simon (CMAR, Hobart)
Cc: GeoNetwork-devel@lists.sourceforge.net; dominic.owen@anonymised.com; wgrunberg@anonymised.com
Subject: Re: [GeoNetwork-devel] proposal for change to schema detection logic

Simon--
the MEST-Blue Net profile schema from the BlueNet GeoNetwork branch is
the exemplar we were looking at for a conformance level 2 profile, with
root element MD_Metadata with a different namespace URI
xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp" as served from
http://mest.ivec.org/geonetwork/srv/en/main.home. You're familiar with
this project, I believe?

Glad to hear you'd like to integrate into the trunk; we're still
debugging, but we'll keep you posted.
thanks
steve

On 2/3/2010 4:04 PM, Simon.Pigot@anonymised.com wrote:

Hi Stephen et al,

Thanks for the document and description - looks like it covers most of the stuff I know about in conformance level 1 - adding the appinfo stuff to the schema.xsd (ie. GN only, leaves base xsds untouched etc) seems like a good idea and workable - also should work for other schemas apart from ISO as well.

Do you have an example of a conformance level 2 profile (ie. root element known but its namespace uri is not the standard namespace uri)?

I'd like to integrate this into the trunk after testing it - we have a profile test case that would be nice to try out.

Cheers and thanks,
Simon
________________________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 5:13 AM
To: GeoNetwork-devel@lists.sourceforge.net; dominic.owen; Wolfgang Grunberg
Subject: [GeoNetwork-devel] proposal for change to schema detection logic

Dear Geonetwork team--
We are testing a modification of the GeoNetwork schema detection algorithm to use the ISO19139 metadataStandardName and version information to identify use of a conformance level one profile. We would like to see this logic added to the trunk build.

The logic will not break the currently used approach; it will add some additional tests, and its use will depend on adding an annotation/appinfo element in the schema.xsd schema that is in the root of each profile configuration directory in %geonetworkroot%/web/geonetwork/xml/schemas. The design would allow for profiles of other base metadata schema as well, if the profile provides a means of self identification. The attached document describes the logic in more detail, and a flow chart for the logic is shown below.

Dominic Owen, who has been posting some here recently, is working with our project (USGIN http://lab.usgin.org) is doing the programming, currently working in a local sandbox.

We will research the procedure for a formal request, but wanted to get the idea out for consideration now..

thanks
steve

[cid:part1.04080002.09050108@anonymised.com]

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com<mailto:steve.richard@anonymised.com>

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com

stephen_richard · February 4, 2010, 5:45am

I was thinking about that this afternoon. How are you self-identifying conformance to profile versions--metadataStandardVersion? If metadataStandardName is reliably used then checking the namespaces wouldn't be necessary, but a conformance level 2 profile would have to include the metadataStandardName and metadataStandardVersion elements--they would be mandatory in any versioned profile.

alternatively, the logic could run that if its a known root element and different namespace URI, then the annotation/appinfo child elements are used (if present) to identify the document element that should contain standardName and version identfiers. This would be trickier to code...

steve

On 2/3/2010 4:42 PM, Simon.Pigot@anonymised.com wrote:

Yep - definitely familiar with that The algorithm might need a bit more work then as we have different versions of this profile and would need to check the profile and version numbers.

Cheers and thanks,
Simon
____________ ____________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 10:26 AM
To: Pigot, Simon (CMAR, Hobart)
Cc: GeoNetwork-devel@lists.sourceforge.net; dominic.owen@anonymised.com; wgrunberg@anonymised.com
Subject: Re: [GeoNetwork-devel] proposal for change to schema detection logic

Simon--
the MEST-Blue Net profile schema from the BlueNet GeoNetwork branch is
the exemplar we were looking at for a conformance level 2 profile, with
root element MD_Metadata with a different namespace URI
xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp" as served from
http://mest.ivec.org/geonetwork/srv/en/main.home. You're familiar with
this project, I believe?

Glad to hear you'd like to integrate into the trunk; we're still
debugging, but we'll keep you posted.
thanks
steve

On 2/3/2010 4:04 PM, Simon.Pigot@anonymised.com wrote:

Hi Stephen et al,

Thanks for the document and description - looks like it covers most of the stuff I know about in conformance level 1 - adding the appinfo stuff to the schema.xsd (ie. GN only, leaves base xsds untouched etc) seems like a good idea and workable - also should work for other schemas apart from ISO as well.

Do you have an example of a conformance level 2 profile (ie. root element known but its namespace uri is not the standard namespace uri)?

I'd like to integrate this into the trunk after testing it - we have a profile test case that would be nice to try out.

Cheers and thanks,
Simon
________________________________________
From: Stephen M Richard [steve.richard@anonymised.com]
Sent: Thursday, 4 February 2010 5:13 AM
To: GeoNetwork-devel@lists.sourceforge.net; dominic.owen; Wolfgang Grunberg
Subject: [GeoNetwork-devel] proposal for change to schema detection logic

Dear Geonetwork team--
We are testing a modification of the GeoNetwork schema detection algorithm to use the ISO19139 metadataStandardName and version information to identify use of a conformance level one profile. We would like to see this logic added to the trunk build.

The logic will not break the currently used approach; it will add some additional tests, and its use will depend on adding an annotation/appinfo element in the schema.xsd schema that is in the root of each profile configuration directory in %geonetworkroot%/web/geonetwork/xml/schemas. The design would allow for profiles of other base metadata schema as well, if the profile provides a means of self identification. The attached document describes the logic in more detail, and a flow chart for the logic is shown below.

Dominic Owen, who has been posting some here recently, is working with our project (USGIN http://lab.usgin.org) is doing the programming, currently working in a local sandbox.

We will research the procedure for a formal request, but wanted to get the idea out for consideration now..

thanks
steve

[cid:part1.04080002.09050108@anonymised.com]

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com<mailto:steve.richard@anonymised.com>

--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard@anonymised.com