VuFind

OAI-PMH harvested records: filter only the ones with an URL to get into SOLR index

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.3
  • Component/s: OAI
  • Labels:
  • Environment:
    Some OIA-PMH sources send records that do not have any URL to access the full text or existence of a certain document somewhere (or even part of it). dc:identifier may be present (or several), but none has an URL to the document itself.

Description


This one was a little bit of a nightmare, as none of the <xsl:variable> or <xsl:param> element could be used as flags within the XSLT (version "1.0", I mean).

A way to exclude these records, if one just wants records that the user can access in the Library or online, is just to bypass all of the transformation and inject an empty record into SOLR or at least without the "id" field.

After having harvested fully NDLTD (in the recent days) I noticed that many records didn't find their way into SOLR index. For some of them I believe the reason is that they don't have dc:identifier or none of these is an URL.

The initial code I was using was:

<xsl:for-each select="//dc:identifier">

<xsl:choose>
<xsl:when test="contains(., '://')">
<field name="id"><xsl:value-of select="//identifier"/></field>
</xsl:when>
</xsl:choose>

</xsl:for-each>

but with the recent problem described with having in the output of the XSL transformation duplicated "description" fields would prevent that record to be indexed by SOLR (as it is a non multiValued one) --- http://vufind.org/jira/browse/VUFIND-499, I reckon that is also part of the reason for the records not being indexed (although the import says "Successfully imported /usr/local/vufind/harvest/NDLTD/ .....xml...").

For that to happen is just necessary that a record as more than an URL in repeated dc:identifier (in the harvested XML file). I mean, even having the same value, having two "id" fields it a "no go" for SOLR (at least according to the tests I have done).

So until late hours last night was fighting with <xsl:variable> and <xsl:param> see if one of them could be used as a flag and could be read outside of that context, something like:

<xsl:for-each select="//dc:identifier">

<xsl:if test="contains(., '://')">

<xsl:variable name="hasURL">yup</xsl:variable>

</xsl:if>

</xsl:for-each>


<xsl:if test="$hasURL = 'yup'" ><field name="id">NDLTD-<xsl:value-of select="substring-after(//identifier,'union.ndltd.org-')"/></field>
</xsl:if>

or many alike in the test part (all kind of them, I would say)

Placing a <xsl:copy-of select="$hasURL"/> just shows the correct value within the <xsl:if test="contains(., '://')"> so cand not be used (<xsl:stylesheet version="2.0" is more complete in the set of elements and testing that can be done -- 1.0 is very limited).

So going to the point that matters, found a very simple way to do it:

(....)

<xsl:template match="oai_dc:dc">

       <xsl:if test="*[contains(//dc:identifier, '://')]">
        <add>
            <doc>

(....)

            </doc>
        </add>
</xsl:if>
    </xsl:template>
</xsl:stylesheet>

That allows even several URLs to be added to "url" fields, as per usual (and no "dead-end"/"cul-de-sac" records). So simple as that, googling it didn't helped that much (was worst, until found this pearl in a situation different a lot, but could extract the idea from it).

Again, please do advance tips on how to do it better if you have some thoughts about it (and do interest you).

All the best from Aveiro, Portugal,

Filipe
  1. 1325533757_NDLTD_OCLC_oai_xtcat_oclc_org_OCLCNo_214409437.xml
    25/Jan/12 10:03 AM
    0.8 kB
    Filipe M S Bento
  2. 1325588833_NDLTD_OCLC_oai_xtcat_oclc_org_OCLCNo_315347813.xml
    25/Jan/12 10:05 AM
    1 kB
    Filipe M S Bento
  3. ddc22_map.properties
    03/Feb/12 6:03 AM
    46 kB
    Filipe M S Bento
  4. format_map.properties
    03/Feb/12 6:01 AM
    2 kB
    Filipe M S Bento
  5. language_map_oai_utf8.properties
    03/Feb/12 6:00 AM
    7 kB
    Filipe M S Bento
  6. language_map.properties
    03/Feb/12 6:02 AM
    6 kB
    Filipe M S Bento
  7. ndltd.xsl
    26/Jan/12 5:04 PM
    8 kB
    Filipe M S Bento

Activity

Hide
Demian Katz added a comment -
This sounds like a reasonable solution to me. Maybe when you are done you can share your NDLTD configurations so we can include them as a sample with VuFind and close out the tickets that discuss issues demonstrated by the example.

One related issue which might help here -- right now, the XSLT import tool doesn't really know whether or not the record was successfully added to Solr; it only checks whether the POST succeeded. I'll try to find some time to see if there's a way to get better feedback so that we can report errors when the POST succeeds but the actual contents result in an error. If nothing else, we could do a lookup to see if a record with the POSTed id value exists after the operation is completed, though that's not the ideal solution since it would probably slow things down.
Show
Demian Katz added a comment - This sounds like a reasonable solution to me. Maybe when you are done you can share your NDLTD configurations so we can include them as a sample with VuFind and close out the tickets that discuss issues demonstrated by the example. One related issue which might help here -- right now, the XSLT import tool doesn't really know whether or not the record was successfully added to Solr; it only checks whether the POST succeeded. I'll try to find some time to see if there's a way to get better feedback so that we can report errors when the POST succeeds but the actual contents result in an error. If nothing else, we could do a lookup to see if a record with the POSTed id value exists after the operation is completed, though that's not the ideal solution since it would probably slow things down.
Hide
Demian Katz added a comment -
Solving the error detection problem was easier than I had expected -- see VUFIND-502.
Show
Demian Katz added a comment - Solving the error detection problem was easier than I had expected -- see VUFIND-502.
Hide
Filipe M S Bento added a comment -
It turns out that the "*" in

  <xsl:if test="*[contains(//dc:identifier, '://')]">

is just a "placebo", as only the first value of the field gets tested!!

i.e., = <xsl:if test="contains(//dc:identifier, '://')">, at least in version "1.0" of XSLT.

Needless to say that those records in which the first <dc:identifier> is not a URL, for instances:

--------------

<oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"><identifier>NDLTD-union.ndltd.org-OCLC-oai-xtcat.oclc.org-OCLCNo-174718330</identifier><datestamp>2011-09-07T02:15:34Z</datestamp><dc:title>Entwicklung und Erprobung sensorintegrierter Schleifwerkzeuge</dc:title><dc:creator>BoÌhm, Christian.</dc:creator><dc:subject>Miniaturisierung. Online-Messung. Telemetrie. CBN-Schleifscheibe. Integrierter Sensor.</dc:subject><dc:type>Online-Publikation</dc:type><dc:description>UniversitÌat, Diss., 2001--Bremen.</dc:description><dc:identifier>ca.5,2MB</dc:identifier><dc:identifier>http://elib.suub.uni-bremen.de/publictions/dissertations/E-Diss232_Boehm.pdf&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://deposit.ddb.de/cgi-bin/dokserv?idn=963778110&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://elib.suub.uni-bremen.de/publications/dissertations/E-Diss232_Boehm.pdf&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://deposit.d-nb.de/cgi-bin/dokserv?idn=963778110&lt;/dc:identifier&gt;&lt;dc:language&gt;ger&lt;/dc:language&gt;&lt;/oai_dc:dc>

-------------

got rejected, even if they have plenty of URLs in the remaining dc:identifiers.

So was getting a lot of "Problem transforming XML" and records not getting into SOLR index.

So since the rest of the afternoon I've been back to try all of the possible xsl:variable combinations and further beyond (define new templates) in order to get a way to do just a so simple task of assign a value to a flag to say, "hey, consider this record because one the <dc:identifier> is actually an URL".

Being trying in vain until now (1am, no dinner yet), but I guess I got a working solution > a KISS one > if the variables are global and then cannot be changed or local but can do only have value in that context, so lets gather everything inside the same context (in this case a <xsl:if test="//dc:identifier">):

     <xsl:variable name="URLs" />
     <xsl:output method="xml" indent="yes" encoding="utf-8"/>

<xsl:template match="oai_dc:dc">

<xsl:if test="//dc:identifier">

<xsl:variable name="URLs"><xsl:for-each select="//dc:identifier"><xsl:value-of select="."/></xsl:for-each></xsl:variable>

<xsl:if test="contains($URLs, '://')">

                  <add>
                     <doc>

                       (....)


I mean gather every possible values that the different dc:identifier may have concatenated in a (local) variable ("URLs" as I called) and then test if within it there some clues of URLs being spread around there (in this case "://").

Ok, only the ones that do not have no dc:identifier with an URL will get reject and will stay out of the /processed sub-folder.

For instances, records like:

------------------



<oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"><identifier>NDLTD-union.ndltd.org-OCLC-oai-xtcat.oclc.org-OCLCNo-163595884</identifier><datestamp>2011-09-07T02:15:34Z</datestamp><dc:title>An estimate of the lense-thirring effect in the solar system and in a system of binary pulsars using delay of light /</dc:title><dc:creator>Caron, Louis-Philippe.</dc:creator><dc:subject>Celestial mechanics. General relativity (Physics) Astrophysics.</dc:subject><dc:description>Thesis (M.Sc.)--York University, 2004. Graduate Programme in Physics and Astronomy.</dc:description><dc:description>Typescript. Includes bibliographical references (leaves 126-129). Also available on the Internet. MODE OF ACCESS via web browser by entering the following URL: LINK NOT YET AVAILABLE.</dc:description><dc:date>2004.</dc:date><dc:identifier>LINK NOT YET AVAILABLE.</dc:identifier><dc:language>eng</dc:language></oai_dc:dc>

-------------------

Bye for now (hope this is a final working version -- if not will update the status as it is importing right now).

FB

PS: been programming for decades (ok, a couple [2]), but with such limitations it is really a nightmare -- but I guess had worse before...
Show
Filipe M S Bento added a comment - It turns out that the "*" in   <xsl:if test="*[contains(//dc:identifier, '://')]"> is just a "placebo", as only the first value of the field gets tested!! i.e., = <xsl:if test="contains(//dc:identifier, '://')">, at least in version "1.0" of XSLT. Needless to say that those records in which the first <dc:identifier> is not a URL, for instances: -------------- <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"><identifier>NDLTD-union.ndltd.org-OCLC-oai-xtcat.oclc.org-OCLCNo-174718330</identifier><datestamp>2011-09-07T02:15:34Z</datestamp><dc:title>Entwicklung und Erprobung sensorintegrierter Schleifwerkzeuge</dc:title><dc:creator>BoÌhm, Christian.</dc:creator><dc:subject>Miniaturisierung. Online-Messung. Telemetrie. CBN-Schleifscheibe. Integrierter Sensor.</dc:subject><dc:type>Online-Publikation</dc:type><dc:description>UniversitÌat, Diss., 2001--Bremen.</dc:description><dc:identifier>ca.5,2MB</dc:identifier><dc:identifier>http://elib.suub.uni-bremen.de/publictions/dissertations/E-Diss232_Boehm.pdf&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://deposit.ddb.de/cgi-bin/dokserv?idn=963778110&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://elib.suub.uni-bremen.de/publications/dissertations/E-Diss232_Boehm.pdf&lt;/dc:identifier&gt;&lt;dc:identifier&gt;http://deposit.d-nb.de/cgi-bin/dokserv?idn=963778110&lt;/dc:identifier&gt;&lt;dc:language&gt;ger&lt;/dc:language&gt;&lt;/oai_dc:dc> ------------- got rejected, even if they have plenty of URLs in the remaining dc:identifiers. So was getting a lot of "Problem transforming XML" and records not getting into SOLR index. So since the rest of the afternoon I've been back to try all of the possible xsl:variable combinations and further beyond (define new templates) in order to get a way to do just a so simple task of assign a value to a flag to say, "hey, consider this record because one the <dc:identifier> is actually an URL". Being trying in vain until now (1am, no dinner yet), but I guess I got a working solution > a KISS one > if the variables are global and then cannot be changed or local but can do only have value in that context, so lets gather everything inside the same context (in this case a <xsl:if test="//dc:identifier">):      <xsl:variable name="URLs" />      <xsl:output method="xml" indent="yes" encoding="utf-8"/> <xsl:template match="oai_dc:dc"> <xsl:if test="//dc:identifier"> <xsl:variable name="URLs"><xsl:for-each select="//dc:identifier"><xsl:value-of select="."/></xsl:for-each></xsl:variable> <xsl:if test="contains($URLs, '://')">                   <add>                      <doc>                        (....) I mean gather every possible values that the different dc:identifier may have concatenated in a (local) variable ("URLs" as I called) and then test if within it there some clues of URLs being spread around there (in this case "://"). Ok, only the ones that do not have no dc:identifier with an URL will get reject and will stay out of the /processed sub-folder. For instances, records like: ------------------ <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd"><identifier>NDLTD-union.ndltd.org-OCLC-oai-xtcat.oclc.org-OCLCNo-163595884</identifier><datestamp>2011-09-07T02:15:34Z</datestamp><dc:title>An estimate of the lense-thirring effect in the solar system and in a system of binary pulsars using delay of light /</dc:title><dc:creator>Caron, Louis-Philippe.</dc:creator><dc:subject>Celestial mechanics. General relativity (Physics) Astrophysics.</dc:subject><dc:description>Thesis (M.Sc.)--York University, 2004. Graduate Programme in Physics and Astronomy.</dc:description><dc:description>Typescript. Includes bibliographical references (leaves 126-129). Also available on the Internet. MODE OF ACCESS via web browser by entering the following URL: LINK NOT YET AVAILABLE.</dc:description><dc:date>2004.</dc:date><dc:identifier>LINK NOT YET AVAILABLE.</dc:identifier><dc:language>eng</dc:language></oai_dc:dc> ------------------- Bye for now (hope this is a final working version -- if not will update the status as it is importing right now). FB PS: been programming for decades (ok, a couple [2]), but with such limitations it is really a nightmare -- but I guess had worse before...
Hide
Filipe M S Bento added a comment -
PS: many thanks, Demian, for VUFIND-502 -- without that simple value added in Solr.php (responseCode 400) I would never would be able to catch the "faulty" records, the ones that were not getting in.
Show
Filipe M S Bento added a comment - PS: many thanks, Demian, for VUFIND-502 -- without that simple value added in Solr.php (responseCode 400) I would never would be able to catch the "faulty" records, the ones that were not getting in.
Hide
Demian Katz added a comment - - edited
I understand your frustration -- I don't have a lot of love for XSLT!

