<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EstiloCorreo17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:510032122;
mso-list-template-ids:-510121508;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:1773167473;
mso-list-template-ids:-2012590870;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">An answer from Jesús L.
Domínguez Muriel (<a class="moz-txt-link-abbreviated" href="mailto:jdmuriel@jdmuriel.com">jdmuriel@jdmuriel.com</a>): <br>
<br>
</font>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EstiloCorreo17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:510032122;
mso-list-template-ids:-510121508;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:1773167473;
mso-list-template-ids:-2012590870;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><font face="Helvetica, Arial, sans-serif"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Hello,<br>
<br>
[Due to a misconfiguration of my e-mail software, I cannot post
directly to the oai-implementers list. If you find this information
useful, please feel free to post it to the list]<br>
<br>
Regarding problems 2 and 3, there is an European initiative called
DRIVER which attempts to solve, among others, those problems.<br>
<br>
DRIVER-conforming repositories must use certain values for date and
type DC fields, and must include open-access full-text records within a
specific OAI set. They should also implement an additional metadata
format –DIDL-, which helps locate the associated full-text files, so
that they can be easily accessed and collected.<br>
<br>
You can find more information at
<a class="moz-txt-link-freetext" href="http://www.driver-support.eu/en/index.html">http://www.driver-support.eu/en/index.html</a><br>
<br>
My personal opinion is that these DRIVER guidelines should be refined
and made clearer. I would have also preferred a different metadata
format to specify associated files, because DIDL is too generic and a
bit confusing. Maybe the future OAI-ORE could be used instead of DIDL.
Anyway, it is a starting point and deserves some study.<br>
<br>
Jesús L.Domínguez Muriel<br>
DIGIBIS S.L.<br>
Madrid, Spain<br>
<o:p></o:p></span></font></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<div>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
<p class="MsoNormal"><b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"
lang="ES">De:</span></b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif"; color: windowtext;"
lang="ES">
<a class="moz-txt-link-abbreviated" href="mailto:oai-implementers-bounces@openarchives.org">oai-implementers-bounces@openarchives.org</a>
[<a class="moz-txt-link-freetext" href="mailto:oai-implementers-bounces@openarchives.org">mailto:oai-implementers-bounces@openarchives.org</a>] <b>En nombre de </b>Frederic
MERCEUR<br>
<b>Enviado el:</b> miércoles, 05 de diciembre de 2007 10:40<br>
<b>Para:</b> <a class="moz-txt-link-abbreviated" href="mailto:oai-implementers@openarchives.org">oai-implementers@openarchives.org</a><br>
<b>Asunto:</b> [OAI-implementers] Some OAI-PMH protocol issues<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US">Hello,
<br>
<br>
Further to the previous email I sent about the </span><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"><a
href="http://www.ifremer.fr/docelec/doc/2007/acte-3238.pdf"><span
lang="EN-US">document</span></a></span><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US"> we
redacted to assess the main difficulties met during the first year of
management of our </span><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"><a
href="http://www.ifremer.fr/avano/"><span lang="EN-US">Avano</span></a></span><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US">
harvester, I would like to focus, in this email, on just 3 problems
linked to
the OAI-PMH protocol, Dublin Core or to repositories implementation. I
would
like to focus particularly on these 3 problems because I guess they
should not
be so difficult to fix. <br>
<br>
<br>
</span><b><span style="font-family: "Helvetica","sans-serif";"
lang="EN-US">Managing
duplicates </span></b><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US"><br>
<br>
Too many duplicates in a result list in Harvesters list can affect the
user’s
comfort. This is not the main problem harvesters are facing today, but
this
should increase in the coming years. Today, at least two phenomenons
can
generate duplicates in the harvesters’ databases: </span><span
lang="EN-US"><o:p></o:p></span></p>
<ul type="disc">
<li class="MsoNormal" style=""><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US">Several research organisations or universities can record
the same electronic resource in their own institutional repository. If
Avano harvests those repositories, it will get descriptive index files
of the same topic stored in several places. This can happen if, for
example, a publication is written in collaboration with several
institutions. If so, this publication may be archived on the server of
each institution. Considering the current low auto-archiving rate,
especially in life sciences, this phenomenon is not the main cause of
the production of duplicates.</span><span lang="EN-US"><o:p></o:p></span></li>
<li class="MsoNormal" style=""><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US">Projects for national or thematic aggregators can pose
problem. In some countries, projects of merged institutional
repositories can agregate records from a selection of repositories in a
centralised database before displaying them again in OAI-PMH on their
own server. As a consequence, records referenced on those servers are
displayed twice in OAI-PMH: via the institutional repository and via
the centralised database. If the manager of an harvester does not know
about the architecture of those national or thematic projects, he may
record the two different servers and generate duplicates in his
harvester’s result lists. </span><span lang="EN-US"><o:p></o:p></span></li>
</ul>
<p class="MsoNormal" style="margin-bottom: 12pt;"><i><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US">To help
harvesters administrator to avoid recording repositories generating
duplicates,
could we imagine adding to the description of the repository
information about
the involvement of the said repository in a national or thematic
agregation
system that would reexpose the records in OAI-PMH from a different
server? <br>
</span></i><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US"><br>
<br>
</span><b><span style="font-family: "Helvetica","sans-serif";"
lang="EN-US">Managing
Type and Date field</span></b><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US"><br>
<br>
As far as I understand, in order to comply with the OAI-PMH protocol,
repositories have to expose their data in the non-qualified Dublin Core
DTD. In
this DTD all fields are optional. Those fields are also non-qualified,
meaning,
for example, that they do not have to correspond to an enclosed value
list.
This optional and non-formalised information trait raises several
issues,
especially for the Type field. <br>
<br>
Indeed, even if the Dublin Core DTD recommends storing the Type
information by
using standardised text strings, few repositories take this into
consideration
and still present the information as free text (ex: publication,
artjournal,
text, article are used to describe an article). Some harvesters,
including
Avano, offer their users to limit their search to one or several types
of resources.
To set up this filter, harvesters try to standardise the Type field
using a
system based on key-word recognition in this character string. This
standardising is therefore imperfect and the filter system may exclude
resources from the result list when a user narrows his search to one or
several
types of specific data. Some informations contained in this Type field
cannot
be standardised.<br>
<br>
Even more problematic is the fact that some repositories do not fill in
this
field. As an example, in September 2007, out of the 107.000 records
available
in Avano, more than 26.000 did not have a Type field. All of those
records are
automatically barred from the search space if a user limits is search
to one or
several selected types. <br>
<br>
<i>Could it be possible to imagine getting a new normalised and
mandatory
information about the type of the digital object (text, image, video….)
so harvesters could offer an reliable option to filter one or several
types ob
objects from the end-user search.<br>
</i><br>
The publication date is also problematic for harvester. For example, In
September 2007, out of the 107.000 records available in Avano, about
15.000 did
not have a publication date. When a record does not have a publication
date or
when it cannot be standardised, it is automatically located at the end
of the
list if the user wants the results to be sorted by date. In the same
way, when
a user limits his search to a specific period of time (see fig. 9),
those files
are barred from the search even if they correspond to the specified
search.
<br>
<br>
But I guess this problem with the publication date will be more
difficult to
fix because it is difficult to define it as mandatory. <br>
<br>
<br>
</span><b><span style="font-family: "Helvetica","sans-serif";"
lang="EN-US">Records
without free access to the digital object</span></b><span
style="font-size: 10pt; font-family: "Helvetica","sans-serif";"
lang="EN-US"><br>
<br>
As far as I understand, the OAI-PMH protocol defines only the sharing
process
of bibliographical records contained in a group of repositories. As a
consequence, some repositories mix records without links to the digital
object
together with records providing free access to the resource. Others
provide
records with paying access (ex : BePress) or records with restricted
access,
for example, for university staff. <br>
<br>
In my opinion, this is the major problem harvesters have to face today.
There
is no indication in the Dublin Core DTD showing the harvesters the
degree of accessibility
of the objects described in the records. As a consequence, harvesters
cannot
pass on this information to their users or provide them with the
ability to
filter empty records or records offering paying access to the resource.
<br>
<br>
It is my opinion that hiding records with free full text among records
with
inaccessible full text is not helpful. For lack of time and/or
interest,
scientists are reluctant to join the Open Access movement and the
archiving
rate of free access publications stays very low, especially in life
sciences.
Free and immediate access to documentation is, without doubt, the best
way to
convince the scientists of the interest of the Open Access movement.
And
drowning a minority of records providing free access publications in an
ocean
of records without link to the full text and/or records offering paying
access
to the documents may not be the best way to promote the Open Access
movement. <br>
<br>
Again, those records without free access to the full text would not be
a
problem for the harvesters if the Dublin Core DTD enabled to signify
the
harvesters the degree of accessibility of the objects described in the
records.
Harvesters could then provide their users with the possibility of
filtering the
records without free access to the digital object. But it is still not
the
case. <br>
<br>
<i>Could we then imagine that, in a possible future version of the
OAI-PMH,
each record will have to provide a normalised and mandatory information
about
the degree of accessibility of the digital object (free, paying,
impossible,
restricted,...)? This will help harvesters so much to provide a better
service
to theirs end-users. <br>
</i><br>
<br>
What do you think?<br>
<br>
Kind regards,<br>
Fred</span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">-- <br>
</span><span style="font-size: 10pt; font-family: "Arial","sans-serif";"
lang="EN-US">Fred
Merceur<br>
Ifremer / Bibliothèque La Pérouse<br>
</span><span style="font-size: 10pt; font-family: "Arial","sans-serif";"><a
href="mailto:frederic.merceur@ifremer.fr"><span lang="EN-US">frederic.merceur@ifremer.fr</span></a></span><span
style="font-size: 10pt; font-family: "Arial","sans-serif";"
lang="EN-US"><br>
Tél : 02-98-49-88-69<br>
Fax : 02-98-49-88-84<br>
</span><span style="font-size: 10pt; font-family: "Arial","sans-serif";"><a
href="http://www.ifremer.fr/blp/"><span lang="EN-US">Bibliothèque La
Pérouse</span></a></span><span
style="font-size: 10pt; font-family: "Arial","sans-serif";"
lang="EN-US"><br>
</span><span style="font-size: 10pt; font-family: "Arial","sans-serif";"><a
href="http://www.ifremer.fr/docelec/"><span lang="EN-US">Archimer,
Ifremer's
Institutional Repository</span></a></span><span
style="font-size: 10pt; font-family: "Arial","sans-serif";"
lang="EN-US"><br>
</span><span style="font-size: 10pt; font-family: "Arial","sans-serif";"><a
href="http://www.ifremer.fr/avano/"><span lang="EN-US">Avano, a marine
and
aquatic OAI harvester</span></a></span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
<br>
<div class="moz-signature">-- <br>
<font face="Arial" size="2">Fred Merceur<br>
Ifremer / Bibliothèque La Pérouse<br>
<a class="moz-txt-link-abbreviated" href="mailto:frederic.merceur@ifremer.fr">frederic.merceur@ifremer.fr</a><br>
Tél : 02-98-49-88-69<br>
Fax : 02-98-49-88-84<br>
<a href="http://www.ifremer.fr/blp/">Bibliothèque La Pérouse</a><br>
<a href="http://www.ifremer.fr/docelec/">Archimer, Ifremer's
Institutional Repository</a><br>
<a href="http://www.ifremer.fr/avano/">Avano, a marine and aquatic OAI
harvester</a><br>
</font></div>
</body>
</html>