<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hola!<br>
<br>
On 09/04/14 10:31, Florian Heß wrote:<br>
</div>
<blockquote cite="mid:5345137F.3080102@ub.uni-heidelberg.de"
type="cite">
<pre wrap="">Am 08.04.2014 11:57, schrieb Sebastien Francois:
</pre>
<blockquote type="cite">
<pre wrap="">- recommit: by definition, this action should touch lastmod
</pre>
</blockquote>
<pre wrap="">
Hi Sebastien,
I am afraid, I disagree here partly. Recommits should touch lastmod only
*if* there are dirty substantial = user-editable metadata columns. This
admittedly is difficult to decide by epadmin recommit tool as the
changes often have taken place directly in advance, bypassing the API,
for this I assume is the main purpose of that tool. Hence, what about
--non-volatile-change alias --no-touch-lastmod switches (and/or their
respective positive counterparts) to epadmin recommit and alike?</pre>
</blockquote>
<br>
Fair point!... <br>
<br>
So when someone runs epadmin recommit, the script forces the
recommit ($dataobj->commit( 1 )) which *always* writes data to
the database, regardless of whether the data-obj was modified during
the re-commit.<br>
<br>
So if I understand correctly your case-studies, it seems like you
need:<br>
<br>
1- epadmin recommit <br>
2- epadmin force-recommit<br>
<br>
v1 could do $dataobj->commit() -> no change in the dataobj =
no DB write, no update of lastmod, revision, history. Change in the
dataobj => lastmod, revision, history updated<br>
<br>
v2 could do $dataobj->commit( 1 ) -> same as the current
behaviour<br>
<br>
<blockquote cite="mid:5345137F.3080102@ub.uni-heidelberg.de"
type="cite">
<pre wrap="">Look, there are so many actions an eprint commit trigger (e.g.
/cfg.d/eprint_fields_automatic.pl) might include that you developers
possibly cannot forsee, that you maybe would [not] consider an
anti-conception feature misuse, and that might need a "recommit"
sometimes e.g. when code just added requires all older eprints to be
reprocessed. Touching lastmod no matter if a specific data object meets
any seldomly occurring conditions for a given action, can result in
problems. A guy from China had problems accessing our OAI server after -
and maybe just because - we regenerated the thumbnails, thus potentially
making they swallow half of HeiDOK.</pre>
</blockquote>
<br>
Shouldn't touch lastmod if regenerating thumbnails, we definitely
agree on this.<br>
<br>
But for other cases, if the metadata is updated then lastmod must be
updated. And the OAI protocol is consistent with this behaviour:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
<span style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); display: inline !important;
float: none;">A repository<span class="Apple-converted-space"> </span></span><b
style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
font-size: medium; font-style: normal; font-variant: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);">must</b><span style="color: rgb(0, 0, 0); font-family:
'Times New Roman'; font-size: medium; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); display: inline !important;
float: none;"><span class="Apple-converted-space"> </span>update
the datestamp of a record if a change occurs, the result of which
would be a change to the<span class="Apple-converted-space"> </span></span><a
href="http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm#metadatapart"
style="font-family: 'Times New Roman'; font-size: medium;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);">metadata part</a><span style="color: rgb(0, 0, 0);
font-family: 'Times New Roman'; font-size: medium; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); display: inline !important;
float: none;"><span class="Apple-converted-space"> </span>of the
XML-encoding of the record. Such changes include, but are not
limited to, changes to the metadata of the record, changes to the
metadata format of the record, introduction of a new metadata
format, termination of support for a metadata format, etc.</span><br>
<br>
Volatile changes shouldn't cause an update of the lastmod datestamp
(by definition... it's a volatile change, not a content/metadata
change). This is how EPrints works (but I agree stuff must be
fine-tuned... hence our discussion :-)).<br>
<br>
So what you cannot have (if you want to respect OAI) is updating
some item's metadata and not update the lastmod field (you can of
course find ways to achieve this result but not OAI-friendly).<br>
<br>
<br>
<blockquote cite="mid:5345137F.3080102@ub.uni-heidelberg.de"
type="cite">
<pre wrap="">Some more info on my OAI-harvesting aggregator scenario so you
understand my problem:
The aggregator database is kept small by dropping items that have not
been modified for more than 100 days. Practically, epadmin recommit is
therefore a superb tool to make our "new media" service advertise rather
old if not obsolete stuff. According to OAI specification (as is how I
remember once having read), OAI-compliant repositories should bear in
mind harvesters not mirroring all of a data provider. This includes in
my eyes that the data provider should repropagate records with some
caution in order to not irritate "bleeding edge stuff" harvesters. Sure,
one can still argue that those are better off considering dc:date more,
but this is not always an appropriate filtering criterion.</pre>
</blockquote>
<br>
So... given the conversations we've had so far - would the suggested
changes (the "don't touch lastmod if no metadata change has
occurred") be compatible with what you're trying to achieve?<br>
<br>
Thanks for keeping the conversation up. Once we're both happy, let's
propagate this to github.<br>
<br>
Seb.<br>
<br>
</body>
</html>