[GeoNetwork-users] [GeoNetwork-devel] MCP versioning Question.

andrew_walsh · August 29, 2012, 6:51am

Hello Simon,

Putting this email trail out onto the GN users list as well as its going to effect anyone
now using the MCP schema when they migrate their exising records to new GN2.8

I have tested switching around the schema detection criteria in the schema-ident files as you have
suggested to Ian and this works fine by making mcp1.4 the default, not the experimental 1.5

So something with gmd:MetadataStandardVersion=MCP:Bluenet V1.4 loads up
as iso19139.mcp-1.4 schema and gmd:MetadataStandardVersion=1.5-experimental
loads up as iso19139.mcp (mcp 1.5 schema)

So in the mcp-1.4 schema-ident.xml we have:

<elements type="root">
   <mcp:MD_Metadata/>
  </elements>

</autodetect>

and in the mcp-1.5 experimental schema-ident.xml we have:

  <elements>
   <gmd:metadataStandardName>
    <gco:CharacterString>Australian Marine Community Profile of ISO 19115:2005/19139</gco:CharacterString>
   </gmd:metadataStandardName>
   <gmd:metadataStandardVersion>
    <gco:CharacterString>1.5-experimental</gco:CharacterString>
   </gmd:metadataStandardVersion>
  </elements>
</autodetect>

I will raise this change as a bug ticket and perhaps you or Ian could generate a patch file
(not sure how to do these patches yet) to add to the ticket for pushing up to the
GN source.

I just want to mention here some notes about how I am intending to migrate existing
metadata with BlueNet MEST v1.4.2 to the new GN 2.8. I will be exporting our existing
metadata to MEF files using geonetwork XML service and a Curl script and then
doing MEF import to the new GN again using Curl.

I have tested this process with
our existing/new GN and it works pretty well preserving most of the important
information such as change date, creation date, local ID, source=site uuid,
thumbnail and privileges (for records that were public). You do lose the original
"owner" and "group owner" of the record but these could be
restored on the new GN.

After this export/import process I still have the issue of fixing up the contents of
metadataStandardVersion element which we should standardise to 1.4.

Also I discovered recently some of our metadata records
(apparently only those MCP type record loaded by copy/paste XML load method which we frequently do)
have a faulty xsi:SchemaLocation inserted into the root element like:

xsi:schemaLocation="
				http://www.isotc211.org/2005/gmd/gmd.xsd http://www.isotc211.org/2005/srv/ http://schemas.opengis.net/iso/19139/20060504/srv/srv.xsd http://bluenet3.antcrc.utas.edu.au/mcp/schema.xsd
&\#x9;&\#x9;&\#x9;

This gets added as part of the copy/paste process but the xsi:schemaLocation lookup is invalid and
also its got some extra uneeded codes &#xA=LINEFEED and ;&#x9=TAB

(See for example http://www.metoc.gov.au/geonetwork/srv/en/metadata.show?id=3841&currTab=simple
and then click the Save as ISO19115/ISO1939 icon and do a File-Save As from the browser and open contents
of the text file, see the bad xsi:SchemaLocation)

This is something I would like to remove from the root element for those effected records,
another XML fix!

Given for the new version migration I would be doing a MEF export/import process what's the best way
for me to do these XML fixes? You mention the updatefixedinfo.xsl process.
Can this be used in a batch mode one the records are in the new system?

Thank and Regards,

Andrew

----- Original Message ----- From: <Simon.Pigot@anonymised.com>
To: <awalsh@anonymised.com>
Cc: <ianwallen@anonymised.com>; <geonetwork-devel@lists.sourceforge.net>; <greg@anonymised.com>
Sent: Wednesday, August 29, 2012 12:01 PM
Subject: RE: [GeoNetwork-devel] MCP versioning Question.

Hi Andrew,

Thanks for the info - yes, MD_Commons was introduced in 1.4 as a replacement for both MD_CreativeCommons and MD_DataCommons (it basically combines them into a single element).

If we switch the default schema to 1.4 in the schema plugins then they will all load as 1.4 records. If you want to fix the mapping to MD_Commons and version numbering (as well as schemalocation), it should be enough to run updatefixedinfo.xsl from the 1.4 schema on all your records - with a little bit of work this could also be done as a massive/batch xslt - best to open a ticket on this to make sure this is included and documented for MCP upgrades to 2.8.

Cheers,
Simon
________________________________________
From: andrew walsh [awalsh@anonymised.com]
Sent: Wednesday, 29 August 2012 11:17 AM
To: Pigot, Simon (CMAR, Hobart)
Cc: ianwallen; geonetwork-devel@lists.sourceforge.net; greg@anonymised.com
Subject: Re: [GeoNetwork-devel] MCP versioning Question.

Hi Simon,

I checked and our current production V1.4.2 MEST (installed 3/8/2010)
is using a pre 1.4 MCP version, like "MCP:BlueNet V1.3". The schema extension
file
that the production GN is using (attached) doesn't have a "mcp:MD_Commons"
element
type which I think was added for v1.4 so that narrows it down to pre v1.4
(correct
me if I am wrong?)

Actually if you read the comments in the header
of the schema extension file attached its a bit misleading because even though
its a pre V1.4 schema it says:

