Andrew,
I implemented a change sometime ago that extracts the modification date from the metadata schema in a customizable way for each schema - this is extract-date-modified.xsl and its iimplemented for each schema - so iso19139.mcp and iso19139.mcp-1.4 records should be using mcp:revisionDate in the CSW harvester when checking for updated records.
extract-date-modified.xsl for iso19139 uses gmd:dateStamp because (as everyone has already said) the dateStamp is used for this purpose in most implementations.
Cheers,
Simon
________________________________________
From: andrew walsh [awalsh@anonymised.com]
Sent: Wednesday, 31 October 2012 6:06 PM
To: tropicano@anonymised.com
Cc: geonetwork-devel@anonymised.com
Subject: Re: [GeoNetwork-devel] Question on regarding dateStamp in iso 19139
Hello Heikki, Ian, Simon, John, Annina and All,
Yes, Heikki to confirm I was talking about the 'Geonetwork' protocol harvester.
I had always thought the Geonetwork had used the database 'changeDate' in the
metadata table as a means to decide to harvest or not. This seemed logical to
me.
My reasoning for this thought is the BlueNet MEST version of Geonetwork
we have been using since August 2010 DOES NOT update the gmd:dateStamp when
records are edited/saved.
Looking at the update-fixed-info.xsl from the Bluenet MEST version 1.4.9
(14/10/2011) of GN
for the ISO19139-mcp schema it says:
<xsl:template match="gmd:dateStamp">
<xsl:choose>
<xsl:when test="/root/env/updateDateStamp='yes'">
<gmd:dateStamp>
<gco:DateTime><xsl:value-of select="/root/env/changeDate"/></gco:DateTime>
</gmd:dateStamp>
</xsl:when>
<xsl:otherwise>
<xsl:copy-of select="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
That is, only update the gmd:DateStamp if ="/root/env/updateDateStamp='yes'
which I never found occurring. How would the /root/env/updateDateStamp be set to
yes?
Simon, maybe you could help here.
Given that I never observed the gmd:DateStamp updating it never occurred to me
that this
would used by the harvester as check whether to harvest a record. So I assumed
the
harvester was looking rather at the database changeDate to decide whether to
harvest or not.
Whereas the core (International version) of Geonetwork from
v2.6.3 up until the current V2.8.0RC1 DOES update the gmd:dateStamp on edit/save
as recently noted by Ian Allen (thanks! Ian).
Looking at update-fixed-info.xsl in all these situations:
- GN v2.8.0RC1 with ISO19139 schema
- GN v2.8.0RC1 + ANZMEST 2.8.0RC1 with ISO19139 schema
- GN v2.8.0RC1 + ANZMEST 2.8.0RC1 with ISO19139-mcp1.4 schema
they all have:
<xsl:template match="gmd:dateStamp">
<xsl:choose>
<xsl:when test="/root/env/changeDate">
<xsl:copy>
<gco:DateTime>
<xsl:value-of select="/root/env/changeDate"/>
</gco:DateTime>
</xsl:copy>
</xsl:when>
<xsl:otherwise>
<xsl:copy-of select="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
Hi Simon,
Could you let me know your understanding of how the 'Geonetwork' protocol
harvester
decides whether to harvest or not in the older Geonetwork+BlueNet and more
recent
Geonetwork+ANZMEST versions?
It seems to me that the Geonetwork protocol harvester and CSW protocol harvester
could use the
database changeDate but maybe I am missing some point?
Regards All,
Andrew
Tuesday, 30 October 2012 21:22 Heikki Doeleman wrote"
hi Andrew,
by GN harvesters do you mean, GeoNetwork protocol harvesters ?
Those could use the database changedate, but currently they don't do that; if a
metadata with the same uuid as one in the >harvesting result exists, it is
overwritten, with no regard to timestamp.
CSW harvesting compares local client's dateStamp to the the metadata in the
harvesting result to decide whether to update or >to never mind, but if the
date element in the ISO19139 metadata is not guaranteed to be a
LastModificationDate (which seems >to be so from your previous emails in this
thread), then that update system should be considered broken, I guess, and we
>should rather ignore datestamps altogether and just replace metadata having
the same uuid as metadata in the harvest results.
Kind regards
Heikki Doeleman
----- Original Message -----
From: heikki
To: Annina Hirschi Wyss
Cc: ianwallen@anonymised.com ; geonetwork-devel@lists.sourceforge.net
Sent: Wednesday, October 31, 2012 12:48 AM
Subject: Re: [GeoNetwork-devel] Question on regarding dateStamp in iso 19139
.. just to clarify: I do not propose here to change the behaviour that
GeoNetwork uses this element as a last modification date; only to make the check
in CSW (and maybe other) harvester fool-proof to this in case the harvested
catalog does not use the element in this way.
On Tue, Oct 30, 2012 at 2:43 PM, heikki <tropicano@anonymised.com> wrote:
hi,
discussed briefly with François and created a ticket to change the behaviour:
#1124 (Unsafe update check in harvesters) – GeoNetwork opensource Developer website. Set for 2.8.0 as the change is
very small.
If people don't agree to this change, please comment in the ticket asap.
Kind regards
Heikki Doeleman
On Tue, Oct 30, 2012 at 2:15 PM, Annina Hirschi Wyss <annina.hirschi@anonymised.com...>
wrote:
Hi,
Some remarks from my side:
You are right with the ISO "restrictions" about the creation date, but where
would you actually store the revision/update information for the metadata set? I
don't think there is a possibility.
Within the maintenance class, there is only an attribute for the next scheduled
update.
I think this missing element is the reason, why many implementations (not only
GeoNetwork) use the field to store the (IMHO more useful and meaningful)
information about the last modification (automatic update on saving the
metadata).
When we worked on the German translation of ISO 19115[*], we also discussed this
issue with several participants from different offices and enterprises in
Germany and Switzerland and finally agreed to include the "change" in the
attribute description to sort of allow storing the change date.
One reason to allow change dates were also the INSPIRE technical guidelines[**]
where the following comment is made on dateStamp:
'ISO is more restrictive because this element
shall contain the "date that the metadata
was created" and INSPIRE may contain the
"date when the metadata record was
created or updated"'
Annina
[*]resulting in an official Document of the German SDI:
http://www.gdi-de.org/download/AK/ISO19115_GermanTranslation_GDIDE.pdf
[**]INSPIRE Knowledge base - European Commission
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
GeoNetwork OpenSource is maintained at
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork