Hi Kate,
Harvesting into another instance would not mean the record is invalid - the only place this would be checked is in the codelist schematron - it uses the URL provided to look up the codelist and check that the codelist value is actually in that codelist so as long as you supplied a valid URL it would be fine (many of these URLs can be mapped to local files if required as well).
The codelist URL wouldn't be changed unless the record was edited - usually shouldn't happen with harvested records.
Cheers,
Simon
________________________________________
From: Kate Roberts [K.Roberts@anonymised.com]
Sent: Tuesday, 12 November 2013 1:10 PM
To: Pigot, Simon (CMAR, Hobart); geonetwork-users@lists.sourceforge.net
Cc: geonetwork-devel@lists.sourceforge.net
Subject: RE: [GeoNetwork-devel] [GeoNetwork-users] Codelist url: hostname is enforced for each particular ISO19115 Profile? [SEC=UNCLASSIFIED]
Hi Simon,
Thanks for the quick reply, and for the advice.
I'll try that tonight.
As an aside, though, I am wondering what that means for my MCP record (once I've made the adjustment that you suggest), when it gets harvested into another instance of GeoNetwork, as an MCP record.
Would it be rejected as "invalid"?
Would it be converted, so that the URLS matched the "normal" MCP template?
As a failsafe, are these changes ones that would need to be done to the schema profile info that is (very usefully) rolled out as part of GN?
Kate
-----Original Message-----
From: Simon.Pigot@anonymised.com [mailto:Simon.Pigot@anonymised.com]
Sent: Tuesday, 12 November 2013 12:54 PM
To: Kate Roberts; geonetwork-users@lists.sourceforge.net
Cc: geonetwork-devel@lists.sourceforge.net
Subject: RE: [GeoNetwork-devel] [GeoNetwork-users] Codelist url: hostname is enforced for each particular ISO19115 Profile? [SEC=UNCLASSIFIED]
Hi Kate,
This all takes place in update-fixed-info.xsl for the specific metadata schema/profile you are using.
You could customize this behaviour in that XSLT so that only extended elements are given the profile specific codelist and the rest are given the standard codelist URL. You could do this by adding a template to that XSLT that matches the particular codelist URL (or adding extra conditions to the generic template that handles all codelists) and apply the appropriate URL there. In fact I think there is an example update-fixed-info.xsl for iso19139.anzlic that does that for MD_ScopeCode.
I suspect it is mostly using just one codelist URL to cut down on the amount of code/maintenance and because the profile codelist URLs include all the standard codelist items anyway. This could be modified to work in the way you want.
Cheers,
Simon
________________________________________
From: Kate Roberts [K.Roberts@anonymised.com]
Sent: Tuesday, 12 November 2013 12:12 PM
To: geonetwork-users@lists.sourceforge.net
Cc: Kate Roberts; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] [GeoNetwork-users] Codelist url: hostname is enforced for each particular ISO19115 Profile? [SEC=UNCLASSIFIED]
Dear colleagues:
When editting using a profile (ANZLIC or MCP), GeoNetwork seems to enforce a particular base hostname, for all codelist urls.
For instance:
for MD_KeywordTypeCode, within a record copied from the ANZLIC Profile template, the codelist value* starts as http://asdd.ga.gov.au…
E.g.
<gmd:MD_KeywordTypeCode codeList="http://asdd.ga.gov.au/asdd/profileinfo/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="discipline"/>
And when I amend it, using the XML editor, to ISO Standards Maintenance Portal
and try to save it, the hostname is changed back to http://asdd.ga.gov.au…
(Testing has been on some earlier GeoNetwork versions, and 2.10, using just the ANZLIC and MCP Profiles)
* And all the codelist values, in an ANZLIC Profile record, are made to have that hostname of
http://asdd.ga.gov.au/asdd/profileinfo/gmxCodelists.xml#
When creating an MCP record, all codelist values are made to have a hostname of
"http://bluenet3.antcrc.utas.edu.au/mcp-1.5-experimental/schema/resources/Codelist/gmxCodelists.xml#
so MD_KeywordTypeCode is
<gmd:MD_KeywordTypeCode codeList="http://bluenet3.antcrc.utas.edu.au/mcp-1.5-experimental/schema/resources/Codelist/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="discipline"/>
Ideally (unless there are standards/rules, or other good reasons against it), we would like to use the ISO codelist url [ http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml\],
A) within profiles, for codelists that have not been altered within that profile.
B) within profiles, for codelists that HAVE been altered within that profile, but the term being used is in the original 19115 codelist.
That is:
if the MCP Profile extends the MD_KeywordTypeCode by adding the term "dataParam", then within one MCP record, when applying a KeywordTypeCode term that is in the original ISO19115 codelist (such as 'discipline' or 'place'), we'd like to use <gmd:MD_KeywordTypeCode codeList="ISO Standards Maintenance Portal; codeListValue="discipline"/>
But when using the MCP-introduced term of "dataParam", we would want to use:
<gmd:MD_KeywordTypeCode codeList="http://bluenet3.antcrc.utas.edu.au/mcp-1.5-experimental/schema/resources/Codelist/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="discipline"/>
If we have to regularly produce 3 Profile versions of a record (ANZLIC, MCP and WMO Profiles), it makes sense (and seems to be more interoperability-friendly) to only use a Profile-specific codelist url where the term being used is Profile-specific.
Is there is a rule, within ISO19139 or ISO19115, that says that the codelist [hostname] can be defined, and then must be consistent throughout the record.
(I haven't been able to find it, but others may know of a rule that justifies GeoNetwork's behaviour?)
Kate
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
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
