[GeoNetwork-devel] MCP versioning Question.

Ian_Allen · August 27, 2012, 11:48am

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.

andrew_walsh · August 28, 2012, 5:01am

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

sppigot · August 28, 2012, 10:17am

Hi Ian,

MCP:BlueNet V1.x is a carry over from the BlueNet project and was originally intended to show that that version of the MCP was a BlueNet extension of the MCP standard. BlueNet project is finished now so it's time to introduce some consistency and tidy up the schema plugins accordingly:

1. My feeling is that Version 1.4 MCP records should have metadataStandardVersion element and schema-ident set to 1.4 as the schema in GN is supposed to match the official 1.4 version of the standard as adopted by the committee.

2. Version 1.5 is actually an experimental version of 1.4 - it is used to test extensions that might be considered by the committee for 1.5 (mostly things I have been working on for various projects) - at present 1.4 records will validate against the 1.5 schema. I think metadataStandardVersion and schema-ident should be set to 1.5-experimental in order to distinguish this experimental version from a future version 1.5.

Let me know how what you think (as well as other MCP users think) - it's the right time to get these consistent now.

Cheers,
Simon
________________________________________
From: ianwallen [ianwallen@anonymised.com]
Sent: Monday, 27 August 2012 9:48 PM
To: geonetwork-devel@lists.sourceforge.net
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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

sppigot · August 28, 2012, 10:29am

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
geonetwork-devel List Signup and Options
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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

Ian_Allen · August 28, 2012, 2:44pm

Simon,

I don't disagree with how you want to cleanup the versions - it sounds
logical.

The one thing I currently don't particularly care for is defaulting to 1.5
experimental when it cannot be detected. I would rather get an error so that
I can choose the version assignment.

My main concern is how are we expected to migrated between systems without
loosing the version number.

- Do we manually do a search and replace of all XML documented prior to
loading them.

- Do we apply a fix (similar to Andrew's suggestion) where instead of
looking for the exact match of
<gco:CharacterString>1.4</gco:CharacterString> we look for the element
containing 1.4 similar to <gco:CharacterString>*1.4*</gco:CharacterString>

- Do we attempt to use a simple xslt to convert Bluenet:MCP to MCP so that
the conversion can be done during the load?

- Other....

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

andrew_walsh · August 29, 2012, 1:17am

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

(attachments)

mcpExtensions.xsd.txt (14.2 KB)

sppigot · August 29, 2012, 1:41am

Ian,

Yes, 1.4 should be the default MCP schema. So probably simplest then to reverse the current behaviour and set mcp-1.4 as the metadata schema for MCP records that don't have metadataStandardVersion value = 1.5-experimental. This is done by using a root element identifier rule in the 1.4 schema-ident and a specific metadataStandardVersion element vale rule in the 1.5-experimental schema-ident. That way you don't actually have to do anything to your records - they will be assigned to the 1.4 schema by default.

Cheers,
Simon

________________________________________
From: ianwallen [ianwallen@anonymised.com]
Sent: Wednesday, 29 August 2012 12:44 AM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] MCP versioning Question.

Simon,

I don't disagree with how you want to cleanup the versions - it sounds
logical.

The one thing I currently don't particularly care for is defaulting to 1.5
experimental when it cannot be detected. I would rather get an error so that
I can choose the version assignment.

My main concern is how are we expected to migrated between systems without
loosing the version number.

- Do we manually do a search and replace of all XML documented prior to
loading them.