It sounds like your revised solution is reasonable, though another option you can consider in situations like this is to use a php:function call. Since you can call php:function within the test attribute of an xsl:if, you could have created a PHP function to loop through all the //dc:identifier values in search of the target string. In this particular case, I think the solution you chose is better -- it's always nicer to use native XSLT without having to plug in external functions if you can get away with it -- but the PHP option can be very helpful when running up against limitations like this.
Show
Demian Katz added a comment - - edited I understand your frustration -- I don't have a lot of love for XSLT! It sounds like your revised solution is reasonable, though another option you can consider in situations like this is to use a php:function call. Since you can call php:function within the test attribute of an xsl:if, you could have created a PHP function to loop through all the //dc:identifier values in search of the target string. In this particular case, I think the solution you chose is better -- it's always nicer to use native XSLT without having to plug in external functions if you can get away with it -- but the PHP option can be very helpful when running up against limitations like this.
Hide
Filipe M S Bento added a comment - - edited
First attachment: example of a XML harvested from NDLTD with just "$" as dc:identifier (one file of many like this)
Show
Filipe M S Bento added a comment - - edited First attachment: example of a XML harvested from NDLTD with just "$" as dc:identifier (one file of many like this)
Hide
Filipe M S Bento added a comment - - edited
Second attachment: example of a XML file that has a "urn" as dc:identifier.

It needs a resolver to link to the proper destination.

A possible resolver could be (just found it out right now): http://nbn-resolving.de/

Going to include that (code) in the XSLT file (ndltd.xsl), transform, in the particular case of this record:

   <dc:identifier>urn:nbn:de:swb:ch1-200700328</dc:identifier>

into

   url solr field: http://nbn-resolving.de/urn:nbn:de:swb:ch1-200700328

as simple, as that!

Filipe

PS: done!

<<< before >>>

---------------

    <!-- URL -->

<xsl:for-each select="//dc:identifier">

<xsl:if test="contains(., '://')">
<field name="url">
<xsl:value-of select="." />
</field>
</xsl:if>
</xsl:for-each>


<<< now >>>

                          <!-- URL -->

<xsl:for-each select="//dc:identifier">
<xsl:choose>
<xsl:when test="contains(., '://')">
<field name="url">
<xsl:value-of select="." />
</field>
</xsl:when>
<xsl:when test="contains(., 'urn:')">
<field name="url">
http://nbn-resolving.de/ <xsl:value-of select="." /> <!-- without the space between ".de/" and "<xsl: ..." -->
</field>
</xsl:when>
</xsl:choose>
</xsl:for-each>

