Re: [CODE4LIB] Anyone familiar with XSLT? Im stuck
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.01.2016 um 19:39 schrieb Eric Lease Morgan: > Your XML files are pretty flat, and if I understand the question > correctly, then it is all but trivial to extract your three elements > as a line of CSV. Consequently I suggest foregoing the concatenation > of all the XML files into a single file. Such only adds complexity. > # process each file > for FILE in ./data/*.xml > > # do the work > $XSLTPROC $XSLT $FILE > > end actually, if [ "$XSLTPROC" = "xsltproc" ] ; then you can reduce that to xsltproc $XSLT ./data/*.xml For simple situations one might do without XSLT and stuff XPath expressions for the content to grab into the command line of utilities like xml_grep or xpath. But since these are essentially shell interfaces to perl modules (XML::Xpath and XML::Twig) it's probably not worth the effort installing them if they are not already present in your environment. Thomas Berger -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iJwEAQECAAYFAlahLiIACgkQYhMlmJ6W47PEIwQAnSRMS+s2lVonN6DDo6FoQLB3 p8tUPKVHLWnnkT58dH798n8Kosjo7K/klV1mQS1mj6Wof4aCGKAv7ANj1IBH0Swo D8FkI4vPeIG/qBe+U2zWO4QV+n3CYidTrh58VwSwVQd6X5fLcwfB4qYua4F6E1pF vckYhHTSKw04auPN+Qk= =ENF+ -END PGP SIGNATURE-
[CODE4LIB] Call for testers: next release of Net::OAI::Harvester Perl module may break legacy custom handlers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Apologies again for cross-posting, but it was just suggested to me that XML4LIB and PERL4LIB probably won't cover the possible audience] The Perl module Net::OAI::Harvester implements a client framework for the OAI Protocol for Metadata Harvesting (OAI-PMH) and was authored and originally maintained by Ed Summers. It has been available on CPAN ever since 2003 and its last stable version 1.15 has been released almost four years ago: < http://search.cpan.org/~thb/OAI-Harvester-1.15/ >. Since one of the repositories used for testing vanished from the web some time ago and this is breaking the test suite a new version has to be released fairly soon. Over time I had been tackling various minor issues and published developer releases on CPAN, cf. the list at the end of this mail or the Changes document linked at the CPAN page for the current release 1.16_12: < http://search.cpan.org/~thb/OAI-Harvester-1.16_12/ > However the sum of these changes is not negligible and specifically their impact on "custom metadata handlers" (which are to be used when processing other metadata formats than oai_dc) may affect applications using the module: >>>>> Up to version 1.15 the metadataHandler was inconsistently fed with input : - GetRecord exposed the almost complete XML response to the Handler (including start_document/end_document events) - ListRecords exposed the (OAI)record element (header, metadata and optional about containers) but did not propagate start_document or end_document events. In both cases the events for the header tags itself and for the optional setSpec subelements had not been forwarded Version 1.20 introduces a modified behavior for metadataHandler and an additional recordHandler: - a metadataHandler will see only the (single) subelement of the OAI metadata element (so for an deleted record it might never be invoced at all) - a recordHandler will see the OAI record element and its subelements Therefore a metadataHandler will now be confined to the metadata fragment(s) of the response, and the new recordHandler approximates the old behavior of ListRecords, however OAI-PMH:identifier and OAI-PMH:datestamp will now be properly encapsulated within their OAI-PMH:header element. Additionally, two new methods responseDate() and request() allow access to the corresponding top-level OAI-PMH elements in all response types. A SAX filter of class Net::OAI::Record::DocumentHelper may be used to inject start_document and end_document events into the chain if they are needed. As a temporary measure, you may set $Net::OAI::Harvester::OLDmetadataHandler =1 to change the behavior of handlers passed as "metadataHandler" into that of a recordHandler. <<<<<< Obviously the change of semantics for a metadataHandler to deal with the "metadata" elements of the response instead of the "record" elements is a design decision and may be questioned by users of the module. The current version also contains several changes which solve deficiencies of Net::OAI::Harvester 1.15 but possibly break existing workarounds for these deficiencies. For example officially (per documentation) you never could acccess the responseDate of the OAI-PMH result, but due to a sloppy implementation of processing for the identify verb it was possible to extract it in this case by an undocumented method. The current version supplies a dedicated responseDate() accessor for all verbs but at the same time fixes the behavior in the identify case. I may be overly optimistic but my impression is that the changes between the current 1.15 and the coming version (most probably numbered 1.20) do actually fix many issues but the fear is realistic (I experienced that myself with an old application of mine using the module) that these fixes may conflict with workarounds introduced by users to make things work before. *** So please, if you are currently using Net::OAI::Harvester *and* had been forced to introduce workarounds or tweak internals of the module, perform thorough testing before upgrading to the coming stable version, preferably already now with the developer version 1.16_12. And, please, please: provide feedback if you should run into trouble, either via the CPAN request tracker for the module at < https://rt.cpan.org/Public/Dist/Display.html?Name=OAI-Harvester > or by direct mail. Sorry for the inconvenience viele Gruesse Thomas Berger Changes to Net::OAI::Harvester since version 1.15 1.16_12 Tue, Jan 12 00:20:05 CET 2016 - - dealing with CPANTS Kwalitee issues, esp. version number mess - - new filter class Net::OAI::Record::DocumentHelper for tweaking 1.16_11 Tue, Jan 12 00:20:05 CET 2016 - - minor cleanup 1.16_10 Mon, Jan 11 01:29:46 CET 2016 - - renamed alldata() method for accessing recordHandler results to recorddata() - - better propagation of n
Re: [CODE4LIB] Net::OAI::Harvester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stephen, > Does anyone know a way in which Net::OAI::Harvester can be used with oai_dc > records in a way where multiple instances of a tag can be captured and then > concatenated with the first one. It should work to extract the tag in array context: my $dc = $r->metadata(); @their_identifiers = $dc->identifier(); Further concatenation would be left to the application. > That being said, I do have one other question: Is there a way within the > Net::OAI::Harvester to output the actual metadata structure that's being > harvested? There is no mandatory method for any metadata handlers within the context of Net::OAI::Harvester to provide this. And for the default OAI_DC handler: It provides the asString method which at least shows the complete content. hope this helps Thomas Berger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk5DfooACgkQYhMlmJ6W47NKfQP+M448CtRS+FyWHvsNY3efPaHk Ywl8yNJ/NlC0cjyHfjgaJpWB3qPM++Fn2BjnIVcXs9LeHmyc+gVB4BuYBuh6qlBg 0e7FDgA4YftPZz35vIQUjFrNuEkZfImKOTEf6NzlW7q30kTxaDTxt7xndAI+7bAJ e0436AcRTyJIAI2uUv0= =f45u -END PGP SIGNATURE-
Re: [CODE4LIB] wikipedia/author disambiguation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 31.05.2011 17:55, schrieb Jonathan Rochkind:
> VIAF one works great, taking me to the human readable VIAF page.
>
> PND one seems to work too, taking me to the authority page in the Deutsche
> National Bibliothek.
>
> The LCCN one does not work. Tries to take me to:
> http://errol.oclc.org/laf/n79021614.html
>
> Which results in an HTTP 500 error from the OCLC server.
>
> Since this template apparently generates a URL to an OCLC service (rather than
> LC? I guess maybe LC itself doesn't have the right permalinks?), I think that
> OCLC probably ought to fix this. If the template is not creating the right
> URL,
> I guess you've got to work with wikipedia to fix it. Or fix your end to accept
> those URLs properly.
These links IIRC are the same ones VIAF employs to link to a
representation of the NAF records and they are broken for about 6 weeks
now.
To my knowledge the {{Authority Control}} Metadata in the English Wikipedia
are inspired from a similar effort in the German Wikipedia, which since
2005 notes authority nunbers for persons: They started with PND numbers
(Personennormdatei, the Collaborative Authority File for german and
austrian libraries) and were backed by an agreement with the German
National Library (Deutsche Nationalbibliothek, DNB) to provide mutual
links from authority Records to Wikipedia and vice versa.
Currently about 150.000 articles on wikipedia.de carry the associated
PND number, many of them also LoC-NA and VIAF numbers:
http://de.wikipedia.org/wiki/Vorlage:NORMDATENCOUNT
The links from portal.d-nb.de to wikipedia.de are not implemented
by 856-like manifest URLs in the authority records nor some kind of
"wikipedia numbers" as additional identification numbers. Rather
wikipedia.de publishes on a daily base a trivial concordance table
relating extracted PND numbers to the corresponding wikipedia lemma.
The DNB portal in turn incorporates this table and generates the
respective links on the fly whenever an affected authority record is
displayed.
Some biographical dictionaries, regional bibliographies, classical
OPACs and historical projects picked up this mechanism and published
their own tables of this kind, all using the PND identification number
as common system of reference. This (as such a low-tech approach
to the semantic web) was coined "PND-BEACON":
< http://de.wikipedia.org/wiki/Wikipedia:PND/BEACON >
(english version: < http://meta.wikimedia.org/wiki/BEACON >)
CKAN data package: < http://ckan.net/package/pndbeacon >
Publishing such beacon files presupposes that your data already
carries more-than-local identification numbers. With this
precondition met, the gain is twofold:
- - publishing a beacon file may direct vistors from the incorporators
of the file to your catalogue
- - the existing authority numbers in your cataloge enable you to
relate (via their beacon files) to other web ressources, thus
rounding up the data you present.
Thomas Berger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iJwEAQECAAYFAk3lG9wACgkQYhMlmJ6W47MBZAP/Sj1LGGRAqKHnjyhUcHVN6JMP
Iy+CH2we1Dowod0PzNXHeR/0rk3Q0MTnWSznuhvM/tmyFESm3IFa1+Uwq8h56uob
lG6N0Bbn7OHTm22XXcNqBwMryOexI/irP4+yt9K1tE0Pm+kDydY8om1NK5vm3rSq
S4S4nwr0zJ7FVDjKJto=
=MqTZ
-END PGP SIGNATURE-
Re: [CODE4LIB] it's cool to hate on OpenURL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Jakob Voss schrieb: ... > Am I right that neither OpenURL nor COinS strictly defines a metadata > model with a set of entities/attributes/fields/you-name-it and their > definition? Apparently all ContextObjects metadata formats are based on > non-normative "implementation guidelines" only ?? You are right, the 129 page spec of Z39.88 only deals with these in examples, and IIRC does not even decent pointers to the following: There are some "Core Metadata formats" registered under http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats notably info:ofi/fmt:kev:mtx:book and info:ofi/fmt:kev:mtx:journal : < http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book >, < http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal >. As for the semantics of the fields defined there, the "description" is certainly not strictly defined in any sense but you can already see that there is potential for confusion and especially no canonical way (no way at all?) to achieve satisfying descriptions for several kinds of non-mainstream objects: * scholarly articles originally published online (when a "journal context" cannot be constructed) * articles in books which are not by coincidence conference proceedings ... ciao Thomas Berger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iJwEAQECAAYFAkvamhkACgkQYhMlmJ6W47P/vQP/XfExoDcfEuMGIgFUw4z4GOiM LhFsKPkVR7wHKDgB+mEF+xnDJoP549Y31YEYKc5lMMz5fVMONUDwwiavVL6IdDvL EU2jDOQO+WnLiw1XENYoTiuEP6bxyF+gojlBlEN7De1OlCJ97gqitwz6owmTxvp0 BfjBcj4X8//5KVMD0rw= =1a4i -END PGP SIGNATURE-