- Do we apply a fix (similar to Andrew's suggestion) where instead of
looking for the exact match of
<gco:CharacterString>1.4</gco:CharacterString> we look for the element
containing 1.4 similar to <gco:CharacterString>*1.4*</gco:CharacterString>

- Do we attempt to use a simple xslt to convert Bluenet:MCP to MCP so that
the conversion can be done during the load?

- Other....

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MCP-versioning-Question-tp4998050p4998338.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 GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

sppigot · August 29, 2012, 2:01am

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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at
GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

------------------------------------------------------------------------------
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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at
GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

Ian_Allen · August 29, 2012, 12:14pm

Simon,

This will correct the current issue however I'm still not sure if this is
the best way to go. Here are some issues.

- If loading a 1.3 (or earlier) file it will change it to 1.4 - but I'm not
100% sure how backward compatible these are - This seems to be the same
issue that we are having but with earlier versions.
- When 1.5 becomes final, I'm assuming that this will then become the
default - which will reintroduce the same issues.
- If 1.5 schema/profile is loaded but not the 1.4, then there will not be
any defaults

I think a better fix would be to allow better condition processing in the
schema-ident.xml.

I believe this is the kind of logic we are looking for.

If gmd:metadataStandardVersion is null then default (Suggesting 1.5 because
if 1.4 is not loaded this will still work)
else if gmd:metadataStandardVersion contains 1.4 then 1.4
else if gmd:metadataStandardVersion contains 1.5 then 1.5
else not identified - so produce an error. (We could create an XSL that the
users could use during the load for performing upgrades between versions)

This way, if 1.6 was to be release and we did not support it then the user
would get an error. Same if they try to upload a older version. Which to me
sounds correct since we don't support those versions.

Maybe the schema-ident.xml could support calling an xsl like is-schema.xsl
which would return a true or false if the record belongs to that schema. As
it would be calling an XSL, there would be greater control in determining
the proper schema.

Another thing, that I just noticed, is a little weird with the current setup
schema/profile setup is that it requires that 1.5 be loaded in order to
load the 1.4. So basically the production 1.4 depends on a development
version 1.5 (weird). When a 1.6 release would be available, does this mean
the 1.4 will depend on 1.5 which will depend on 1.6 - which means that for
us to upgrade any changes to the 1.4, we would need to remove the 1.4, 1.5
schema profile and then load all 3 in the correct order? I guest that maybe
we are hoping that by the time 1.6 comes out, 1.4 will not longer be used?

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

sppigot · August 29, 2012, 1:59pm

Hi Ian,

On backwards compatibility of MCP: 1.3 is valid in 1.4 which is valid in 1.5 so they are backwards compatible in terms of schema validation. However, to edit a 1.3 record that has been assigned to the 1.4 schema, you would need to first run update-fixed-info.xsl on the 1.3 record as the editing templates for 1.4 only refer to 1.4 elements.

Rules for schema ident: At the moment the rules for schema identification are applied such that the most specific rule that matches a record will get a match - so for example searching for an attribute+value or element+value will take precedence over a more 'general' rule such as the name of the root element. The idea here was to get a flexible and fast set of rules (in JDOM) for identifying the schema to which a record belongs as opposed to having to run multiple XSLTs especially as the schema ident process is run every time a record is imported/harvested (ie. perf would need to be investigated if we changed from the JDOM rules to XSLTs).

Returning to MCP: Given the backwards compatibility of the MCP schemas, the idea was to assign records that are nominally MCP (by root element in mcp namespace) but that don't match a specific version to the official version (1.4 is the official version). However as you say this could cause problems in the future when 1.5 becomes the official version as sites that don't upgrade will find that if they harvest 1.5 records they will be assigned to 1.4 - not what we or they would want as elements from 1.5 won't necessarily work in 1.4.

Back to rules for schema ident: rather than an XSLT, how about a regular expression on the element values? That way we could be more specific about the records that will be assigned to a particular schema than the root element rule and avoid the problems mentioned above.

Cheers,
Simon

________________________________________
From: ianwallen [ianwallen@anonymised.com]
Sent: Wednesday, 29 August 2012 10:14 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] MCP versioning Question.

Simon,

This will correct the current issue however I'm still not sure if this is
the best way to go. Here are some issues.

- If loading a 1.3 (or earlier) file it will change it to 1.4 - but I'm not
100% sure how backward compatible these are - This seems to be the same
issue that we are having but with earlier versions.
- When 1.5 becomes final, I'm assuming that this will then become the
default - which will reintroduce the same issues.
- If 1.5 schema/profile is loaded but not the 1.4, then there will not be
any defaults

I think a better fix would be to allow better condition processing in the
schema-ident.xml.

I believe this is the kind of logic we are looking for.

If gmd:metadataStandardVersion is null then default (Suggesting 1.5 because
if 1.4 is not loaded this will still work)
else if gmd:metadataStandardVersion contains 1.4 then 1.4
else if gmd:metadataStandardVersion contains 1.5 then 1.5
else not identified - so produce an error. (We could create an XSL that the
users could use during the load for performing upgrades between versions)

This way, if 1.6 was to be release and we did not support it then the user
would get an error. Same if they try to upload a older version. Which to me
sounds correct since we don't support those versions.

Maybe the schema-ident.xml could support calling an xsl like is-schema.xsl
which would return a true or false if the record belongs to that schema. As
it would be calling an XSL, there would be greater control in determining
the proper schema.