"This file contains extensions of the ISO19139 gmd schema
objects for the Australian Marine Community Profile Version 1.3-19139 and
1.4-19139"

I do recall being told around early 2011 when I started loaded all the metadata
that 1.4 or 1.5 would become the "official" schema. So following that lead
I set my gmd:MetadataStandardVersion to 1.4 or 1.5.

Actually I have at the moment:

"MCP:Bluenet version 1.5" - 1453 records
"MCP:Bluenet V1.4" - 308 records

Anyway, moving forward to the new 2.8 GN, lets be consistent,
they should all load as V1.4.

But how to to do this? Probably easiest for us is to do a massive
edit of the 'data' element in METADATA table in our Oracle db
changing the contents of gmd:MetadataStandardVersion to "1.4".
Tricky also because we would also have to update the
mcp:revisionDate element
and also the METADATA table 'change_date' to ensure our changes are properly
picked up by the AODN MEST harvestor. Sounds hard.

Could instead we craft some
kind of massive xslt that our V1.4.2 MEST could run?

Cheers,

Andrew

----- Original Message -----
From: <Simon.Pigot@anonymised.com>
To: <awalsh@anonymised.com>; <ianwallen@anonymised.com>
Cc: <greg@anonymised.com>; <geonetwork-devel@lists.sourceforge.net>
Sent: Tuesday, August 28, 2012 8:29 PM
Subject: RE: [GeoNetwork-devel] MCP versioning Question.

Hi Andrew,

Thanks for the suggestions - I think (correct me if I'm wrong) that we still
have the chance to use the version identifiers for 1.4 and 1.5-experimental I
mentioned in the response to Ian's email as most people using the MCP are
using MCP:Bluenet V1.3 in the BlueNetMEST 1.4.x software: they probably
haven't switched many records to 1.4 and/or 1.5-experimental as provided in
GeoNetwork/ANZMEST 2.8 as it is not yet production ready?

Cheers and thanks,
Simon
________________________________________
From: andrew walsh [awalsh@anonymised.com]
Sent: Tuesday, 28 August 2012 3:01 PM
To: ianwallen
Cc: greg@anonymised.com; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] MCP versioning Question.

Hello Ian and Simon,

Simon forgive me for commenting on this before your reply, but I
had come across a similar issue to Ian, so Ian thanks for raising this.
I also get metadata import as MCP-1.5 when I guess it's really MCP-1.4.

Our production GN at http://www.metoc.gov.au/geonetwork has used 2
different <gmd:MetadataStandardVersion>,
i.e we have not been consistent:

"MCP:Bluenet version 1.5"
"MCP:Bluenet V1.4"

Now the schema detection logic says :

IF MetadataStandardVersion=1.4 then load up as MCP1.4 record
ELSE Default to MCP1.5 record

So all of our existing MCP metadata records are going to end up as MCP1.5
on import to the newer 2.8 ANZMEST-GN. However maybe this unintended
version/schema
upgrade (1.4->1.5) is not such a bad thing because anything that is V1.4 is
valid
with the 1.5 schema.

Maybe its necessary to make the schema detection logic smarter i.e anything
with '1.4' as a sub-string gets MCP-1.4, anything with '1.5' gets MCP-1.5 and
anything not recognised defaults to MCP1.5. Any thoughts on this?

Looking forward to your replies....

Regards,

Andrew

PS: Ian,

I agree with what you are saying about the inconsistencies.
'MCP:BlueNet V1.4' is better than just '1.4'

----- Original Message -----
From: "ianwallen" <ianwallen@anonymised.com>
To: <geonetwork-devel@lists.sourceforge.net>
Sent: Monday, August 27, 2012 9:48 PM
Subject: [GeoNetwork-devel] MCP versioning Question.

Simon,

Is there a reason the 1.4 version of MCP is labeled (within
gmd:metadataStandardVersion) as "1.4" while the 1.5 is labeled as
"MCP:BlueNet V1.5". Shouldn't the 1.4 be labeled as "MCP:BlueNet V1.4"

Also, there also seems to be some inconsistencies...

The following use "MCP:BlueNet V1.4"
convert/OGCSOSGetCapabilitiesLayer-to-19139.xsl
convert/OGCSOSGetCapabilities-to-ISO19119_ISO19139.xsl

And the following use "1.4"
schema-ident.xml
update-fixed-info.xsl
template/thredds-harvester-unidata-data-discovery.xml

Here is a suggested patch if you agree that it should be named "MCP:BlueNet
V1.4"

http://osgeo-org.1560.n6.nabble.com/file/n4998050/mcp_1.4_version.patch
mcp_1.4_version.patch

One of the issues that I was encountering is that I cannot add an MCP 1.4
document to geonetworks via the file upload unless the versions matches
within the schema-ident.xml (otherwise it defaults to a MCP 1.5). All the
MCP records that I currently have use "MCP:BlueNet V1.4" within
gmd:metadataStandardVersion. They were all created with Bluenet MEST.
Although it is possible to change them from "MCP:BlueNet V1.4" to 1.4, I
would like to hear your input.

Thanks.

--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/MCP-versioning-Question-tp4998050.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork