Hi
I have exported a MEF file with an online resource attached (using a GN version based on master), the MEF file contains in private folder this file, and xml the reference to resources.get service:
http://ORIGINSERVER/geonetwork/srv/eng/resources.get?id=11&fname=file.zip&access=private
When is imported in another server I see the file available in data folder, but the onlineresource still references to ORIGINSERVER.I expected the url was updated in the import to reference to the server where has been imported.
Otherwise seem to me a bit useless, unless I’m missing something?
Thanks and regards,
Jose García
–
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net
Jesse,
I believe the update-fixed-info.xsl will fix the references. But I don't
think it is executed when performing and import from a file.
I just did a test where I imported the sample iso19139 data into a test
server. I then edited the "Physiographic Map of North and Central Eurasia
(Sample record, please remove!)" It contains " phy.zip" which defaults to
"localhost" - but soon as I hit save (which executes the
update-fixed-info.xsl) the hostname changes to my test server.
In your case (assuming you have hundreds of records in your MEF file) I'm
not sure how you would go about having them all run thought the
update-fixed-info.xsl. Editing and saving the records via the web does not
seem practical. I would be interested in seeing how this can be done...
Maybe we should log a ticket that would allow the update-fixed-info.xsl to
be executed during file imports (maybe as an option).
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MEF-import-with-online-resources-tp5027792p5027906.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
but that would also have other effects, such as updating the metadata datestamp, which is possibly not what you want when importing.
I think the ticket should ask for this reference update to be moved to a dedicated xslt, which is invoked both at import and from update-fixed-info.
Kind regards
Heikki doeleman
On Wed, Jan 16, 2013 at 6:41 PM, ianwallen <ianwallen@anonymised.com> wrote:
Jesse,
I believe the update-fixed-info.xsl will fix the references. But I don’t
think it is executed when performing and import from a file.
I just did a test where I imported the sample iso19139 data into a test
server. I then edited the “Physiographic Map of North and Central Eurasia
(Sample record, please remove!)” It contains " phy.zip" which defaults to
“localhost” - but soon as I hit save (which executes the
update-fixed-info.xsl) the hostname changes to my test server.
In your case (assuming you have hundreds of records in your MEF file) I’m
not sure how you would go about having them all run thought the
update-fixed-info.xsl. Editing and saving the records via the web does not
seem practical. I would be interested in seeing how this can be done…
Maybe we should log a ticket that would allow the update-fixed-info.xsl to
be executed during file imports (maybe as an option).
–
View this message in context: http://osgeo-org.1560.n6.nabble.com/MEF-import-with-online-resources-tp5027792p5027906.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122612
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
Heikki,
You bring a good point. But in my opinion, if the document is changed (even
if it is the reference url) then this is a change and the datestamp should
be updated. But I guess it could depends on the usage.
One example would be a system migration - When migrating system and this is
the only change then I kind of agree with you since the old site will be
shutdown and the old reference would not make any sense. Another example
could be changing the hostname of the server in which a new url will be used
and the old one will no longer be valid. In these cases I also don't see any
problem with performing the change without updating the datestamp.
If making copy from a master site then I don't see a problem with changing
the datestamp since it is not an authoritative copy.
When harvesting the data, should it point to the original data or the
current site? I always thought harvesting was supposed to have a mirror copy
of the original (unless edited).
Anyway - I'm visualizing updating the import interface as follows
- Add an option to the import interface for the following.
- run the update fix (update-fixed-info.xsl)
- update url only (update-url-info.xsl)(NEW)
- import as is - no changes (default)
- Add option regarding the datestamp
- update datestamp (update-date-info.xsl)(NEW)
- do not update datestamp (default)
And similar option can exist in the harvester setting.
Note: I'm assuming that you mean the metadata datestamp in the database and
not the datestamp in the file since the datestamp in the iso19139 is a
created date and that should not change (even thought it currently is for
harvesting purposes.)
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MEF-import-with-online-resources-tp5027792p5027989.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
Hi Ian and Heikki,
Having an option to update/not update the online resource URL
on mef import would be useful.
Its important in this discussion to not get confused between the 'database
changeDate' and the 'gmd:dateStamp' in the XML metadata.
My understanding was that the 'geonetwork protocol' harvester
in deciding whether or not to harvest a record uses the 'database changeDate'
and not the gmd:dateStamp. For example see this post I made last year
on Nov 2:
http://osgeo-org.1560.n6.nabble.com/Question-on-regarding-dateStamp-in-iso-19139-td5011273i20.html#a5013438
I recall some discussion that the 'CSW harvester' did something different and
used the gmd:dateStamp? but that was not clear to me.
Regards,
Andrew
----- Original Message ----- From: "ianwallen" <ianwallen@anonymised.com>
To: <geonetwork-devel@lists.sourceforge.net>
Sent: Thursday, January 17, 2013 10:12 AM
Subject: Re: [GeoNetwork-devel] MEF import with online resources
Heikki,
You bring a good point. But in my opinion, if the document is changed (even
if it is the reference url) then this is a change and the datestamp should
be updated. But I guess it could depends on the usage.
One example would be a system migration - When migrating system and this is
the only change then I kind of agree with you since the old site will be
shutdown and the old reference would not make any sense. Another example
could be changing the hostname of the server in which a new url will be used
and the old one will no longer be valid. In these cases I also don't see any
problem with performing the change without updating the datestamp.
If making copy from a master site then I don't see a problem with changing
the datestamp since it is not an authoritative copy.
When harvesting the data, should it point to the original data or the
current site? I always thought harvesting was supposed to have a mirror copy
of the original (unless edited).
Anyway - I'm visualizing updating the import interface as follows
- Add an option to the import interface for the following.
- run the update fix (update-fixed-info.xsl)
- update url only (update-url-info.xsl)(NEW)
- import as is - no changes (default)
- Add option regarding the datestamp
- update datestamp (update-date-info.xsl)(NEW)
- do not update datestamp (default)
And similar option can exist in the harvester setting.
Note: I'm assuming that you mean the metadata datestamp in the database and
not the datestamp in the file since the datestamp in the iso19139 is a
created date and that should not change (even thought it currently is for
harvesting purposes.)
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/MEF-import-with-online-resources-tp5027792p5027989.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
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
Hi
Not sure if really required about the option to update/not update the online resource URL on mef import, I mean if the mef file includes the file referenced in an online resource, then I think can be updated automatically. Note that I only talk about change online resource URL that uses the service resource.get from GeoNetwork.
Andrew, about the date the issue now is that GeoNetwork handles change date both db and gmd:dateStamp to be the same. So for example CSW harvester uses gmd:dateStamp as metadata change date for now.
Regards,
Jose García
On Thu, Jan 17, 2013 at 3:23 AM, andrew walsh <awalsh@anonymised.com65…> wrote:
Hi Ian and Heikki,
Having an option to update/not update the online resource URL
on mef import would be useful.
Its important in this discussion to not get confused between the ‘database
changeDate’ and the ‘gmd:dateStamp’ in the XML metadata.
My understanding was that the ‘geonetwork protocol’ harvester
in deciding whether or not to harvest a record uses the ‘database changeDate’
and not the gmd:dateStamp. For example see this post I made last year
on Nov 2:
http://osgeo-org.1560.n6.nabble.com/Question-on-regarding-dateStamp-in-iso-19139-td5011273i20.html#a5013438
I recall some discussion that the ‘CSW harvester’ did something different and
used the gmd:dateStamp? but that was not clear to me.
Regards,
Andrew
----- Original Message -----
From: “ianwallen” <ianwallen@anonymised.com>
To: <geonetwork-devel@lists.sourceforge.net>
Sent: Thursday, January 17, 2013 10:12 AM
Subject: Re: [GeoNetwork-devel] MEF import with online resources
Heikki,
You bring a good point. But in my opinion, if the document is changed (even
if it is the reference url) then this is a change and the datestamp should
be updated. But I guess it could depends on the usage.
One example would be a system migration - When migrating system and this is
the only change then I kind of agree with you since the old site will be
shutdown and the old reference would not make any sense. Another example
could be changing the hostname of the server in which a new url will be used
and the old one will no longer be valid. In these cases I also don’t see any
problem with performing the change without updating the datestamp.
If making copy from a master site then I don’t see a problem with changing
the datestamp since it is not an authoritative copy.
When harvesting the data, should it point to the original data or the
current site? I always thought harvesting was supposed to have a mirror copy
of the original (unless edited).
Anyway - I’m visualizing updating the import interface as follows
- Add an option to the import interface for the following.
- run the update fix (update-fixed-info.xsl)
- update url only (update-url-info.xsl)(NEW)
- import as is - no changes (default)
- Add option regarding the datestamp
- update datestamp (update-date-info.xsl)(NEW)
- do not update datestamp (default)
And similar option can exist in the harvester setting.
Note: I’m assuming that you mean the metadata datestamp in the database and
not the datestamp in the file since the datestamp in the iso19139 is a
created date and that should not change (even thought it currently is for
harvesting purposes.)
–
View this message in context:
http://osgeo-org.1560.n6.nabble.com/MEF-import-with-online-resources-tp5027792p5027989.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122612
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
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only – learn more at:
http://p.sf.net/sfu/learnmore_122712
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
–
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net