Another thing, that I just noticed, is a little weird with the current setup
schema/profile setup is that it requires that 1.5 be loaded in order to
load the 1.4. So basically the production 1.4 depends on a development
version 1.5 (weird). When a 1.6 release would be available, does this mean
the 1.4 will depend on 1.5 which will depend on 1.6 - which means that for
us to upgrade any changes to the 1.4, we would need to remove the 1.4, 1.5
schema profile and then load all 3 in the correct order? I guest that maybe
we are hoping that by the time 1.6 comes out, 1.4 will not longer be used?

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MCP-versioning-Question-tp4998050p4998578.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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at GeoNetwork - Geographic Metadata Catalog download | SourceForge.net

sppigot · August 29, 2012, 2:39pm

Ian,

On the 'weirdness' of 1.4 being dependent on 1.5-experimental :-): The experimental schema is supposed to contain features that MCP users should evaluate for inclusion in future versions of the MCP. Difficult to get anyone to use these things but very important as they are often only really understood when it comes to using them. So the idea here is to kind of 'make' everyone install the 1.5-experimental schema so that they can check out these things. Keep in mind that (a) we've just changed the default schema to 1.4 (b) 1.5-experimental only adds some new elements to 1.4 (there are no changes to existing elements) (c) I had hoped that 1.5-experimental would be 1.5 official by now - this hasn't happened because I'm not sure whether some of the new elements constitute 'best practice' yet so they haven't been presented to the MCP governance committee (eg. those used for taxonomic extent/coverage).

Cheers,
Simon
________________________________________
From: ianwallen [ianwallen@anonymised.com]
Sent: Wednesday, 29 August 2012 10:14 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] MCP versioning Question.

Simon,

This will correct the current issue however I'm still not sure if this is
the best way to go. Here are some issues.

- If loading a 1.3 (or earlier) file it will change it to 1.4 - but I'm not
100% sure how backward compatible these are - This seems to be the same
issue that we are having but with earlier versions.
- When 1.5 becomes final, I'm assuming that this will then become the
default - which will reintroduce the same issues.
- If 1.5 schema/profile is loaded but not the 1.4, then there will not be
any defaults

I think a better fix would be to allow better condition processing in the
schema-ident.xml.

I believe this is the kind of logic we are looking for.

If gmd:metadataStandardVersion is null then default (Suggesting 1.5 because
if 1.4 is not loaded this will still work)
else if gmd:metadataStandardVersion contains 1.4 then 1.4
else if gmd:metadataStandardVersion contains 1.5 then 1.5
else not identified - so produce an error. (We could create an XSL that the
users could use during the load for performing upgrades between versions)

This way, if 1.6 was to be release and we did not support it then the user
would get an error. Same if they try to upload a older version. Which to me
sounds correct since we don't support those versions.

Maybe the schema-ident.xml could support calling an xsl like is-schema.xsl
which would return a true or false if the record belongs to that schema. As
it would be calling an XSL, there would be greater control in determining
the proper schema.

Another thing, that I just noticed, is a little weird with the current setup
schema/profile setup is that it requires that 1.5 be loaded in order to
load the 1.4. So basically the production 1.4 depends on a development
version 1.5 (weird). When a 1.6 release would be available, does this mean
the 1.4 will depend on 1.5 which will depend on 1.6 - which means that for
us to upgrade any changes to the 1.4, we would need to remove the 1.4, 1.5
schema profile and then load all 3 in the correct order? I guest that maybe
we are hoping that by the time 1.6 comes out, 1.4 will not longer be used?

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MCP-versioning-Question-tp4998050p4998578.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
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Ian_Allen · August 29, 2012, 5:42pm

Simon,

I now have a greater understand on why it is as it is. Thank you for the
detail explanation.

And, Yes, I think a regular expression on the element values would be a good
solution as it would allow us choose the correct version ("MCP:Bluenet V1.4"
or "1.4").
As for the default, I think that if we cannot detect the proper version,
then I would leave it as is and let it default to 1.5-experimental.

The only small concern that I may have is since we are not planning to add
support for 1.3 and below. If a user attempts to load a 1.3, should we bump
it up to a 1.4 or 1.5? i.e should the logic be as follows. If version is
"1\.[0-4]" then place it in the 1.4 schema else use the 1.5. Or should the
logic be - If version is "1\.4" then place it in the 1.4 schema else use the
1.5. As I don't have any 1.3 data, I'm not too concerned on the decision -
but I just wanted to put it up as a option.

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