------------------

And, yes, Demian, I am a stronger supported of resolving issues locally, try not to use third party solutions that may change in behavior.

PS(2): yes, Demian, I thought of a "PHP function to loop through all the //dc:identifier values in search of the target string" exactly as you say but didn't find a way to output a value / flag if found and how to use it within the XSLT (that flag; a local variable?). So stacked then all together seemed to me the fastest and easiest way to do it (although took several hours to have that light turned on above my head)
Show
Filipe M S Bento added a comment - - edited Second attachment: example of a XML file that has a "urn" as dc:identifier. It needs a resolver to link to the proper destination. A possible resolver could be (just found it out right now): http://nbn-resolving.de/ Going to include that (code) in the XSLT file (ndltd.xsl), transform, in the particular case of this record:    <dc:identifier>urn:nbn:de:swb:ch1-200700328</dc:identifier> into    url solr field: http://nbn-resolving.de/urn:nbn:de:swb:ch1-200700328 as simple, as that! Filipe PS: done! <<< before >>> ---------------     <!-- URL --> <xsl:for-each select="//dc:identifier"> <xsl:if test="contains(., '://')"> <field name="url"> <xsl:value-of select="." /> </field> </xsl:if> </xsl:for-each> <<< now >>>                           <!-- URL --> <xsl:for-each select="//dc:identifier"> <xsl:choose> <xsl:when test="contains(., '://')"> <field name="url"> <xsl:value-of select="." /> </field> </xsl:when> <xsl:when test="contains(., 'urn:')"> <field name="url"> http://nbn-resolving.de/ <xsl:value-of select="." /> <!-- without the space between ".de/" and "<xsl: ..." --> </field> </xsl:when> </xsl:choose> </xsl:for-each> ------------------ And, yes, Demian, I am a stronger supported of resolving issues locally, try not to use third party solutions that may change in behavior. PS(2): yes, Demian, I thought of a "PHP function to loop through all the //dc:identifier values in search of the target string" exactly as you say but didn't find a way to output a value / flag if found and how to use it within the XSLT (that flag; a local variable?). So stacked then all together seemed to me the fastest and easiest way to do it (although took several hours to have that light turned on above my head)
Hide
Demian Katz added a comment -
Thanks for all of these extra details. Are you able to share your completed ndltd.xsl file, or is it still in progress?
Show
Demian Katz added a comment - Thanks for all of these extra details. Are you able to share your completed ndltd.xsl file, or is it still in progress?
Hide
Filipe M S Bento added a comment -
Demian,

I think everything is covered right now... so please find it attached (xsl).

The entry in vufind/harvest/oai.ini is:

[NDLTD]
url = http://union.ndltd.org/OAI-PMH/
metadataPrefix = oai_dc
idSearch[] = "/^oai:union.ndltd.org:/"
idReplace[] = "NDLTD-"
idSearch[] = "/\//"
idReplace[] = "-"
idSearch[] = "/:/"
idReplace[] = "-"
injectId = "identifier"
injectDate = "datestamp"


I'me using union.ndltd.org now because http://alcme.oclc.org/ndltd/ just gives HTTP Error 500 for every action.

Looking forward for other sources being shared here (although now looking fw more for real time searches in EBSCO's and SCOPUS's sources)

All the best,

Filipe

PS: yes, I've harcoded the format field value into Portuguese (not sure now why -- many changes made after, but had a reason for sure...)
Show
Filipe M S Bento added a comment - Demian, I think everything is covered right now... so please find it attached (xsl). The entry in vufind/harvest/oai.ini is: [NDLTD] url = http://union.ndltd.org/OAI-PMH/ metadataPrefix = oai_dc idSearch[] = "/^oai:union.ndltd.org:/" idReplace[] = "NDLTD-" idSearch[] = "/\//" idReplace[] = "-" idSearch[] = "/:/" idReplace[] = "-" injectId = "identifier" injectDate = "datestamp" I'me using union.ndltd.org now because http://alcme.oclc.org/ndltd/ just gives HTTP Error 500 for every action. Looking forward for other sources being shared here (although now looking fw more for real time searches in EBSCO's and SCOPUS's sources) All the best, Filipe PS: yes, I've harcoded the format field value into Portuguese (not sure now why -- many changes made after, but had a reason for sure...)
Hide
Filipe M S Bento added a comment - - edited
ndltd.xsl: please refer to comment/info above.

I guess you can close this ticket, now, and assignee it to me if you want. Thanks!
Show
Filipe M S Bento added a comment - - edited ndltd.xsl: please refer to comment/info above. I guess you can close this ticket, now, and assignee it to me if you want. Thanks!
Hide
Demian Katz added a comment -
Thanks, Filipe. I've committed this as r4988 with a couple of minor changes:

1.) Added parameter so you can control the URN resolver via .ini file.
2.) Translated format strings into English (other formats default to English, but we can always add translations to the language files).
3.) Only put data in the building facet if the parameter is non-empty.

I notice that your file refers to a language map that does not exist in the trunk. I've changed it to language_map.properties for now, but perhaps you can submit the one you're actually using for more accurate results.
Show
Demian Katz added a comment - Thanks, Filipe. I've committed this as r4988 with a couple of minor changes: 1.) Added parameter so you can control the URN resolver via .ini file. 2.) Translated format strings into English (other formats default to English, but we can always add translations to the language files). 3.) Only put data in the building facet if the parameter is non-empty. I notice that your file refers to a language map that does not exist in the trunk. I've changed it to language_map.properties for now, but perhaps you can submit the one you're actually using for more accurate results.
Hide
Filipe M S Bento added a comment - - edited
language_map_oai_utf8.properties: as the name says encoded in UTF8 (with some entries, found in records, that do not comply to any ISO standard).
-- in Portuguese
FB
Show
Filipe M S Bento added a comment - - edited language_map_oai_utf8.properties: as the name says encoded in UTF8 (with some entries, found in records, that do not comply to any ISO standard). -- in Portuguese FB
Hide
Filipe M S Bento added a comment - - edited
format_map.properties: as the name says (but with some extra entries, found in records, that do not comply with known standards).
-- remains in English (as the official / trunk one)
FB
Show
Filipe M S Bento added a comment - - edited format_map.properties: as the name says (but with some extra entries, found in records, that do not comply with known standards). -- remains in English (as the official / trunk one) FB
Hide
Filipe M S Bento added a comment - - edited
language_map.properties: as the name says (but with some extra entries, found in records, that do not comply with ISO standards).
-- in Portuguese
FB
Show
Filipe M S Bento added a comment - - edited language_map.properties: as the name says (but with some extra entries, found in records, that do not comply with ISO standards). -- in Portuguese FB
Hide
Filipe M S Bento added a comment - - edited
ddc22_map.properties: translated into Portuguese
Show
Filipe M S Bento added a comment - - edited ddc22_map.properties: translated into Portuguese
Hide
Filipe M S Bento added a comment - - edited

Demian, like msg'ed could you please commit another version of ndltd.xsl with publishDateSort field included (that is missing)?

----
                <!-- PUBLISHDATE -->
                <xsl:if test="//dc:date">
                    <field name="publishDate">
                        <xsl:value-of select="substring(//dc:date, 1, 4)"/>
                    </field>
                </xsl:if>
+++

                <!-- PUBLISHDATE -->
                <xsl:if test="//dc:date">
                    <field name="publishDate">
                        <xsl:value-of select="substring(//dc:date, 1, 4)"/>
                    </field>
                   <field name="publishDateSort">
                        <xsl:value-of select="substring(//dc:date, 1, 4)"/>
                    </field>
                </xsl:if>

Many thanks,

Filipe
Show
Filipe M S Bento added a comment - - edited Demian, like msg'ed could you please commit another version of ndltd.xsl with publishDateSort field included (that is missing)? ----                 <!-- PUBLISHDATE -->                 <xsl:if test="//dc:date">                     <field name="publishDate">                         <xsl:value-of select="substring(//dc:date, 1, 4)"/>                     </field>                 </xsl:if> +++                 <!-- PUBLISHDATE -->                 <xsl:if test="//dc:date">                     <field name="publishDate">                         <xsl:value-of select="substring(//dc:date, 1, 4)"/>                     </field>                    <field name="publishDateSort">                         <xsl:value-of select="substring(//dc:date, 1, 4)"/>                     </field>                 </xsl:if> Many thanks, Filipe
Hide
Demian Katz added a comment -
Updated file committed as r5358.
Show
Demian Katz added a comment - Updated file committed as r5358.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: