Yes, as long as you have the requisite technical expertise. You'll need to be comfortable with Web technologies, XML, and OpenURL.
We'll review your configuration and get back to you within a week or two. Once we add you to the program, our robots will periodically visit your URLs and update the links on our website appropriately.
####
So in general, Google only accepts Scholar registrations from vendors, not directly from library customers. They get the registration from an Ex Libris server.
There might be configuration in your SFX admin to update your base URL registered with Google... but if there is, it doens't actually work reliably.
You've got to file a support ticket with EL, and tell them you need to change your base URL registration with Google Scholar, and theoretically they can do it, and hopefully it won't take too long to take effect. EL support hopefully will know how to do
this.
Your other option, of course, is simply changing your DNS so your former hostname now points to your Umlaut server. :) That's legit too, especially since Google Scholar isn't the only place you have to update, you probably have dozens or hundreds of vendors
to update too, it can make sense to keep your URLs the same, but just point them at Umlaut. (Although if your old URL was sfx.princeton.edu/sfx, that's kind of awkward. If you're switching now, definitely switch to a vendor/product neutral URL, so you won't
have to do this again! We use findit.library.jh.edu, no 'umlaut' or 'sfx' in the name, but the name of our service that we won't have to change if we change products)
I _wish_ Google would take registration directly from libraries. Because I'd like to have the option of switching to other link resolver vendors with Umlaut, like SerSol. But as far as I know, SerSol provides no way to set the Google Scholar registration
to anything but their own servers. If anyone knows anyone at Google....
Jonathan
Actually, I see you found Google Docs that claim they DO support direct registration! I've never found those docs before, that's potentially exciting... if they'll really do it. It would open up more possibilities for us, perhaps.
I might try emailing that email address and getting them to confirm that they'll really do that... but I kind of predict i'll get no response to my email, it's VERY hard to actually get in touch with Google on this stuff.
For you now, the easiest thing is probably just asking EL to change your base URL in your google scholar registration, that's what we all did. :)
When we switched over to using Umlaut a few months ago, I thought I was going to have to talk to our supplier, Innovative, to get them to make the changes in the Google Scholar registration. But then I realised that Google harvests a file called, in our case, institutional_links.xml, which contains the settings I needed to change:
<institutional_links>
<!-- The full name of your institution, for display in preferences. -->
<!-- (REQUIRED; no more than 60 characters) -->
<institution>Durham University Library</institution>
…
<!-- The label for the links to your electronic full text. -->
<!-- It should be short and should include the name of your school. -->
<!-- (REQUIRED; no more than 25 characters) -->
<electronic_link_label>Durham ConneXions</electronic_link_label>
…
<!-- The base URL for your link resolver. -->
<!-- (REQUIRED; no more than 1024 characters) -->
<openurl_base>http://openurl.ac.uk/ukfed:dur.ac.uk</openurl_base>
…
The file finishes up with a set of URLs which point to the actual journal holdings files which Millennium generates nightly:
<electronic_holdings>
<url>http://129.234.247.3/public/institutional_holdings1.xml</url>
<url>http://129.234.247.3/public/institutional_holdings2.xml</url>
…
</electronic_holdings>
</institutional_links>
So we changed the base URL to http://openurl.ac.uk/ukfed:dur.ac.uk as you will see above, which routes via a UK resolver service that holds the actual base URL of our Umlaut installation. Then all we need to do is keep openurl.ac.uk up to date with the location of our resolver.
So in the case of a Millennium system, it seems our supplier simply tells Google where the institutional_links.xml file is on our server, and Google gets on with it. The file has exactly the same format as the institutional_links.xml file that is given in the instructions Kevin located.
With an SFX server, I strongly suspect it is using the same mechanism, but whether your institutional_links.xml file is held on a central server by Ex Libris or is held on your own SFX server, I don’t know. Of course, if you have a cloud-hosted SFX that may amount to the same thing! But if you host SFX locally you could dig around and see if the institutional_links.xml file is actually under your control already. Except that Ex Libris seem to be happy to change the base URL on request anyway…
As you will see, the institituonal_links.xml file supports multiple journal holdings files, and in our case Millennium splits the output into multiple files to avoid them getting too big. I think SFX just bungs them all into one file. I used to look after an SFX installation at Dundee, and when we implemented Summon I used the journal holdings file and transformed it into CSV which I could load into the Serials Solutions KB as a local holdings file. This allowed us to turn on the relevant material in Summon without having to customise all their packages, which would have been extra work.
In the case of Millennium I have to do something similar: I have a script which amalgamates all our journal holdings files into a single one, because Primo, when harvesting our holdings files, only supports reading from a single file….
Matthew
--
Matthew Phillips
Head of Digital and Bibliographic Services,
Durham University Library, Stockton Road, Durham, DH1 3LY
When we did this, we did try to update all vendors (as well as google scholar) from our old sfx-specific non-standard-port base url to our new Umlaut base URL.
But we also put redirects in in place from the old one, that caught it and actually issued an HTTP redirect to the new one. We have so many vendors and places the base URL is configured, that we knew we wouldn't catch them all right away, but wanted everyone
using Umlaut right away.
In order to do this, we had to change the actual URL SFX was at, so the old URL would redirect instead of being direct to SFX -- but SFX was still accessible, for Umlaut API use or troubleshooting or whatever. Fortunately, it's relatively straightforward
to change the URL SFX lives at, although I forget the details.
Another thing I considered but we never implemented is making sure logs were catching anything that went to the old URL and got redirected (and logging with HTTP referrer), and monitoring those logs so we could catch any place that still had the old base
URL, and figure out how to update it.
We chose a vendor/product-neutral URL for our new one, so if we ever switch products again, including away from Umlaut, we hope to avoid ever having to change this base URL again, since it involves updates at so many vendors.
Jonathan