Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
Interesting! In any event, a caveat is still deserved.
I would recommend removing not just the 450 or 455, but any 550 terms as well.
In fact, I’d just keep the 150. There is no place for variant forms of the
heading in the AS Subject record the way there is in the Agent record. It would
be desirable to keep those terms as variants to facilitate searching, in
exactly the same way we use variant forms of names in the Agent records. That
would require a change to the data model for Subject records.
Karen
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of
Majewski, Steven Dennis (sdm7g)
Sent: Saturday, June 17, 2017 5:16 PM
To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
I don’t believe that behavior is specific to the LCNAF plugin. It’s inherited
from the MarcXML base mappings. So if you don’t use the plugin and manually
import a MARC XML authority record, I believe that you’ll get the same result.
https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_base_map.rb#L970-L1043<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_archivesspace_archivesspace_blob_master_backend_app_converters_lib_marcxml-5Fbase-5Fmap.rb-23L970-2DL1043=DwMGaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ=gfjfKwGRGu39PosoWeTPP2Q-8p6o6-pYF--KBTmCuE8=Pnq4shGspI3G_3IH2FhOfo5ShyoLdu31GIEi1Vmc41A=>
So perhaps the "or @tag=‘450’” should be removed from the base mappings, along
with ‘451’ and ‘455’ [?]
Are there any counter cases where you would want those mappings to create a
term ?
Does it need to check if there is a previous 15x tag first to determine whether
to skip 45x ?
— Steve.
On Jun 16, 2017, at 2:57 PM, Karen Miller
<k-mill...@northwestern.edu<mailto:k-mill...@northwestern.edu>> wrote:
Hi, Candace.
I can’t help on the plugin operational issue, but I can offer a caveat about
using the plugin for LCSH. This plugin has (until very recently) worked well
for us at NUL for importing Agent records from LCNAF, but we have never used it
to import Subject records. And, as Steve pointed out, the import from OCLC is
unreliable.
When a Subject is imported using this plug-in, individual Subject records are
created for the preferred term (the MARC 150 field in the authority record) as
well as for each of the non-preferred terms (the MARC 450 fields in the
authority record, i.e., references). For example, an LCSH record with 4
non-preferred terms will be imported as 5 Subject records, one for the
preferred term and one for each of the non-preferred terms, with no indication
in the records for the non-preferred terms that they are references and should
not be assigned, as well as no indication of the preferred term with which they
are associated. This is almost certainly not what your archivists or catalogers
want.
While the import of Name Authority File (LCNAF) records correctly places
non-preferred names in the Agent record for the preferred name designated as
references, the import of LCSH records operates differently and would wreak
havoc on the use of Subject records.
I understand that Yale is undertaking a project to update the plug-in and hopes
to change the functionality so that only the preferred Subject term is
imported, but until then, I can’t recommend using it.
Best,
Karen
Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu<http://www.library.northwestern.edu/>
k-mill...@northwestern.edu<mailto:k-mill...@northwestern.edu>
874.467.3462
From:
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of
Maurice, Candace A
Sent: Friday, June 16, 2017 1:39 PM
To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
Hi Steve,
I tried to implement the patch, but still no luck. My file on line 71 is
different than in the patch you provided (see function below).
def search(query, page, records_per_page)
uri = URI(@base_url)
start_record = calculate_start_record(page, records_per_page)
params = default_params.merge('q' => [query.to_s, @scheme],
'count' => records_per_page,
'start' => start_record)
uri.query = URI.encode_www_form(params)
response = Net::HTTP.get_response(uri)
if resp
Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
@scheme is re-used later in the importer to construct the URI for the marc.xml,
as well as in the search, so instead of adding the prefix to @scheme, it should
just be prefixed in the search parameters:
-params = default_params.merge('q' => [query.to_s, @scheme],
+params = default_params.merge('q' => [query.to_s, 'cs:' + @scheme],
Sorry for the quick & wrong first answer!
— Steve.
On Jun 16, 2017, at 4:03 PM, Majewski, Steven Dennis (sdm7g)
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>> wrote:
Although those changes seem to fix the search, when I actually try importing
either subject or agent records, I get an internal server error. This need more
investigation.
On Jun 16, 2017, at 3:12 PM, Majewski, Steven Dennis (sdm7g)
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>> wrote:
My tests and patch were on current master branch, and so it looks like there
were further changes to lcnaf between 1.4.2 and 2.0.1 .
But the significant changes in my patch were:
[1] prefixing the @scheme parameter with (what I assume is) a field specifier:
@scheme = “cs:” + @scheme
( prefix could either be added to @scheme in initialized method, or else added
to the search params in search method. ) You can just manually edit that change
if the patch doesn’t work.
[2] the “p uri” prints out the final doc.gov<http://doc.gov/> URI and query
string. This was part of the debugging and reverse engineering: to compare the
URI & query in id.loc.gov<http://id.loc.gov/> search page with what LCNAF
plugin was using. Since I’m not sure if API changes to
id.loc.gov<http://id.loc.gov/> are documented anywhere, I left it there in case
of future changes or problems. You can always grab the URL out of the log file
and paste it into curl or your browser to see if it’s working as expected. So
the line 71 change is not required.
— Steve.
On Jun 16, 2017, at 2:38 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hi Steve,
I tried to implement the patch, but still no luck. My file on line 71 is
different than in the patch you provided (see function below).
def search(query, page, records_per_page)
uri = URI(@base_url)
start_record = calculate_start_record(page, records_per_page)
params = default_params.merge('q' => [query.to_s, @scheme],
'count' => records_per_page,
'start' => start_record)
uri.query = URI.encode_www_form(params)
response = Net::HTTP.get_response(uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
results = OpenSearchResultSet.new(response.body, query)
results.entries.each do |entry|
marc_uri = URI("#{entry['uri']}.marcxml.xml")
response = Net::HTTP.get_response(marc_uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
entry['xml'] = response.body.force_encoding("iso-8859-1").encode('utf-8')
end
results
End
-candace
From:
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of "Majewski, Steven Dennis (sdm7g)"
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>>
Reply-To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Thursday, June 15, 2017 at 12:26 PM
To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
It appears to be no longer working in any version.
I believe loc has changed the API for the service slightly. Need to investigate
further.
But trying to reverse engineer the parameters from inspecting the difference in
the params used in the web page search vs. what’s embedded in LCNAF plugin, I
tried this change, which appears to work for me:
diff --git a/plugins/lcnaf/frontend/models/opensearcher.rb
b/plugins/lcnaf/frontend/models/opensearcher.rb
index 9391ab5..37e2813 100644
--- a/plugins/lcnaf/frontend/models/opensearcher.rb
+++ b/plugins/lcnaf/frontend/models/opensearcher.rb
@@ -14,7 +14,7 @@ class OpenSearcher
def initialize(base_url, scheme )
@base_url = base_url
-@scheme = scheme
+@scheme = "cs:" + scheme
end
@@ -71,7 +71,7 @@ class OpenSearcher
'start' => start_record)
uri.query = URI.encode_www_form(params)
-
+p uri
results = HTTPRequest.new.get(uri) do |response|
i
Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
Although those changes seem to fix the search, when I actually try importing
either subject or agent records, I get an internal server error. This need more
investigation.
On Jun 16, 2017, at 3:12 PM, Majewski, Steven Dennis (sdm7g)
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>> wrote:
My tests and patch were on current master branch, and so it looks like there
were further changes to lcnaf between 1.4.2 and 2.0.1 .
But the significant changes in my patch were:
[1] prefixing the @scheme parameter with (what I assume is) a field specifier:
@scheme = “cs:” + @scheme
( prefix could either be added to @scheme in initialized method, or else added
to the search params in search method. ) You can just manually edit that change
if the patch doesn’t work.
[2] the “p uri” prints out the final doc.gov<http://doc.gov/> URI and query
string. This was part of the debugging and reverse engineering: to compare the
URI & query in id.loc.gov<http://id.loc.gov/> search page with what LCNAF
plugin was using. Since I’m not sure if API changes to
id.loc.gov<http://id.loc.gov/> are documented anywhere, I left it there in case
of future changes or problems. You can always grab the URL out of the log file
and paste it into curl or your browser to see if it’s working as expected. So
the line 71 change is not required.
— Steve.
On Jun 16, 2017, at 2:38 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hi Steve,
I tried to implement the patch, but still no luck. My file on line 71 is
different than in the patch you provided (see function below).
def search(query, page, records_per_page)
uri = URI(@base_url)
start_record = calculate_start_record(page, records_per_page)
params = default_params.merge('q' => [query.to_s, @scheme],
'count' => records_per_page,
'start' => start_record)
uri.query = URI.encode_www_form(params)
response = Net::HTTP.get_response(uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
results = OpenSearchResultSet.new(response.body, query)
results.entries.each do |entry|
marc_uri = URI("#{entry['uri']}.marcxml.xml")
response = Net::HTTP.get_response(marc_uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
entry['xml'] = response.body.force_encoding("iso-8859-1").encode('utf-8')
end
results
End
-candace
From:
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of "Majewski, Steven Dennis (sdm7g)"
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>>
Reply-To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Thursday, June 15, 2017 at 12:26 PM
To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
It appears to be no longer working in any version.
I believe loc has changed the API for the service slightly. Need to investigate
further.
But trying to reverse engineer the parameters from inspecting the difference in
the params used in the web page search vs. what’s embedded in LCNAF plugin, I
tried this change, which appears to work for me:
diff --git a/plugins/lcnaf/frontend/models/opensearcher.rb
b/plugins/lcnaf/frontend/models/opensearcher.rb
index 9391ab5..37e2813 100644
--- a/plugins/lcnaf/frontend/models/opensearcher.rb
+++ b/plugins/lcnaf/frontend/models/opensearcher.rb
@@ -14,7 +14,7 @@ class OpenSearcher
def initialize(base_url, scheme )
@base_url = base_url
-@scheme = scheme
+@scheme = "cs:" + scheme
end
@@ -71,7 +71,7 @@ class OpenSearcher
'start' => start_record)
uri.query = URI.encode_www_form(params)
-
+p uri
results = HTTPRequest.new.get(uri) do |response|
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
( The other OCLC search has always been unreliable — it’s a test site and not a
supported service. )
— Steve Majewski
On Jun 15, 2017, at 12:07 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hello All,
We are on version 1.4.2 and we have had a user report that the subject heading
plugin is not returning results for either LCNAF or LCSH (OCLC works, however).
The user doesn’t receive any e
Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
My tests and patch were on current master branch, and so it looks like there
were further changes to lcnaf between 1.4.2 and 2.0.1 .
But the significant changes in my patch were:
[1] prefixing the @scheme parameter with (what I assume is) a field specifier:
@scheme = “cs:” + @scheme
( prefix could either be added to @scheme in initialized method, or else added
to the search params in search method. ) You can just manually edit that change
if the patch doesn’t work.
[2] the “p uri” prints out the final doc.gov<http://doc.gov> URI and query
string. This was part of the debugging and reverse engineering: to compare the
URI & query in id.loc.gov<http://id.loc.gov> search page with what LCNAF plugin
was using. Since I’m not sure if API changes to id.loc.gov<http://id.loc.gov>
are documented anywhere, I left it there in case of future changes or problems.
You can always grab the URL out of the log file and paste it into curl or your
browser to see if it’s working as expected. So the line 71 change is not
required.
— Steve.
On Jun 16, 2017, at 2:38 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hi Steve,
I tried to implement the patch, but still no luck. My file on line 71 is
different than in the patch you provided (see function below).
def search(query, page, records_per_page)
uri = URI(@base_url)
start_record = calculate_start_record(page, records_per_page)
params = default_params.merge('q' => [query.to_s, @scheme],
'count' => records_per_page,
'start' => start_record)
uri.query = URI.encode_www_form(params)
response = Net::HTTP.get_response(uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
results = OpenSearchResultSet.new(response.body, query)
results.entries.each do |entry|
marc_uri = URI("#{entry['uri']}.marcxml.xml")
response = Net::HTTP.get_response(marc_uri)
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
end
entry['xml'] = response.body.force_encoding("iso-8859-1").encode('utf-8')
end
results
End
-candace
From:
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of "Majewski, Steven Dennis (sdm7g)"
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>>
Reply-To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Thursday, June 15, 2017 at 12:26 PM
To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
It appears to be no longer working in any version.
I believe loc has changed the API for the service slightly. Need to investigate
further.
But trying to reverse engineer the parameters from inspecting the difference in
the params used in the web page search vs. what’s embedded in LCNAF plugin, I
tried this change, which appears to work for me:
diff --git a/plugins/lcnaf/frontend/models/opensearcher.rb
b/plugins/lcnaf/frontend/models/opensearcher.rb
index 9391ab5..37e2813 100644
--- a/plugins/lcnaf/frontend/models/opensearcher.rb
+++ b/plugins/lcnaf/frontend/models/opensearcher.rb
@@ -14,7 +14,7 @@ class OpenSearcher
def initialize(base_url, scheme )
@base_url = base_url
-@scheme = scheme
+@scheme = "cs:" + scheme
end
@@ -71,7 +71,7 @@ class OpenSearcher
'start' => start_record)
uri.query = URI.encode_www_form(params)
-
+p uri
results = HTTPRequest.new.get(uri) do |response|
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
( The other OCLC search has always been unreliable — it’s a test site and not a
supported service. )
— Steve Majewski
On Jun 15, 2017, at 12:07 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hello All,
We are on version 1.4.2 and we have had a user report that the subject heading
plugin is not returning results for either LCNAF or LCSH (OCLC works, however).
The user doesn’t receive any error messages when using the plugin, but tried
typing in known subject headings for the Library Of Congress and it’s still not
returning results. I checked the Background jobs and logs and there are not
error messages. I also went to the LOC website and all appears to be fine when
searching subject headings on their site
Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
Thanks for the fast response, Steve! I’ll try your fix to see if it works for
us as well. Thanks!
From:
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of "Majewski, Steven Dennis (sdm7g)"
<sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>>
Reply-To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Thursday, June 15, 2017 at 12:26 PM
To: Archivesspace Users Group
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Subject Heading Plugin not working
properly 1.4.2
It appears to be no longer working in any version.
I believe loc has changed the API for the service slightly. Need to investigate
further.
But trying to reverse engineer the parameters from inspecting the difference in
the params used in the web page search vs. what’s embedded in LCNAF plugin, I
tried this change, which appears to work for me:
diff --git a/plugins/lcnaf/frontend/models/opensearcher.rb
b/plugins/lcnaf/frontend/models/opensearcher.rb
index 9391ab5..37e2813 100644
--- a/plugins/lcnaf/frontend/models/opensearcher.rb
+++ b/plugins/lcnaf/frontend/models/opensearcher.rb
@@ -14,7 +14,7 @@ class OpenSearcher
def initialize(base_url, scheme )
@base_url = base_url
-@scheme = scheme
+@scheme = "cs:" + scheme
end
@@ -71,7 +71,7 @@ class OpenSearcher
'start' => start_record)
uri.query = URI.encode_www_form(params)
-
+p uri
results = HTTPRequest.new.get(uri) do |response|
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
( The other OCLC search has always been unreliable — it’s a test site and not a
supported service. )
— Steve Majewski
On Jun 15, 2017, at 12:07 PM, Maurice, Candace A
<cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>> wrote:
Hello All,
We are on version 1.4.2 and we have had a user report that the subject heading
plugin is not returning results for either LCNAF or LCSH (OCLC works, however).
The user doesn’t receive any error messages when using the plugin, but tried
typing in known subject headings for the Library Of Congress and it’s still not
returning results. I checked the Background jobs and logs and there are not
error messages. I also went to the LOC website and all appears to be fine when
searching subject headings on their site.
Has anyone else experienced a similar issue? Can you point me in the right
direction for resolving this issue?
Thanks,
Candace
-
Candace Maurice
Web Developer
Howard-Tiltion Memorial Library
Tulane University
504.314.7784
cmaur...@tulane.edu<mailto:cmaur...@tulane.edu>
<512DA1AA-B52D-4559-9B7E-FB77BCC5BB86.png>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org<mailto:Archivesspace_Users_Group@lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
Re: [Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
It appears to be no longer working in any version.
I believe loc has changed the API for the service slightly. Need to investigate
further.
But trying to reverse engineer the parameters from inspecting the difference in
the params used in the web page search vs. what’s embedded in LCNAF plugin, I
tried this change, which appears to work for me:
diff --git a/plugins/lcnaf/frontend/models/opensearcher.rb
b/plugins/lcnaf/frontend/models/opensearcher.rb
index 9391ab5..37e2813 100644
--- a/plugins/lcnaf/frontend/models/opensearcher.rb
+++ b/plugins/lcnaf/frontend/models/opensearcher.rb
@@ -14,7 +14,7 @@ class OpenSearcher
def initialize(base_url, scheme )
@base_url = base_url
-@scheme = scheme
+@scheme = "cs:" + scheme
end
@@ -71,7 +71,7 @@ class OpenSearcher
'start' => start_record)
uri.query = URI.encode_www_form(params)
-
+p uri
results = HTTPRequest.new.get(uri) do |response|
if response.code != '200'
raise OpenSearchException.new("Error during OpenSearch search:
#{response.body}")
( The other OCLC search has always been unreliable — it’s a test site and not a
supported service. )
— Steve Majewski
On Jun 15, 2017, at 12:07 PM, Maurice, Candace A
> wrote:
Hello All,
We are on version 1.4.2 and we have had a user report that the subject heading
plugin is not returning results for either LCNAF or LCSH (OCLC works, however).
The user doesn’t receive any error messages when using the plugin, but tried
typing in known subject headings for the Library Of Congress and it’s still not
returning results. I checked the Background jobs and logs and there are not
error messages. I also went to the LOC website and all appears to be fine when
searching subject headings on their site.
Has anyone else experienced a similar issue? Can you point me in the right
direction for resolving this issue?
Thanks,
Candace
-
Candace Maurice
Web Developer
Howard-Tiltion Memorial Library
Tulane University
504.314.7784
cmaur...@tulane.edu
<512DA1AA-B52D-4559-9B7E-FB77BCC5BB86.png>
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
[Archivesspace_Users_Group] Subject Heading Plugin not working properly 1.4.2
Hello All, We are on version 1.4.2 and we have had a user report that the subject heading plugin is not returning results for either LCNAF or LCSH (OCLC works, however). The user doesn’t receive any error messages when using the plugin, but tried typing in known subject headings for the Library Of Congress and it’s still not returning results. I checked the Background jobs and logs and there are not error messages. I also went to the LOC website and all appears to be fine when searching subject headings on their site. Has anyone else experienced a similar issue? Can you point me in the right direction for resolving this issue? Thanks, Candace - Candace Maurice Web Developer Howard-Tiltion Memorial Library Tulane University 504.314.7784 cmaur...@tulane.edu [Description: Description: cid:image001.jpg@01C9F346.FB284370] ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
