Hi Andrew et al,
The definition of dateStamp is the "date the metadata was created". Yu
*must* not change that definition. ISO 19115 is *not* concerned with
implementation. Hence using the logic of "how else do you know the
change date" or "everyone needs that change date" are not good reasons
to change the definition of dateStamp. If you need a change date for the
metadata then you must implement it in the back end of the database, as
suggested by Andrew, or create a profile which contains a new element
for the metadata change date. You *must not* change the definition of
and existing ISO 19115 metadata element.
I'm extremely surprised that the people that I worked with to develop
ISO TC 211 standards allowed this misuse of dateStamp to be implemented
in national profiles.
John Hockaday
On Wed, 2012-10-31 at 18:06 +1100, andrew walsh wrote:
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:
http://trac.osgeo.org/geonetwork/ticket/1124. 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 DoelemanOn 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[**]http://inspire.jrc.ec.europa.eu/documents/Metadata/INSPIRE_MD_IR_and_ISO_v1_2_20100616.pdf
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
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------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
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