From daniel.chudnov at yale.edu Sun Nov 6 20:55:04 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Nov 6 20:55:14 2005 Subject: [gcs-pcs-list] COinS-PMH at LoC (sort of) Message-ID: The Ariadne paper several of us published earlier this year which partly led to the development of COinS suggested, near the end, that a site like American Memory might combine an approach like (the then still-unnamed) COinS with autodiscoveryish links to OAI-PMH services, and that this might provide a basis for additional services and opportunities for remixing content. I stumbled onto a sharp greasemonkey hack yesterday that suggested we could do this *now*... and, it works. http://curtis.med.yale.edu/dchud/log/project/rogue/american-memory- coinspmh-enabled The original GM script is extended with a bit that rewrites item-page HTML to support COinS-PMH; a second GM script pops up the beginnings of a "COinS Sidebar" generated within the same HTML frame. All hail the sloppy underbelly! -dchud -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Mon Nov 7 10:59:56 2005 From: ehs at pobox.com (Edward Summers) Date: Mon Nov 7 11:00:02 2005 Subject: [gcs-pcs-list] COinS-PMH at LoC (sort of) In-Reply-To: References: Message-ID: On Nov 6, 2005, at 7:55 PM, Daniel Chudnov wrote: > All hail the sloppy underbelly! Umm, wow. It's great to see this stuff actually working Dan. You have glued together oai-pmh and the browsing experience. Quite a mash up indeed. Since there are oai-pmh repositories behind xxx.lanl.gov it would be pretty cool to see them enabled like this. It could be the start of some very interesting client side applications that can leverage this metadata. //Ed From daniel.chudnov at yale.edu Mon Nov 7 14:04:51 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Nov 7 14:04:57 2005 Subject: [gcs-pcs-list] COinS-PMH at LoC (sort of) In-Reply-To: References: Message-ID: <8C3E7C05-490F-4937-81D5-2ADC9AD8FEC8@yale.edu> On Nov 7, 2005, at 10:59 AM, Edward Summers wrote: > > Since there are oai-pmh repositories behind xxx.lanl.gov it would > be pretty cool to see them enabled like this. It could be the start > of some very interesting client side applications that can leverage > this metadata. Done. http://curtis.med.yale.edu/dchud/log/project/rogue/arxiv-org- coinspmh-enabled Note, though, that this is not smartly implemented enough to overcome their OAI server throttling policy, so read the whole entry before you try it. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From T.Hammond at nature.com Mon Nov 7 14:08:47 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Mon Nov 7 14:08:55 2005 Subject: [gcs-pcs-list] Offbeat Message-ID: <125F7834E11A5741A7D79412EE3504F91D08CB8F@UK1APPS2.mpl.root-domain.org> Little bit offbeat, but https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1086 3&rfc_flag=0 might be of interest. Sorry to be wicked. :) Cheers, Tony ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** From lukethelibrarian at gmail.com Tue Nov 15 19:12:49 2005 From: lukethelibrarian at gmail.com (Luke Rosenberger) Date: Tue Nov 15 19:12:55 2005 Subject: [gcs-pcs-list] Sanity check Message-ID: I'm de-lurking here in the hope that some of you can check my sanity here, or help me get my head wrapped around this issue. At my work, we did an evaluation of SerialsSolution and EBSCO LinkSource, and ultimately went with LinkSource as our OpenURL resolver solution. One difference I noticed between SerialsSolutions and LinkSource has been increasingly nagging at me as the time has passed since that decision: the difference in the way the two services set up their base URLs. A SerialsSolutions base URL looks like... http://tb8br3eg8r.search.serialssolutions.com/ ...where the "subdomain" tb8br3eg8r identifies the SerialsSolution customer/resourceset. However, an EBSCO LinkSource base URL looks like this... http://linksource.epnet.com/LinkSource/linking.aspx ...which is to say, it includes nothing that explicitly links it with a certain LinkSource customer/resourceset. So how does LinkSource know whose resolver to look at when it fields an incoming OpenURL? That was the question I asked EBSCO support -- both regarding their current infrastructure and regarding their upcoming migration of LinkSource to their A-to-Z infrastructure -- and you can see their response at the bottom of this message. Long story short, here's the decision tree: (1) it looks for a cookie previously set by epnet.com identifying the EBSCO customer institution with which the customer is associated, (2) lacking that, it tries to locate the IP address of the requestor within an IP address range associated with an EBSCO client institution, (3) LinkSource prompts for a username and password. As I express in my reply (below) I see some real problems with that scenario that have particular impact upon plans to deploy OpenURL COinS. My question for all of you who understand the history and development of the OpenURL protocol better than I: does EBSCO's plan -- looking at cookies, IP addresses, or other factors to identify the "context" of the user instead of deriving it from the base URL -- really fit the design of the OpenURL protocol? Or is this a gray area or something that the designers of OpenURL really didn't consider? I'd really appreciate any feedback, suggestions, citations, documentation, or ideas you can throw my way -- at the moment, I feel like I'm talking with people at EBSCO who just don't get it, but I'm hoping at some point I can either get through to somebody that does, or else get a cluestick upside the head that will straighten me out. Thanks in advance. ---------- Forwarded message ---------- From: Rosenberger, Luke E Sent: Tuesday, November 15, 2005 13:23 To: 'EBSCO' Cc: 'ebscosupport@ebsco.com' Subject: RE: Case #69771 Update - New interface Authentication Please note that my original concern in this case was not the authentication of the user in LinkSource, but rather the association of a given user request with a given LinkSource resolver, in cases where that association would be in doubt. I am concerned that because of your decision not to identify the specific LinkSource resolver in the base URL, you may not be conforming to the intent of the OpenURL protocol, and that such an implementation could lead to complicated problems in the future, as OpenURLs begin to appear more frequently outside the context of authenticated databases. In an academic environment, we cannot be handing out a username and password to access link-resolver services -- it's far too cumbersome an option for patrons we know, let alone those future patrons who will be visiting our resources for the first time next week or next month. Therefore, the methodology you describe in your response below leaves two options: cookie and IP address. Both of these approaches are inherently problematic. (1) The use of cookies assumes that the patron has already visited and been authenticated by an EBSCO database prior to attempting to follow an OpenURL link. As libraries attempt to reach out and offer services to patrons in more places, we will see more and more of our patrons who come across OpenURL links without having previously accessed an EBSCO database **or without even having visited the library website** -- as they may be entering from a non-EBSCO database or non-database referrer. Moreover, because of the privacy concerns that some users harbor regarding cookies, they may have their browser set to automatically delete all cookies every time the browser is closed (I know Firefox and Opera offer this option) -- so with those users, each new browser session will be like starting over from scratch. (2) The use of cookies as a primary identification method -- at least as EBSCO currently employs cookies -- also assumes that a given patron will only be associated with one EBSCO client. This has proven to be a problem for us already -- two of the five colleges in our district are joint public-academic libraries. Therefore, the patrons of those libraries are, in fact, patrons of the Harris County Public Library and NHMCCD. Both HCPL and NHMCCD are EBSCO customers -- but NHMCCD is a LinkSource customer, while HCPL is not. An implementation which looks at cookies set by EBSCO databases will invariable run into problems in situations where a given customer may use EBSCO databases from more than one institution. (3) The use of IP address as a secondary method limits targets only those who are on-campus, or whose institutions use a proxy-based remote authentication solution. The software we use, SirsiDynix's RPA, is not proxy-based, and is therefore incompatible with this method. (4) Even at those institutions who are employing proxy-based solutions (such as EZProxy), your dependence on IP address as a method for determining institutional affiliation assumes that patrons will already be operating in a proxied mode when they access the OpenURL link. This assumption again ignores what is bound to be an increasing trend in the future: OpenURLs which will appear *outside* of authenticated databases, on standard webpages. Please consider the prototypes currently deployed of the OpenURL COinS structure (see http://ocoins.info for more information) and/or client-side rewriting tools, such as Greasemonkey scripts, IE bookmarklets, and extensions/toolbars such as Openly's OpenURL Referrer -- http://www.openly.com/openurlref/ -- or Virginia Tech's LibX toolbar -- http://libx.org/ -- or others. The design of URL-rewriting proxy tools such as EZProxy makes it unlikely that the administrator of those tools will be able to anticipate and "proxy" all possible pages where incoming OpenURL links could appear, simply for the purpose of ensuring that the correct link resolver is chosen. I believe that it would be a much better choice for you to choose a structure for your LinkSource base URL that would specifically identify the LinkSource resolver that should be used. If you continue to insist that will not be necessary, I would appreciate more information about how you intend to mitigate the problems outlined above. Thanks in advance. Luke Rosenberger, Technology Librarian Automated Library Services, DSTC North Harris Montgomery Community College District 5000 Research Forest Dr The Woodlands TX 77381-4399 tel 832-813-6652 luke.rosenberger@nhmccd.edu ________________________________ From: EBSCO [mailto:EBSCOSupport@ebsco.com] Sent: Tuesday, November 15, 2005 11:45 To: Rosenberger, Luke E Subject: Case #69771 Update - New interface Authentication Hello Luke, After extensive research with our development team we have established that in the new LinkSource/A-to-Z interface, authentication will be checked in a system-specified order - the admin cannot change the order: If no cookie is present, then the following are checked: IP address, Username/Password (either one configured on LinkSource/A-to-Z or an Athens login.) LinkSource/A-to-Z will not support these authentication methods: Patron Files, CPID, Referring URL, or Shibboleth. There are future plans to consider offering Shibboleth authentication. As always, if we can be of service to you at any time in the future, please do not hesitate to contact A-to-Z with LinkSource Customer Care. Thanks, Tesa Williams A-to-Z with LinkSource Representative (877) 327-2622 (U.S.A. and Canada) (205) 981-4000 (Worldwide) Fax (205) 408-6194 Hours 7:00 A.M. to 5:00 P.M. CST EBSCO Information Services CUSTOMERFOCUSEDCONTENTDRIVEN -- AIM: lukethelibrarian / Yahoo Messenger: lukethelibrarian / MSN Messenger: lukethelibrarian@gmail.com "Oh, no, don't be sorry. You see, I don't believe that libraries should be drab places where people sit in silence, and that's been the main reason for our policy of employing wild animals as librarians." -- Graham Chapman as the Chairman in "Gorilla Librarian," Episode Ten, Monty Python's Flying Circus From andrew-forman at uiowa.edu Wed Nov 16 08:56:21 2005 From: andrew-forman at uiowa.edu (Forman, Andrew B) Date: Wed Nov 16 08:56:27 2005 Subject: [gcs-pcs-list] Sanity check Message-ID: <183294552478444386C2B6B95D597E05022DC94E@IOWAEVS02.iowa.uiowa.edu> Luke, I think you've hit one of the main reasons why the current authentication/authorization schemes in use are in desperate need of overhaul. We're starting to look at Shibboleth as an answer to the overall problem, but that will require our various vendors to begin supporting Shibboleth (Elsevier has already joined InCommon, not sure of anyone else) or provide other SAML-based interfaces. For your immediate problem, I wonder if asking LinkSource to enable an optional query parameter might be your best option. There must be some sort of internal unique identifier for your institution that could be passed in on the URL (a step zero on the decision tree =). I don't know how responsive they are to enhancements, but I wouldn't expect it to be technically difficult on their end. HTH, Andrew Andrew Forman Application Development University of Iowa Libraries 319 335 9152 -----Original Message----- From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf Of Luke Rosenberger Sent: Tuesday, November 15, 2005 6:13 PM To: gcs-pcs-list@cipolo.med.yale.edu Subject: [gcs-pcs-list] Sanity check I'm de-lurking here in the hope that some of you can check my sanity here, or help me get my head wrapped around this issue. At my work, we did an evaluation of SerialsSolution and EBSCO LinkSource, and ultimately went with LinkSource as our OpenURL resolver solution. One difference I noticed between SerialsSolutions and LinkSource has been increasingly nagging at me as the time has passed since that decision: the difference in the way the two services set up their base URLs. A SerialsSolutions base URL looks like... http://tb8br3eg8r.search.serialssolutions.com/ ...where the "subdomain" tb8br3eg8r identifies the SerialsSolution customer/resourceset. However, an EBSCO LinkSource base URL looks like this... http://linksource.epnet.com/LinkSource/linking.aspx ...which is to say, it includes nothing that explicitly links it with a certain LinkSource customer/resourceset. So how does LinkSource know whose resolver to look at when it fields an incoming OpenURL? That was the question I asked EBSCO support -- both regarding their current infrastructure and regarding their upcoming migration of LinkSource to their A-to-Z infrastructure -- and you can see their response at the bottom of this message. Long story short, here's the decision tree: (1) it looks for a cookie previously set by epnet.com identifying the EBSCO customer institution with which the customer is associated, (2) lacking that, it tries to locate the IP address of the requestor within an IP address range associated with an EBSCO client institution, (3) LinkSource prompts for a username and password. As I express in my reply (below) I see some real problems with that scenario that have particular impact upon plans to deploy OpenURL COinS. My question for all of you who understand the history and development of the OpenURL protocol better than I: does EBSCO's plan -- looking at cookies, IP addresses, or other factors to identify the "context" of the user instead of deriving it from the base URL -- really fit the design of the OpenURL protocol? Or is this a gray area or something that the designers of OpenURL really didn't consider? I'd really appreciate any feedback, suggestions, citations, documentation, or ideas you can throw my way -- at the moment, I feel like I'm talking with people at EBSCO who just don't get it, but I'm hoping at some point I can either get through to somebody that does, or else get a cluestick upside the head that will straighten me out. Thanks in advance. ---------- Forwarded message ---------- From: Rosenberger, Luke E Sent: Tuesday, November 15, 2005 13:23 To: 'EBSCO' Cc: 'ebscosupport@ebsco.com' Subject: RE: Case #69771 Update - New interface Authentication Please note that my original concern in this case was not the authentication of the user in LinkSource, but rather the association of a given user request with a given LinkSource resolver, in cases where that association would be in doubt. I am concerned that because of your decision not to identify the specific LinkSource resolver in the base URL, you may not be conforming to the intent of the OpenURL protocol, and that such an implementation could lead to complicated problems in the future, as OpenURLs begin to appear more frequently outside the context of authenticated databases. In an academic environment, we cannot be handing out a username and password to access link-resolver services -- it's far too cumbersome an option for patrons we know, let alone those future patrons who will be visiting our resources for the first time next week or next month. Therefore, the methodology you describe in your response below leaves two options: cookie and IP address. Both of these approaches are inherently problematic. (1) The use of cookies assumes that the patron has already visited and been authenticated by an EBSCO database prior to attempting to follow an OpenURL link. As libraries attempt to reach out and offer services to patrons in more places, we will see more and more of our patrons who come across OpenURL links without having previously accessed an EBSCO database **or without even having visited the library website** -- as they may be entering from a non-EBSCO database or non-database referrer. Moreover, because of the privacy concerns that some users harbor regarding cookies, they may have their browser set to automatically delete all cookies every time the browser is closed (I know Firefox and Opera offer this option) -- so with those users, each new browser session will be like starting over from scratch. (2) The use of cookies as a primary identification method -- at least as EBSCO currently employs cookies -- also assumes that a given patron will only be associated with one EBSCO client. This has proven to be a problem for us already -- two of the five colleges in our district are joint public-academic libraries. Therefore, the patrons of those libraries are, in fact, patrons of the Harris County Public Library and NHMCCD. Both HCPL and NHMCCD are EBSCO customers -- but NHMCCD is a LinkSource customer, while HCPL is not. An implementation which looks at cookies set by EBSCO databases will invariable run into problems in situations where a given customer may use EBSCO databases from more than one institution. (3) The use of IP address as a secondary method limits targets only those who are on-campus, or whose institutions use a proxy-based remote authentication solution. The software we use, SirsiDynix's RPA, is not proxy-based, and is therefore incompatible with this method. (4) Even at those institutions who are employing proxy-based solutions (such as EZProxy), your dependence on IP address as a method for determining institutional affiliation assumes that patrons will already be operating in a proxied mode when they access the OpenURL link. This assumption again ignores what is bound to be an increasing trend in the future: OpenURLs which will appear *outside* of authenticated databases, on standard webpages. Please consider the prototypes currently deployed of the OpenURL COinS structure (see http://ocoins.info for more information) and/or client-side rewriting tools, such as Greasemonkey scripts, IE bookmarklets, and extensions/toolbars such as Openly's OpenURL Referrer -- http://www.openly.com/openurlref/ -- or Virginia Tech's LibX toolbar -- http://libx.org/ -- or others. The design of URL-rewriting proxy tools such as EZProxy makes it unlikely that the administrator of those tools will be able to anticipate and "proxy" all possible pages where incoming OpenURL links could appear, simply for the purpose of ensuring that the correct link resolver is chosen. I believe that it would be a much better choice for you to choose a structure for your LinkSource base URL that would specifically identify the LinkSource resolver that should be used. If you continue to insist that will not be necessary, I would appreciate more information about how you intend to mitigate the problems outlined above. Thanks in advance. Luke Rosenberger, Technology Librarian Automated Library Services, DSTC North Harris Montgomery Community College District 5000 Research Forest Dr The Woodlands TX 77381-4399 tel 832-813-6652 luke.rosenberger@nhmccd.edu ________________________________ From: EBSCO [mailto:EBSCOSupport@ebsco.com] Sent: Tuesday, November 15, 2005 11:45 To: Rosenberger, Luke E Subject: Case #69771 Update - New interface Authentication Hello Luke, After extensive research with our development team we have established that in the new LinkSource/A-to-Z interface, authentication will be checked in a system-specified order - the admin cannot change the order: If no cookie is present, then the following are checked: IP address, Username/Password (either one configured on LinkSource/A-to-Z or an Athens login.) LinkSource/A-to-Z will not support these authentication methods: Patron Files, CPID, Referring URL, or Shibboleth. There are future plans to consider offering Shibboleth authentication. As always, if we can be of service to you at any time in the future, please do not hesitate to contact A-to-Z with LinkSource Customer Care. Thanks, Tesa Williams A-to-Z with LinkSource Representative (877) 327-2622 (U.S.A. and Canada) (205) 981-4000 (Worldwide) Fax (205) 408-6194 Hours 7:00 A.M. to 5:00 P.M. CST EBSCO Information Services CUSTOMERFOCUSEDCONTENTDRIVEN -- AIM: lukethelibrarian / Yahoo Messenger: lukethelibrarian / MSN Messenger: lukethelibrarian@gmail.com "Oh, no, don't be sorry. You see, I don't believe that libraries should be drab places where people sit in silence, and that's been the main reason for our policy of employing wild animals as librarians." -- Graham Chapman as the Chairman in "Gorilla Librarian," Episode Ten, Monty Python's Flying Circus _______________________________________________ gcs-pcs-list mailing list gcs-pcs-list@cipolo.med.yale.edu http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3036 bytes Desc: not available Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20051116/209fdf3c/smime.bin From eric at openly.com Wed Nov 16 09:56:47 2005 From: eric at openly.com (Eric Hellman) Date: Wed Nov 16 09:56:57 2005 Subject: [gcs-pcs-list] Sanity check In-Reply-To: <183294552478444386C2B6B95D597E05022DC94E@IOWAEVS02.iowa.uiowa.edu> References: <183294552478444386C2B6B95D597E05022DC94E@IOWAEVS02.iowa.uiowa.edu> Message-ID: 1. Shibboleth does not solve the problem Luke cites- WAYF (where are you from) is really a difficult problem. Shibboleth has no support for the kind of authentication needed by services such as metasearch. Please don't expect all problems to go away if everybody were to support Shib. Do expect new problems to arise. 2. Proxy-server solutions can be made to work rather well. Not perfect, but pretty good. 3. You will be thankful for things like OpenWorldCat-in-Google. If you can't lead a horse to water, you don't even get a chance to make him drink. 4. I'm not convinced this has anything much to do with COinS, other than the fact that as OpenURL deployment grows, existing problems grow, too. If anything, client-side agents allow for more ways to solve the core WAYF and authentication problems. At 7:56 AM -0600 11/16/05, Forman, Andrew B wrote: >Luke, > >I think you've hit one of the main reasons why the current >authentication/authorization schemes in use are in desperate need of >overhaul. > >We're starting to look at Shibboleth as an answer to the overall problem, >but that will require our various vendors to begin supporting Shibboleth >(Elsevier has already joined InCommon, not sure of anyone else) or provide >other SAML-based interfaces. -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From ross.singer at library.gatech.edu Wed Nov 16 10:00:38 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Nov 16 10:00:50 2005 Subject: [Possible Spam]::RE: [gcs-pcs-list] Sanity check In-Reply-To: References: <183294552478444386C2B6B95D597E05022DC94E@IOWAEVS02.iowa.uiowa.edu> Message-ID: <437B4996.7020701@library.gatech.edu> However, this particular problem is pretty easily remedied by just having some semblance of institutional association in the resolver url somewhere. I agree that WAYF is a big problem, but implementations like this do little to solve it. -Ross. Eric Hellman wrote: > 1. Shibboleth does not solve the problem Luke cites- WAYF (where are > you from) is really a difficult problem. Shibboleth has no support for > the kind of authentication needed by services such as metasearch. > Please don't expect all problems to go away if everybody were to > support Shib. Do expect new problems to arise. > > 2. Proxy-server solutions can be made to work rather well. Not > perfect, but pretty good. > > 3. You will be thankful for things like OpenWorldCat-in-Google. If you > can't lead a horse to water, you don't even get a chance to make him > drink. > > 4. I'm not convinced this has anything much to do with COinS, other > than the fact that as OpenURL deployment grows, existing problems > grow, too. If anything, client-side agents allow for more ways to > solve the core WAYF and authentication problems. > > > At 7:56 AM -0600 11/16/05, Forman, Andrew B wrote: > >> Luke, >> >> I think you've hit one of the main reasons why the current >> authentication/authorization schemes in use are in desperate need of >> overhaul. >> >> We're starting to look at Shibboleth as an answer to the overall >> problem, >> but that will require our various vendors to begin supporting Shibboleth >> (Elsevier has already joined InCommon, not sure of anyone else) or >> provide >> other SAML-based interfaces. > > From godmar at gmail.com Wed Nov 16 10:37:45 2005 From: godmar at gmail.com (Godmar Back) Date: Wed Nov 16 10:37:49 2005 Subject: [Possible Spam]::RE: [gcs-pcs-list] Sanity check In-Reply-To: <437B4996.7020701@library.gatech.edu> References: <183294552478444386C2B6B95D597E05022DC94E@IOWAEVS02.iowa.uiowa.edu> <437B4996.7020701@library.gatech.edu> Message-ID: <719dced30511160737s31204689l910d99ca50b93de6@mail.gmail.com> Does anybody know what specifically EBSCO is afraid of that makes them require authentication just for OpenURL resolution? Does their OpenURL resolver provide some added service (maybe full bibliographic records?) that they don't want just anybody to see for fear it could be data-mined? - Godmar On 11/16/05, Ross Singer wrote: > However, this particular problem is pretty easily remedied by just > having some semblance of institutional association in the resolver url > somewhere. > > I agree that WAYF is a big problem, but implementations like this do > little to solve it. > > -Ross. > > Eric Hellman wrote: > > > 1. Shibboleth does not solve the problem Luke cites- WAYF (where are > > you from) is really a difficult problem. Shibboleth has no support for > > the kind of authentication needed by services such as metasearch. > > Please don't expect all problems to go away if everybody were to > > support Shib. Do expect new problems to arise. > > > > 2. Proxy-server solutions can be made to work rather well. Not > > perfect, but pretty good. > > > > 3. You will be thankful for things like OpenWorldCat-in-Google. If you > > can't lead a horse to water, you don't even get a chance to make him > > drink. > > > > 4. I'm not convinced this has anything much to do with COinS, other > > than the fact that as OpenURL deployment grows, existing problems > > grow, too. If anything, client-side agents allow for more ways to > > solve the core WAYF and authentication problems. > > > > > > At 7:56 AM -0600 11/16/05, Forman, Andrew B wrote: > > > >> Luke, > >> > >> I think you've hit one of the main reasons why the current > >> authentication/authorization schemes in use are in desperate need of > >> overhaul. > >> > >> We're starting to look at Shibboleth as an answer to the overall > >> problem, > >> but that will require our various vendors to begin supporting Shibboleth > >> (Elsevier has already joined InCommon, not sure of anyone else) or > >> provide > >> other SAML-based interfaces. > > > > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From shultzs at oclc.org Wed Nov 16 10:39:35 2005 From: shultzs at oclc.org (Shultz,Scott) Date: Wed Nov 16 10:39:39 2005 Subject: [gcs-pcs-list] RE: gcs-pcs-list Digest, Vol 12, Issue 3 Message-ID: My name is Scott Shultz. I am the (new) product manager for registry services here at OCLC. My first project is the OpenURL Resolver Registry that Phil Norman from OCLC has been managing to date. While it certainly doesn't address all your needs, I just wanted to be sure you are aware of the OpenURL Resolver registry (http://www.oclc.org/productworks/urlresolver.htm) from OCLC. The main goal for the registry is for it to solve the "many-to-many" problem between libraries and the growing list of OpenURL-related service partners. The registry provides libraries with a free central location to easily register their OpenURL resolver, enabling their collection to surface with patrons through our list of partners. The partners get access to a comprehensive registry of libraries and their OpenURL Resolver information without a heavy investment in infrastructure to build it themselves. We offer a free Gateway service that helps resolve a library patron to their instituion based on registry entries. I'll point out that I think it is important to separate WAYF from authentication - these are separate functions and should be considered individually. While the registry doesn't offer any magic bullets to the authentication issues you raise, I do think the registry can help with the WAYF issue: 1) Our OpenURL Resolver registry will first attempt to match up a patron with their institution via IP address checking. This in and of itself doesn't solve the basic WAYF issue you expressed with EBSCO - it really just tries to do the same thing they are doing - but it does provide a central place for these registrations to reside (instead of residing in closed vendor-specific registries). Our registry allows the resolver info to be shared among all service-providing partners. 2) Shibboleth doesn't explicitly solve the problem either, although I think Athens authentication comes closer. We are currently examining several authentication options. Again, keep in mind that while we are not trying to provide an authentication engine, there may be opportunities to insert that step in our process. 3) A last fallback for when we can't associate a patron with a library is to provide a "Choose your library from this list" option to allow users to choose their institution (not yet implemented in our Alpha project but seriously being considered for the Beta). While this approach certainly won't authenticate the patron in any way, it does get them on their way to their institution's resolver, where they will likely need to authenticate themselves in some way to proceed. Again, separation of WAYF from authentication... In order for this program to be successful and provide maximum value to all stakeholders, the registry needs to become *the* comprehensive list of library resolvers, and also secure as many partners as we can. If you have questions, suggestions, or want more info please see the website or feel free to contact me directly. Scott Shultz shultzs@oclc.org 614-761-5333 From lukethelibrarian at gmail.com Wed Nov 16 11:53:17 2005 From: lukethelibrarian at gmail.com (Luke Rosenberger) Date: Wed Nov 16 11:55:19 2005 Subject: [gcs-pcs-list] Sanity check Message-ID: On 11/16/05, Godmar Back wrote: > Does anybody know what specifically EBSCO is afraid of that makes them > require authentication just for OpenURL resolution? > > Does their OpenURL resolver provide some added service (maybe full > bibliographic records?) that they don't want just anybody to see for > fear it could be data-mined? I just wanted folks on this list to know that my conversation with EBSCO has continued today in a more productive fashion. It appears that EBSCO will offer an optional way to specify the institution as part of the base URL, and they will allow the administrator to choose which subset of LinkSource links (or all of them, if desired) to make visible to non-authenticated users. Here is the first response I received from EBSCO: -----Original Message----- From: EBSCO Sent: Wednesday, November 16, 2005 06:36 am CST (GMT-06:00) Subject: New interface Authentication Hello Luke, LinkSource will accept a URL that specifically identifies your institution. The format for passing this information would be: http://linksource.ebsco.com/linking.aspx?sec.code=xxxx&<...context object?> (where xxxx is your institution's A-to-Z customer code.) This will facilitate identification of your institution's end users by LinkSource. The next piece to this is that although we will know which institution's LinkSource to use, LinkSource will still try to authenticate the user. One of the new features of the new LinkSource is that you can configure it to allow "unauthorized" users with access to a subset of links on the LinkSource menu (e.g. those that don't provide pre-authenticated access to resources). This way you can give access to those customers who do not authenticated via IP (or have a cookie from a previous LinkSource session.) For the future we will address allowing the customer to identify their own account as part of the base URL as well we are looking at how best to incorporate Shibboleth with LinkSource to make the experience as seamless as possible. -----End Original Message----- To clarify, I wanted to make sure that in my case, where all outbound links from LinkSource to licensed content go through our Remote Patron Authentication system, I would be able to present exactly the same LinkSource menu to authenticated and non-authenticated users. EBSCO responded: -----Original Message----- From: EBSCO Sent: Wednesday, November 16, 2005 10:08 Subject: Case #69771 Update - New interface Authentication Luke, In the new interface the LinkSource menu can be configured to look the same for both authentication and non-authenticated users. -----End Original Message----- That pretty much settles my concerns about the situation for now. If you see other potential problems, I'd be interested in any other feedback you could provide -- I appreciate the discussion and feedback you've provided. -- AIM: lukethelibrarian / Yahoo Messenger: lukethelibrarian / MSN Messenger: lukethelibrarian@gmail.com "Oh, no, don't be sorry. You see, I don't believe that libraries should be drab places where people sit in silence, and that's been the main reason for our policy of employing wild animals as librarians." -- Graham Chapman as the Chairman in "Gorilla Librarian," Episode Ten, Monty Python's Flying Circus From daniel.chudnov at yale.edu Fri Nov 18 09:50:49 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Nov 18 09:50:54 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes Message-ID: <20051118145049.GE1382@curtis.med.yale.edu> Fyi, along the lines of the first greasemonkey COinS-PMH hack for American Memory, there are now similar hacks for Flickr and Amazon.com, along with the arxiv.org one previously posted. Also, unalog supports it natively, so additional examples can be seen at unalog.com and links.med.yale.edu (Yale's unalog instance), along with Peter's wordpress instance. http://flickr.com/photos/dchud/tags/coinspmh/ It makes for a powerful demonstration to open adjacent firefox tabs (with greasemonkey off) for each of those sites, then to turn greasemonkey on and reload each in turn. I did this yesterday for a number of colleagues and there was a lot of nodding (which I take to be favorable) and a lot of head-shaking (which I take to be favorable :). We've been somewhat slack about the suggested "ROGUE 05" process, but perhaps a more seriousness might be worthwhile. I'll assume there is enough interest to continue, and propose the following changes to the spec, with a revision to be released by November 27: (1) Change the name to unAPI. ("un API", or "una PI", mixing noun genders in keeping with actual practice). Caps optional! The goals of the name change are (a) have a better name, (b) have a shorter name, (c) reinforce that it's about having the same basic interface to many types of content services. (2) Recommend (or require) that COinS CO data for COinS-PMH (a.k.a. "newname") have titles in rft.title. Makes for more informative sidebar or popup menu or whatever thingies. (3) Recommend that PMH services support a convention for Sets called "virtual:URL-ENCODED-PAGE-URL", e.g. "virtual:person:dchud" for unalog, and support a ListRecords verb that would return a virtual recordset comprising items from that page/path. This could potentially lower the necessary number of PMH calls for a single page to two (one ListMetadataFormats, one ListRecords with the set spec). I have *no* idea if the OAIPMH folks would approve (should ask!). Any/all feedback will be rewarded handsomely. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jeremy.frumkin at oregonstate.edu Fri Nov 18 10:23:41 2005 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Fri Nov 18 10:27:02 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: <20051118145049.GE1382@curtis.med.yale.edu> Message-ID: I actually did the demo Dan described below for some folks here at the NSDL meeting, and the same nodding head response ensued. I?m not sure if we?re looking at an induced response, but I took the response to be quite positive ? an ?aha!? moment. Dan ? one quick question of clarification: The name change you are suggesting below is to change COinS-PMH to unAPI? It wasn?t clear to me if you were suggesting to change the COinS-PMH spec, or the standards process spec (i.e. Change ROGUE 05 to unAPI). I?m thinking the former, but wanted to make sure that is correct. I?m not sure I?m getting the ?virtual:URL-ENCODED-PAGE-URL? idea ? could you provide a simple walk-through case utilizing it? -- jf On 11/18/05 6:50 AM, "Daniel Chudnov" wrote: > Fyi, along the lines of the first greasemonkey COinS-PMH hack for American > Memory, there are now similar hacks for Flickr and Amazon.com, along with > the arxiv.org one previously posted. Also, unalog supports it natively, > so additional examples can be seen at unalog.com and links.med.yale.edu > (Yale's unalog instance), along with Peter's wordpress instance. > > http://flickr.com/photos/dchud/tags/coinspmh/ > > It makes for a powerful demonstration to open adjacent firefox tabs (with > greasemonkey off) for each of those sites, then to turn greasemonkey on > and reload each in turn. I did this yesterday for a number of colleagues > and there was a lot of nodding (which I take to be favorable) and a lot > of head-shaking (which I take to be favorable :). > > We've been somewhat slack about the suggested "ROGUE 05" process, but > perhaps a more seriousness might be worthwhile. I'll assume there is > enough interest to continue, and propose the following changes to the > spec, with a revision to be released by November 27: > > > (1) Change the name to unAPI. ("un API", or "una PI", mixing > noun genders in keeping with actual practice). Caps optional! > The goals of the name change are (a) have a better name, (b) have > a shorter name, (c) reinforce that it's about having the same basic > interface to many types of content services. > > (2) Recommend (or require) that COinS CO data for COinS-PMH (a.k.a. > "newname") have titles in rft.title. Makes for more informative > sidebar or popup menu or whatever thingies. > > (3) Recommend that PMH services support a convention for Sets called > "virtual:URL-ENCODED-PAGE-URL", e.g. "virtual:person:dchud" > for unalog, and support a ListRecords verb that would return a > virtual recordset comprising items from that page/path. This could > potentially lower the necessary number of PMH calls for a single page > to two (one ListMetadataFormats, one ListRecords with the set spec). > I have *no* idea if the OAIPMH folks would approve (should ask!). > > > Any/all feedback will be rewarded handsomely. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20051118/f5b5d4f7/attachment.htm From daniel.chudnov at yale.edu Fri Nov 18 10:36:09 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Nov 18 10:36:13 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: References: <20051118145049.GE1382@curtis.med.yale.edu> Message-ID: <20051118153608.GG1382@curtis.med.yale.edu> Jeremy Frumkin wrote, on Fri, Nov 18, 2005 at 07:23:41AM -0800: > I actually did the demo Dan described below for some folks here at the NSDL > meeting, and the same nodding head response ensued. I?m not sure if we?re > looking at an induced response, but I took the response to be quite positive > ? an ?aha!? moment. Cool! > Dan ? one quick question of clarification: The name change you are > suggesting below is to change COinS-PMH to unAPI? It wasn?t clear to me if > you were suggesting to change the COinS-PMH spec, or the standards process > spec (i.e. Change ROGUE 05 to unAPI). I?m thinking the former, but wanted to > make sure that is correct. I'm proposing changing the name of COinS-PMH to unAPI. > I'm not sure I'm getting the virtual:URL-ENCODED-PAGE-URL idea ? could you > provide a simple walk-through case utilizing it? Visit a unalog page with the monkey and scripts enabled. You'll see 50 or so entries at right and the same number at left. At present, all 50 generated metadata links are just links for GetRecord queries back to the PMH service. So, to generate that took only one PMH query; the rest is DHTML (or ajax if you prefer). The problem comes in if you want to get all 50 of those records. Currently there's no deterministic way to do that without sending 50 more queries. The proposed virtual:PATH set spec theoretically provides a convention that allows a single PMH request/response to encapsulate all 50 records. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jeremy.frumkin at oregonstate.edu Fri Nov 18 10:49:51 2005 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Fri Nov 18 10:49:49 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: <20051118153608.GG1382@curtis.med.yale.edu> Message-ID: Dan described: > Visit a unalog page with the monkey and scripts enabled. You'll see > 50 or so entries at right and the same number at left. At present, > all 50 generated metadata links are just links for GetRecord queries > back to the PMH service. So, to generate that took only one PMH query; > the rest is DHTML (or ajax if you prefer). > > The problem comes in if you want to get all 50 of those records. > Currently there's no deterministic way to do that without sending 50 > more queries. The proposed virtual:PATH set spec theoretically provides > a convention that allows a single PMH request/response to encapsulate > all 50 records. Ok, gotcha. So, thinking about this from some different perspectives: 1) I am doubtful that the OAI-PMH folks will go for this idea insomuch that it seems to be moving away from the general harvesting philosophy. Although you are suggesting a way to harvest full records in batch, the set you are going to harvest is a very dynamically selective set, as opposed to a general range. That being said, I would be interested in understanding how extending the OAI-PMH spec to allow for more flexible types of harvesting batches of records. 2) Obviously, current OAI-Servers won't support this type of ListRecords request, so it might be useful to extend a current OAI-Server tool to support this function. 3) I imagine the SRU/W folks would chime in, "if you used SRU/W instead of OAI-PMH, you would already have this ability". However, SRU/W is not nearly as lightweight as OAI-PMH. I can most definitely see the utility of this - otherwise, server/network load goes up, and also latency problems become increased. -- jf From Peter.Binkley at ualberta.ca Fri Nov 18 11:51:52 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Fri Nov 18 11:51:56 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes Message-ID: <908893006339C0409519E4065DF3B24901570E41@mailserver.ualibrary.ualberta.ca> Another approach would be to add a GetRecords verb to OAI-PMH, that allowed you to send a delimited list of identifiers. That would put the onus on the client to assemble the list of desired records, rather than requiring the server to map a virtual set to a collection of records, which might be tricky in some cases. The response might use resumption tokens to manage large requests. I'm not sure the OAI folks would be receptive to the idea of a new verb, though... Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Daniel Chudnov > Sent: Friday, November 18, 2005 08:36 AM > To: Jeremy Frumkin > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] more COinS-PMH: demos, process, changes > > Jeremy Frumkin wrote, on Fri, Nov 18, 2005 at 07:23:41AM -0800: > > I actually did the demo Dan described below for some folks > here at the > > NSDL meeting, and the same nodding head response ensued. > I?m not sure > > if we?re looking at an induced response, but I took the > response to be > > quite positive ? an ?aha!? moment. > > Cool! > > > > Dan ? one quick question of clarification: The name change you are > > suggesting below is to change COinS-PMH to unAPI? It wasn?t > clear to > > me if you were suggesting to change the COinS-PMH spec, or the > > standards process spec (i.e. Change ROGUE 05 to unAPI). I?m > thinking > > the former, but wanted to make sure that is correct. > > I'm proposing changing the name of COinS-PMH to unAPI. > > > > I'm not sure I'm getting the virtual:URL-ENCODED-PAGE-URL > idea ? could > > you provide a simple walk-through case utilizing it? > > Visit a unalog page with the monkey and scripts enabled. > You'll see 50 or so entries at right and the same number at > left. At present, all 50 generated metadata links are just > links for GetRecord queries back to the PMH service. So, to > generate that took only one PMH query; the rest is DHTML (or > ajax if you prefer). > > The problem comes in if you want to get all 50 of those records. > Currently there's no deterministic way to do that without > sending 50 more queries. The proposed virtual:PATH set spec > theoretically provides a convention that allows a single PMH > request/response to encapsulate all 50 records. > > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Fri Nov 18 11:54:22 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Nov 18 11:54:32 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: <20051118145049.GE1382@curtis.med.yale.edu> References: <20051118145049.GE1382@curtis.med.yale.edu> Message-ID: <437E073E.9000509@library.gatech.edu> Daniel Chudnov wrote: >(1) Change the name to unAPI. ("un API", or "una PI", mixing > noun genders in keeping with actual practice). Caps optional! > The goals of the name change are (a) have a better name, (b) have > a shorter name, (c) reinforce that it's about having the same basic > interface to many types of content services. > > I needed Dan to clarify this for me, and I'll try to reconstruct what I got from it. I was concerned about changing the name from COinS-* to something else because I feared it would generate confusion by having two different names for identical COinS tags. However: 1) The spans themselves would still be called COinS 2) It's the actual interaction with OAI that would be unAPI (or whatever) 3) It would open the door to make this "implementation agnostic" (COinS, Microformats, etc.) Dan, is that somewhat accurate? >(2) Recommend (or require) that COinS CO data for COinS-PMH (a.k.a. > "newname") have titles in rft.title. Makes for more informative > sidebar or popup menu or whatever thingies. > > This could be somewhat problematic as a "requirement". I suggest "recommendation". -Ross. From ross.singer at library.gatech.edu Fri Nov 18 12:04:16 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Nov 18 12:04:27 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: References: Message-ID: <437E0990.7040308@library.gatech.edu> Jeremy Frumkin wrote: >3) I imagine the SRU/W folks would chime in, "if you used SRU/W instead of >OAI-PMH, you would already have this ability". However, SRU/W is not nearly >as lightweight as OAI-PMH. > > I actually just submitted a presentation proposal last night that suggested using SRW/U as the backend for an OAI-PMH server. The "archive" and "collections" would be dynamic (and not all verbs would be supported, most likely), but would make SRW/U servers fully harvestable. -Ross. From jyoung at oclc.org Fri Nov 18 12:12:36 2005 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Nov 18 12:12:40 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes Message-ID: This sounds familiar. http://www.dlib.org/dlib/february05/sanderson/02sanderson.html Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Ross Singer > Sent: Friday, November 18, 2005 12:04 PM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] more COinS-PMH: demos, process, changes > > Jeremy Frumkin wrote: > > >3) I imagine the SRU/W folks would chime in, "if you used SRU/W instead > of > >OAI-PMH, you would already have this ability". However, SRU/W is not > nearly > >as lightweight as OAI-PMH. > > > > > I actually just submitted a presentation proposal last night that > suggested using SRW/U as the backend for an OAI-PMH server. The > "archive" and "collections" would be dynamic (and not all verbs would be > supported, most likely), but would make SRW/U servers fully harvestable. > > -Ross. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ross.singer at library.gatech.edu Fri Nov 18 12:16:06 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Nov 18 12:16:17 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: References: Message-ID: <437E0C56.2030905@library.gatech.edu> Good point. I didn't say my idea was original, and in fact this isn't even the real point of my presentation proposal (which is just that when you get your bib data to XML, the world is your oyster). So, yeah... good article, btw. -Ross. Young,Jeff (OR) wrote: >This sounds familiar. > >http://www.dlib.org/dlib/february05/sanderson/02sanderson.html > >Jeff > > > >>-----Original Message----- >>From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- >>bounces@cipolo.med.yale.edu] On Behalf Of Ross Singer >>Sent: Friday, November 18, 2005 12:04 PM >>To: gcs-pcs-list@cipolo.med.yale.edu >>Subject: Re: [gcs-pcs-list] more COinS-PMH: demos, process, changes >> >>Jeremy Frumkin wrote: >> >> >> >>>3) I imagine the SRU/W folks would chime in, "if you used SRU/W >>> >>> >instead > > >>of >> >> >>>OAI-PMH, you would already have this ability". However, SRU/W is not >>> >>> >>nearly >> >> >>>as lightweight as OAI-PMH. >>> >>> >>> >>> >>I actually just submitted a presentation proposal last night that >>suggested using SRW/U as the backend for an OAI-PMH server. The >>"archive" and "collections" would be dynamic (and not all verbs would >> >> >be > > >>supported, most likely), but would make SRW/U servers fully >> >> >harvestable. > > >>-Ross. >>_______________________________________________ >>gcs-pcs-list mailing list >>gcs-pcs-list@cipolo.med.yale.edu >>http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> >> > > > From daniel.chudnov at yale.edu Fri Nov 18 12:16:44 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Nov 18 12:16:49 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: References: <20051118153608.GG1382@curtis.med.yale.edu> Message-ID: <20051118171644.GK1382@curtis.med.yale.edu> Jeremy Frumkin wrote, on Fri, Nov 18, 2005 at 07:49:51AM -0800: > > 1) I am doubtful that the OAI-PMH folks will go for this idea insomuch that > it seems to be moving away from the general harvesting philosophy. Although > you are suggesting a way to harvest full records in batch, the set you are > going to harvest is a very dynamically selective set, as opposed to a > general range. That being said, I would be interested in understanding how > extending the OAI-PMH spec to allow for more flexible types of harvesting > batches of records. This isn't extending the spec, and we don't need them to go for it... it would just be a convention for a "virtual" set spec. That said, it would be preferable for them to not think it's evil. And, good point about the range thing. > 2) Obviously, current OAI-Servers won't support this type of ListRecords > request, so it might be useful to extend a current OAI-Server tool to > support this function. Definitely not. The faux-AI servers I've written (for unalog and for the flickr/amazon proxies) are specific to this purpose anyway, so it shouldn't be hard to change those. Or, actually, the flickr/amazon proxy doesn't even deal with multiple items per page, so, no worries there. > 3) I imagine the SRU/W folks would chime in, "if you used SRU/W instead of > OAI-PMH, you would already have this ability". However, SRU/W is not nearly > as lightweight as OAI-PMH. I think this confuses things. SRU search result sets are just that... I'm talking about just referencing the exact same content set that some arbitrary page references. Some pages might comprise SRU search result sets... others might be date-range browses (which might match the spirit of the OAI verb more closely), or any other kind of item or browse view, which aren't like anything OAI-PMH yet supports directly by design. Imho the confusion really kicks in when you start to trade off questions about whether this stuff should be about Z39.88-style service resolution or "hard-coded" links to OAI services, an issue both Ross and Kristina have wisely raised. And for which I have no answer. :( -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Nov 18 12:31:10 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Nov 18 12:31:16 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: <908893006339C0409519E4065DF3B24901570E41@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570E41@mailserver.ualibrary.ualberta.ca> Message-ID: <20051118173110.GM1382@curtis.med.yale.edu> Binkley, Peter wrote, on Fri, Nov 18, 2005 at 09:51:52AM -0700: > Another approach would be to add a GetRecords verb to OAI-PMH, that > allowed you to send a delimited list of identifiers. That would put the > onus on the client to assemble the list of desired records, rather than > requiring the server to map a virtual set to a collection of records, > which might be tricky in some cases. The response might use resumption > tokens to manage large requests. I'm not sure the OAI folks would be > receptive to the idea of a new verb, though... I think the "add something to OAI-PMH proper" is not reasonable. This is one thing the microformats people have right. :) That said, it *is* worth asking them if we find any consensus about whether the idea is worthwhile at all. Maybe they've already run into it. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jyoung at oclc.org Fri Nov 18 12:31:09 2005 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Nov 18 12:31:21 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes Message-ID: I took some heat a few years ago for adding verbs to the baseURL for one of my repositories. My solution was to alter the baseURL ever so slightly for the extension verbs. Normal verb=GetRecord: http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecord&metadataPrefix=xsd&identifier=info:ofi/fmt:xml:xsd:dissertation Extension verb=GetMetadata: http://alcme.oclc.org/openurl/servlet/OAIHandler/extension?verb=GetMetadata&metadataPrefix=xsd&identifier=info:ofi/fmt:xml:xsd:dissertation Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Binkley, Peter > Sent: Friday, November 18, 2005 11:52 AM > To: daniel.chudnov@yale.edu; Jeremy Frumkin > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: RE: [gcs-pcs-list] more COinS-PMH: demos, process, changes > > Another approach would be to add a GetRecords verb to OAI-PMH, that > allowed you to send a delimited list of identifiers. That would put the > onus on the client to assemble the list of desired records, rather than > requiring the server to map a virtual set to a collection of records, > which might be tricky in some cases. The response might use resumption > tokens to manage large requests. I'm not sure the OAI folks would be > receptive to the idea of a new verb, though... > > Peter > > > -----Original Message----- > > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > > Of Daniel Chudnov > > Sent: Friday, November 18, 2005 08:36 AM > > To: Jeremy Frumkin > > Cc: gcs-pcs-list@cipolo.med.yale.edu > > Subject: Re: [gcs-pcs-list] more COinS-PMH: demos, process, changes > > > > Jeremy Frumkin wrote, on Fri, Nov 18, 2005 at 07:23:41AM -0800: > > > I actually did the demo Dan described below for some folks > > here at the > > > NSDL meeting, and the same nodding head response ensued. > > I?m not sure > > > if we?re looking at an induced response, but I took the > > response to be > > > quite positive ? an ?aha!? moment. > > > > Cool! > > > > > > > Dan ? one quick question of clarification: The name change you are > > > suggesting below is to change COinS-PMH to unAPI? It wasn?t > > clear to > > > me if you were suggesting to change the COinS-PMH spec, or the > > > standards process spec (i.e. Change ROGUE 05 to unAPI). I?m > > thinking > > > the former, but wanted to make sure that is correct. > > > > I'm proposing changing the name of COinS-PMH to unAPI. > > > > > > > I'm not sure I'm getting the virtual:URL-ENCODED-PAGE-URL > > idea ? could > > > you provide a simple walk-through case utilizing it? > > > > Visit a unalog page with the monkey and scripts enabled. > > You'll see 50 or so entries at right and the same number at > > left. At present, all 50 generated metadata links are just > > links for GetRecord queries back to the PMH service. So, to > > generate that took only one PMH query; the rest is DHTML (or > > ajax if you prefer). > > > > The problem comes in if you want to get all 50 of those records. > > Currently there's no deterministic way to do that without > > sending 50 more queries. The proposed virtual:PATH set spec > > theoretically provides a convention that allows a single PMH > > request/response to encapsulate all 50 records. > > > > > > -Dan > > > > > > -- > > Daniel Chudnov > > Yale Center for Medical Informatics > > (203) 737-5789 > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From daniel.chudnov at yale.edu Fri Nov 18 12:36:15 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Nov 18 12:36:20 2005 Subject: [gcs-pcs-list] more COinS-PMH: demos, process, changes In-Reply-To: <437E073E.9000509@library.gatech.edu> References: <20051118145049.GE1382@curtis.med.yale.edu> <437E073E.9000509@library.gatech.edu> Message-ID: <20051118173615.GN1382@curtis.med.yale.edu> Ross Singer wrote, on Fri, Nov 18, 2005 at 11:54:22AM -0500: > Daniel Chudnov wrote: > > >(1) Change the name to unAPI. ("un API", or "una PI", mixing > > noun genders in keeping with actual practice). Caps optional! > > The goals of the name change are (a) have a better name, (b) have > > a shorter name, (c) reinforce that it's about having the same basic > > interface to many types of content services. > > > I needed Dan to clarify this for me, and I'll try to reconstruct what I > got from it. > I was concerned about changing the name from COinS-* to something else > because I feared it would generate confusion by having two different > names for identical COinS tags. > However: > 1) The spans themselves would still be called COinS > 2) It's the actual interaction with OAI that would be unAPI (or > whatever) > 3) It would open the door to make this "implementation agnostic" > (COinS, Microformats, etc.) > Dan, is that somewhat accurate? 1) Yes... the spec says "use COinS, and when you do...". That wouldn't change. 2) Er, yeah. 3) Yes, exactly. Ideally the unAPI could be a starting point that could grow more functions. > >(2) Recommend (or require) that COinS CO data for COinS-PMH (a.k.a. > > "newname") have titles in rft.title. Makes for more informative > > sidebar or popup menu or whatever thingies. > > > This could be somewhat problematic as a "requirement". I suggest > "recommendation". I'm leaning the same way. Is it reasonable to have any "recommendations" at all, though? That's what gets me. It seems somehow wrong to have a "minimally functional" spec with *any* optionality. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From godmar at gmail.com Sun Nov 20 14:01:48 2005 From: godmar at gmail.com (Godmar Back) Date: Sun Nov 20 14:01:54 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH Message-ID: <719dced30511201101q22baa816h7b8aafeb88652e2b@mail.gmail.com> Hi, I asked Dan a few questions about his coins-pmh and the amazon mixer greasemonkey scripts, which I then tested, and he suggested I take some of our discussion on list. The main question that I would like answered if OAI-PMH is something that we should include into LibX (libx.org), the client-side infrastructure we are building to integrate the library into a user's webflow (credit to Lorcan Dempsey for describing LibX this way.) LibX already supports COinS. >From a brief web search and skimming of the documents on OAI that are out there, I understand that OAI is a distributed architecture for archiving electronic documents and other resources, and PMH is some kind of protocol on top of it that allows metadata about those resources to be exchanged among various service and data providers/repositories. So, let me cut right to the chase, and I hope this list is not an inappropriate place to ask this question: Is OAI/OAI-PMH something that's here today, and if so, in what way would you like to see support for it integrated into your browser (or, if you don't like client-side solutions, into your OpenURL resolution server)? One feature I would like to offer users is full bibliographic data for any article. If a user sees a reference to a research paper, they should be able to select it, and with one or two clicks a) get the paper and b) an Endnote or bibtex record for the paper. Libx already provides a) through Scholar+OpenURL - could OAI-PMH provide b), today? Thanks! - Godmar From daniel.chudnov at yale.edu Sun Nov 20 17:14:01 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Nov 20 17:14:07 2005 Subject: [gcs-pcs-list] Re: COinS-PMH, LibX, and OAI-PMH In-Reply-To: <719dced30511201101q22baa816h7b8aafeb88652e2b@mail.gmail.com> References: <719dced30511201101q22baa816h7b8aafeb88652e2b@mail.gmail.com> Message-ID: <19AAABCE-923B-4ABA-A454-74C09F0BA756@yale.edu> Some brief responses: On Nov 20, 2005, at 2:01 PM, Godmar Back wrote: > > From a brief web search and skimming of the documents on OAI that are > out there, I understand that OAI is a distributed architecture for > archiving electronic documents and other resources, and PMH is some > kind of protocol on top of it that allows metadata about those > resources to be exchanged among various service and data > providers/repositories. As a point of information, there is an unfortunate name clash between OAIS (Open Archival Information System), for which an excellent reference model document has provided a widely adopted approach to repository architectures, and the OAI (Open Archives Initiative), which has produced OAI-PMH, the protocol for metadata harvesting (PMH). It is even more confusing because the OAI-PMH protocol is often used with systems which implement OAIS-style architectures, but they are distinct entities from distinct initiatives. OAIS Reference Model: http://ssdoo.gsfc.nasa.gov/nost/isoas/ OAI: http://www.openarchives.org/ OAI-PMH: http://www.openarchives.org/OAI/openarchivesprotocol.html > One feature I would like to offer users is full bibliographic data for > any article. If a user sees a reference to a research paper, they > should be able to select it, and with one or two clicks a) get the > paper and b) an Endnote or bibtex record for the paper. This is exactly the kind of featureset to support which I've been pushing on COinS-PMH. I just don't want to limit our use cases to the scholarly context, hence the demos for flickr, amazon, etc.. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Sun Nov 20 20:43:52 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sun Nov 20 20:44:12 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH In-Reply-To: <719dced30511201101q22baa816h7b8aafeb88652e2b@mail.gmail.com> References: <719dced30511201101q22baa816h7b8aafeb88652e2b@mail.gmail.com> Message-ID: <9ff833e61b17c6910938cb4465c8ab27@library.gatech.edu> Godmar, This is a tricky question. OAI-PMH is certainly "there yet" in regards to a traditional "server A asks server B for records and harvests them" model. Dan's proposal shifts the model from "server-to-machine" to "server-to-user". The cool thing about this is that it "gives" our data to the user to do with it whatever he or she may desire to do with it. The downside is, well, that there's currently not really anything out there /to do/ with it right now. Your idea of making the data available to EndNote/RefWorks/BibTex is exactly the sort of use unAPI (nee COinS-PMH) /needs/. However, I'm not sure how easy it would be to get something like DC into something useful to these apps. There are, of course, other uses for unAPI data, as well, but I think you're clarifying a fairly big problem in "client development" for it. When the purpose for implementing unAPI is so users can "do whatever they want" with your data, it's pretty difficult to create a client without a fairly specific purpose for what to do with that data. So, the real key here is finding/making services that can do things with this data. -Ross. On Nov 20, 2005, at 2:01 PM, Godmar Back wrote: > Hi, > > I asked Dan a few questions about his coins-pmh and the amazon mixer > greasemonkey > scripts, which I then tested, and he suggested I take some of our > discussion on list. > > The main question that I would like answered if OAI-PMH is something > that we should include into LibX (libx.org), the client-side > infrastructure we are building to integrate the library into a user's > webflow (credit to Lorcan Dempsey for describing LibX this way.) LibX > already supports COinS. > >> From a brief web search and skimming of the documents on OAI that are > out there, I understand that OAI is a distributed architecture for > archiving electronic documents and other resources, and PMH is some > kind of protocol on top of it that allows metadata about those > resources to be exchanged among various service and data > providers/repositories. > > So, let me cut right to the chase, and I hope this list is not an > inappropriate place to ask this question: > > Is OAI/OAI-PMH something that's here today, and if so, in what way > would you like to see support for it integrated into your browser (or, > if you don't like client-side solutions, into your OpenURL resolution > server)? > > One feature I would like to offer users is full bibliographic data for > any article. If a user sees a reference to a research paper, they > should be able to select it, and with one or two clicks a) get the > paper and b) an Endnote or bibtex record for the paper. > > Libx already provides a) through Scholar+OpenURL - could OAI-PMH > provide b), today? > > Thanks! > > - Godmar > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From Peter.Binkley at ualberta.ca Mon Nov 21 12:23:33 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Mon Nov 21 12:23:40 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH Message-ID: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> I'd say that if we *can't* get the metadata into the metadata-management tools our users are using, COinS-PMH won't take off. That may require making LibX capable of handling more complex metadata formats like MODS. Or maybe tools like RefWorks can already handle it. Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Ross Singer > Sent: Sunday, November 20, 2005 06:44 PM > To: Godmar Back > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH > > Godmar, > > This is a tricky question. OAI-PMH is certainly "there yet" > in regards to a traditional "server A asks server B for > records and harvests them" > model. > > Dan's proposal shifts the model from "server-to-machine" to > "server-to-user". The cool thing about this is that it > "gives" our data to the user to do with it whatever he or she > may desire to do with it. > > The downside is, well, that there's currently not really > anything out there /to do/ with it right now. > > Your idea of making the data available to > EndNote/RefWorks/BibTex is exactly the sort of use unAPI (nee > COinS-PMH) /needs/. However, I'm not sure how easy it would > be to get something like DC into something useful to these apps. > > There are, of course, other uses for unAPI data, as well, but > I think you're clarifying a fairly big problem in "client > development" for it. > When the purpose for implementing unAPI is so users can "do > whatever they want" with your data, it's pretty difficult to > create a client without a fairly specific purpose for what to > do with that data. > > So, the real key here is finding/making services that can do > things with this data. > > -Ross. > > On Nov 20, 2005, at 2:01 PM, Godmar Back wrote: > > > Hi, > > > > I asked Dan a few questions about his coins-pmh and the > amazon mixer > > greasemonkey scripts, which I then tested, and he suggested I take > > some of our discussion on list. > > > > The main question that I would like answered if OAI-PMH is > something > > that we should include into LibX (libx.org), the client-side > > infrastructure we are building to integrate the library > into a user's > > webflow (credit to Lorcan Dempsey for describing LibX this > way.) LibX > > already supports COinS. > > > >> From a brief web search and skimming of the documents on > OAI that are > > out there, I understand that OAI is a distributed architecture for > > archiving electronic documents and other resources, and PMH is some > > kind of protocol on top of it that allows metadata about those > > resources to be exchanged among various service and data > > providers/repositories. > > > > So, let me cut right to the chase, and I hope this list is not an > > inappropriate place to ask this question: > > > > Is OAI/OAI-PMH something that's here today, and if so, in what way > > would you like to see support for it integrated into your > browser (or, > > if you don't like client-side solutions, into your OpenURL > resolution > > server)? > > > > One feature I would like to offer users is full > bibliographic data for > > any article. If a user sees a reference to a research paper, they > > should be able to select it, and with one or two clicks a) get the > > paper and b) an Endnote or bibtex record for the paper. > > > > Libx already provides a) through Scholar+OpenURL - could OAI-PMH > > provide b), today? > > > > Thanks! > > > > - Godmar > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From yee at berkeley.edu Mon Nov 21 12:59:42 2005 From: yee at berkeley.edu (Raymond Yee) Date: Mon Nov 21 12:59:55 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH and Refworks In-Reply-To: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> Message-ID: <43820B0E.3070408@berkeley.edu> What would it take to demonstrate moving COinS-PMH to RefWorks? It is possible to push things into Refworks (and you can contact Refworks for the low-down on how to do so). You can also figure it out without too much difficulty -- I have an example on my wiki: If you have Refworks, go to http://www.refworks.com/express/ExpressImport.asp?vendor=ProQuest&url=http%3A%2F%2Fraymondyee.net%2Fwiki%2FRisFormat_2fSampleFile1%3Faction%3Draw2%26mimetype%3Dtext%2Fplain to import the data in http://raymondyee.net/wiki/RisFormat_2fSampleFile1?action=raw2&mimetype=text/plain In other words, what's the glue between COinS-PMH and this import mechanism that we need? -Raymond Binkley, Peter wrote: > I'd say that if we *can't* get the metadata into the metadata-management > tools our users are using, COinS-PMH won't take off. That may require > making LibX capable of handling more complex metadata formats like MODS. > Or maybe tools like RefWorks can already handle it. > > Peter > > >> -----Original Message----- >> From: gcs-pcs-list-bounces@cipolo.med.yale.edu >> [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf >> Of Ross Singer >> Sent: Sunday, November 20, 2005 06:44 PM >> To: Godmar Back >> Cc: gcs-pcs-list@cipolo.med.yale.edu >> Subject: Re: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH >> >> Godmar, >> >> This is a tricky question. OAI-PMH is certainly "there yet" >> in regards to a traditional "server A asks server B for >> records and harvests them" >> model. >> >> Dan's proposal shifts the model from "server-to-machine" to >> "server-to-user". The cool thing about this is that it >> "gives" our data to the user to do with it whatever he or she >> may desire to do with it. >> >> The downside is, well, that there's currently not really >> anything out there /to do/ with it right now. >> >> Your idea of making the data available to >> EndNote/RefWorks/BibTex is exactly the sort of use unAPI (nee >> COinS-PMH) /needs/. However, I'm not sure how easy it would >> be to get something like DC into something useful to these apps. >> >> There are, of course, other uses for unAPI data, as well, but >> I think you're clarifying a fairly big problem in "client >> development" for it. >> When the purpose for implementing unAPI is so users can "do >> whatever they want" with your data, it's pretty difficult to >> create a client without a fairly specific purpose for what to >> do with that data. >> >> So, the real key here is finding/making services that can do >> things with this data. >> >> -Ross. >> >> On Nov 20, 2005, at 2:01 PM, Godmar Back wrote: >> >> >>> Hi, >>> >>> I asked Dan a few questions about his coins-pmh and the >>> >> amazon mixer >> >>> greasemonkey scripts, which I then tested, and he suggested I take >>> some of our discussion on list. >>> >>> The main question that I would like answered if OAI-PMH is >>> >> something >> >>> that we should include into LibX (libx.org), the client-side >>> infrastructure we are building to integrate the library >>> >> into a user's >> >>> webflow (credit to Lorcan Dempsey for describing LibX this >>> >> way.) LibX >> >>> already supports COinS. >>> >>> >>>> From a brief web search and skimming of the documents on >>>> >> OAI that are >> >>> out there, I understand that OAI is a distributed architecture for >>> archiving electronic documents and other resources, and PMH is some >>> kind of protocol on top of it that allows metadata about those >>> resources to be exchanged among various service and data >>> providers/repositories. >>> >>> So, let me cut right to the chase, and I hope this list is not an >>> inappropriate place to ask this question: >>> >>> Is OAI/OAI-PMH something that's here today, and if so, in what way >>> would you like to see support for it integrated into your >>> >> browser (or, >> >>> if you don't like client-side solutions, into your OpenURL >>> >> resolution >> >>> server)? >>> >>> One feature I would like to offer users is full >>> >> bibliographic data for >> >>> any article. If a user sees a reference to a research paper, they >>> should be able to select it, and with one or two clicks a) get the >>> paper and b) an Endnote or bibtex record for the paper. >>> >>> Libx already provides a) through Scholar+OpenURL - could OAI-PMH >>> provide b), today? >>> >>> Thanks! >>> >>> - Godmar >>> _______________________________________________ >>> gcs-pcs-list mailing list >>> gcs-pcs-list@cipolo.med.yale.edu >>> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >>> >>> >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> >> > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- -- Raymond Yee 2195 Hearst (250-22) Technology Architect UC Berkeley Interactive University Project Berkeley, CA 94720-3810 yee@uclink.berkeley.edu 510-642-0476 (work) http://iu.berkeley.edu/rdhyee 413-541-5683 (fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20051121/44949930/smime.bin From godmar at gmail.com Mon Nov 21 13:00:38 2005 From: godmar at gmail.com (Godmar Back) Date: Mon Nov 21 13:00:44 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH In-Reply-To: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> Message-ID: <719dced30511211000p6abfe89dp15a1b9f034d2609e@mail.gmail.com> Peter, I think that, resources permitting, we could add to LibX whatever is needed. My question is whether the payoff would be worth the investment. Are there services/servers out there, today, from which to draw the metadata that is then processed and presented to the user? Could you give specific pointers to such services? Are they public/subscription-based, production or experimental, and just what meta-data do they hold? Are they typically library-hosted or hosted at a service provider's site? Is there, for instance, a server out there which, when presented with an arbitrary v0.1 OpenURL, will return complete bibliographical information about the item to which the OpenURL refers? [Note that it is not unreasonable to expect such a service in the day and age of Google.] If not, are there are least services that would handle significant chunks of the problem? (I understand, for instance, that Dan's server would give me at least some info when genre=book&id=oai:isbn:... - but I suspect his server may not be a production server(?)) - Godmar On 11/21/05, Binkley, Peter wrote: > I'd say that if we *can't* get the metadata into the metadata-management > tools our users are using, COinS-PMH won't take off. That may require > making LibX capable of handling more complex metadata formats like MODS. > Or maybe tools like RefWorks can already handle it. > > Peter > > > -----Original Message----- > > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > > Of Ross Singer > > Sent: Sunday, November 20, 2005 06:44 PM > > To: Godmar Back > > Cc: gcs-pcs-list@cipolo.med.yale.edu > > Subject: Re: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH > > > > Godmar, > > > > This is a tricky question. OAI-PMH is certainly "there yet" > > in regards to a traditional "server A asks server B for > > records and harvests them" > > model. > > > > Dan's proposal shifts the model from "server-to-machine" to > > "server-to-user". The cool thing about this is that it > > "gives" our data to the user to do with it whatever he or she > > may desire to do with it. > > > > The downside is, well, that there's currently not really > > anything out there /to do/ with it right now. > > > > Your idea of making the data available to > > EndNote/RefWorks/BibTex is exactly the sort of use unAPI (nee > > COinS-PMH) /needs/. However, I'm not sure how easy it would > > be to get something like DC into something useful to these apps. > > > > There are, of course, other uses for unAPI data, as well, but > > I think you're clarifying a fairly big problem in "client > > development" for it. > > When the purpose for implementing unAPI is so users can "do > > whatever they want" with your data, it's pretty difficult to > > create a client without a fairly specific purpose for what to > > do with that data. > > > > So, the real key here is finding/making services that can do > > things with this data. > > > > -Ross. > > > > On Nov 20, 2005, at 2:01 PM, Godmar Back wrote: > > > > > Hi, > > > > > > I asked Dan a few questions about his coins-pmh and the > > amazon mixer > > > greasemonkey scripts, which I then tested, and he suggested I take > > > some of our discussion on list. > > > > > > The main question that I would like answered if OAI-PMH is > > something > > > that we should include into LibX (libx.org), the client-side > > > infrastructure we are building to integrate the library > > into a user's > > > webflow (credit to Lorcan Dempsey for describing LibX this > > way.) LibX > > > already supports COinS. > > > > > >> From a brief web search and skimming of the documents on > > OAI that are > > > out there, I understand that OAI is a distributed architecture for > > > archiving electronic documents and other resources, and PMH is some > > > kind of protocol on top of it that allows metadata about those > > > resources to be exchanged among various service and data > > > providers/repositories. > > > > > > So, let me cut right to the chase, and I hope this list is not an > > > inappropriate place to ask this question: > > > > > > Is OAI/OAI-PMH something that's here today, and if so, in what way > > > would you like to see support for it integrated into your > > browser (or, > > > if you don't like client-side solutions, into your OpenURL > > resolution > > > server)? > > > > > > One feature I would like to offer users is full > > bibliographic data for > > > any article. If a user sees a reference to a research paper, they > > > should be able to select it, and with one or two clicks a) get the > > > paper and b) an Endnote or bibtex record for the paper. > > > > > > Libx already provides a) through Scholar+OpenURL - could OAI-PMH > > > provide b), today? > > > > > > Thanks! > > > > > > - Godmar > > > _______________________________________________ > > > gcs-pcs-list mailing list > > > gcs-pcs-list@cipolo.med.yale.edu > > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From lists at hubmed.org Mon Nov 21 14:28:46 2005 From: lists at hubmed.org (Alf Eaton) Date: Mon Nov 21 14:28:53 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH and Refworks In-Reply-To: <43820B0E.3070408@berkeley.edu> References: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> <43820B0E.3070408@berkeley.edu> Message-ID: On 21 Nov 2005, at 12:59, Raymond Yee wrote: > What would it take to demonstrate moving COinS-PMH to RefWorks? It > is possible to push things into Refworks (and you can contact > Refworks for the low-down on how to do so). You can also figure > it out without too much difficulty -- I have an example on my wiki: > > If you have Refworks, go to > > http://www.refworks.com/express/ExpressImport.asp? > vendor=ProQuest&url=http%3A%2F%2Fraymondyee.net%2Fwiki% > 2FRisFormat_2fSampleFile1%3Faction%3Draw2%26mimetype%3Dtext%2Fplain > > to import the data in > > http://raymondyee.net/wiki/RisFormat_2fSampleFile1? > action=raw2&mimetype=text/plain > > In other words, what's the glue between COinS-PMH and this import > mechanism that we need? > > -Raymond That would depend what kind of data you're trying to import: if you're just trying to import the data that's present in the ContextObject then it's easy - you can do it with Javascript. If you have to call somewhere else to get the full metadata (eg HubMed can export RIS-formatted data for a PMID) then it's a bit more tricky, as you have to build in a lookup service for each type of data. On the other hand, you could just use SFX with an OpenURL link, eg http://demo.exlibrisgroup.com:9003/demo?genre=article&id=pmid:15616563 which gives the option (in 'Advanced') to download the record via a direct export tool in a number of formats. alf. From godmar at gmail.com Mon Nov 21 15:14:12 2005 From: godmar at gmail.com (Godmar Back) Date: Mon Nov 21 15:14:16 2005 Subject: [gcs-pcs-list] COinS-PMH, LibX, and OAI-PMH and Refworks In-Reply-To: References: <908893006339C0409519E4065DF3B24901570E4C@mailserver.ualibrary.ualberta.ca> <43820B0E.3070408@berkeley.edu> Message-ID: <719dced30511211214j57974e68o54fba9c3235600a@mail.gmail.com> On 11/21/05, Alf Eaton wrote: > > That would depend what kind of data you're trying to import: if > you're just trying to import the data that's present in the > ContextObject then it's easy - you can do it with Javascript. If you > have to call somewhere else to get the full metadata (eg HubMed can > export RIS-formatted data for a PMID) then it's a bit more tricky, as > you have to build in a lookup service for each type of data. On the > other hand, you could just use SFX with an OpenURL link, eg > http://demo.exlibrisgroup.com:9003/demo?genre=article&id=pmid:15616563 > which gives the option (in 'Advanced') to download the record via a > direct export tool in a number of formats. > I too had noticed that SFX provided that option and thought of harvesting it via AJAX like I do with Google Scholar, but I don't think this will help much. I think it will only work for some cases (e.g. when the PMID given and SFX knows whom to contact.) Try, for instance, http://demo.exlibrisgroup.com:9003/demo?genre=article&id=doi:10.1074/jbc.M004545200 and click on "citation information". It's incomplete (compare with http://dx.doi.org/10.1074/jbc.M004545200 ) - I think they just echo back what crossref returned when they looked up that DOI. Similarly, in other cases, they just echo back the context object, as you allude to at the beginning of your reply. - Godmar From eric at openly.com Mon Nov 21 15:54:51 2005 From: eric at openly.com (Eric Hellman) Date: Mon Nov 21 15:54:58 2005 Subject: [gcs-pcs-list] Fwd: Re: Comment on COinS spec Message-ID: The question for the list is Should COinS recommend an XMDP profile or something similar? http://gmpg.org/xmdp/description >Date: Mon, 21 Nov 2005 18:40:29 +0000 >From: Pete Johnston >X-Accept-Language: en-us, en >To: Eric Hellman >Subject: Re: Comment on COinS spec > >Hi Eric, > >Sorry about the belated response... various other things got in the >way last week. > >>If it's ok with you, I'll pass this on to the the GCS-PCS list. > >Yes, fine. > >>Ok, suppose we recommend a value for the profile attribute. What is >>a user-agent supposed to do with it? Can you think of a likely >>scenario where a user would benefit? > >I was arguing that a profile (or some other similar mechanism) was >necessary to remove any ambiguity about the use of span class="Z3988", >i.e. to provide a mechanism by which an application could dependably >assume that the value of the title attribute is a Context Object. I >recognise that I'm being prety pedantic and it seems unlikely that >anyone will use span class="Z3988" for some other purpose - but that >possibility does exist. ;-) And so currently there is the >possibility that a user-agent will act on the basis that a value is >a Context Object, when in fact it isn't. So the benefit is getting >rid of that ambiguity. > >Looking at it another way, the COinS spec effectively defines a >"microformat" [1], albeit a minimal one. I haven't tracked the >microformats stuff in any detail, but they have a format called XMDP >for describing a microformat. I don't think they _require_ the use >of a profile reference in the instance document to indicate that a >microformat is being used, but I think it is recommended e.g. [2] >says: > >=== ># Why should I reference XMDP profiles in my documents? > > * In order to precisely define the classes and new rel values >you are using as being defined by one or more specific microformats. >With an XMDP validator, you will also be able to make sure that you >are only using values that have been defined, and this may help >catch problems with your content sooner rather than later. > ># Must content marked up with microformats reference the proper XMDP >profile(s)? > > * At this point we are saying that content marked up with >microformats SHOULD reference the proper XMDP profile(s). This >requirement may be changed to a MUST for microformat validity. >=== > >I guess there may be scope for using the profile URI to provide access >to other resources that may be useful to COinS applications, rather in >the way that GRDDL works - but I must admit I'm not sure what those >other resources would be just at the moment! > >>Note that , in general, it is a rather high implementation barrier >>to require anything in HEAD or certainly in an HEAD attribute. Blog >>software, Wiki software, etc will in general not allow users to >>access HEAD, and most certainly will not support adding an >>attribute in the HEAD element. So a required attribute is a >>non-starter. So given that background, how might an optional >>profile attribute be of more than theoretical use? > >OK... I guess I don't think having the profile as optional really >addresses the problem. But if those issues of tools are an >over-riding concern, so be it! ;-) > >Cheers >Pete > >[1] http://microformats.org/ >[2] http://microformats.org/wiki/xmdp-faq > >-- >Pete Johnston >Research Officer (Interoperability) >UKOLN, University of Bath, Bath BA2 7AY, UK >tel: +44 (0)1225 383619 fax: +44 (0)1225 386838 >mailto:p.johnston@ukoln.ac.uk >http://www.ukoln.ac.uk/ukoln/staff/p.johnston/ -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From ehs at pobox.com Mon Nov 21 16:33:51 2005 From: ehs at pobox.com (Edward Summers) Date: Mon Nov 21 16:33:54 2005 Subject: [gcs-pcs-list] Fwd: Re: Comment on COinS spec In-Reply-To: References: Message-ID: <33DB0F77-612A-45B1-9F07-E2DE016502AE@pobox.com> > The question for the list is > > Should COinS recommend an XMDP profile or something similar? > http://gmpg.org/xmdp/description I think this is a great idea, and one that I've pursued a bit on the various microformat forums. One hurdle is that microformats are essentially about marking up human readable content, and COinS are essentially about hiding identifiers. There is some effort afoot in the microformats community to develop a citation microformat. I thought that the openurl KEVs could be used for this...much like hCal uses iCal. This led me to try to add an HTMLified version of openurl to the citation brain storming wiki [1]. I think that draft citation microformat using openurl's KEVs could be successful...and could put openurl semantics into a new arena. The process is completely open, and I know dchud has been thinking along similar lines about an identifier microformat which is similar but different. I'd be interested in helping out with a draft if anyone else is. //Ed [1] http://microformats.org/wiki/cite-formats#Example > > >> Date: Mon, 21 Nov 2005 18:40:29 +0000 >> From: Pete Johnston >> X-Accept-Language: en-us, en >> To: Eric Hellman >> Subject: Re: Comment on COinS spec >> >> Hi Eric, >> >> Sorry about the belated response... various other things got in >> the way last week. >> >>> If it's ok with you, I'll pass this on to the the GCS-PCS list. >> >> Yes, fine. >> >>> Ok, suppose we recommend a value for the profile attribute. What >>> is a user-agent supposed to do with it? Can you think of a likely >>> scenario where a user would benefit? >> >> I was arguing that a profile (or some other similar mechanism) was >> necessary to remove any ambiguity about the use of span >> class="Z3988", >> i.e. to provide a mechanism by which an application could dependably >> assume that the value of the title attribute is a Context Object. I >> recognise that I'm being prety pedantic and it seems unlikely that >> anyone will use span class="Z3988" for some other purpose - but >> that possibility does exist. ;-) And so currently there is the >> possibility that a user-agent will act on the basis that a value >> is a Context Object, when in fact it isn't. So the benefit is >> getting rid of that ambiguity. >> >> Looking at it another way, the COinS spec effectively defines a >> "microformat" [1], albeit a minimal one. I haven't tracked the >> microformats stuff in any detail, but they have a format called >> XMDP for describing a microformat. I don't think they _require_ >> the use of a profile reference in the instance document to >> indicate that a microformat is being used, but I think it is >> recommended e.g. [2] says: >> >> === >> # Why should I reference XMDP profiles in my documents? >> >> * In order to precisely define the classes and new rel values >> you are using as being defined by one or more specific >> microformats. With an XMDP validator, you will also be able to >> make sure that you are only using values that have been defined, >> and this may help catch problems with your content sooner rather >> than later. >> >> # Must content marked up with microformats reference the proper >> XMDP profile(s)? >> >> * At this point we are saying that content marked up with >> microformats SHOULD reference the proper XMDP profile(s). This >> requirement may be changed to a MUST for microformat validity. >> === >> >> I guess there may be scope for using the profile URI to provide >> access >> to other resources that may be useful to COinS applications, >> rather in >> the way that GRDDL works - but I must admit I'm not sure what those >> other resources would be just at the moment! >> >>> Note that , in general, it is a rather high implementation >>> barrier to require anything in HEAD or certainly in an HEAD >>> attribute. Blog software, Wiki software, etc will in general not >>> allow users to access HEAD, and most certainly will not support >>> adding an attribute in the HEAD element. So a required attribute >>> is a non-starter. So given that background, how might an optional >>> profile attribute be of more than theoretical use? >> >> OK... I guess I don't think having the profile as optional really >> addresses the problem. But if those issues of tools are an over- >> riding concern, so be it! ;-) >> >> Cheers >> Pete >> >> [1] http://microformats.org/ >> [2] http://microformats.org/wiki/xmdp-faq >> >> -- >> Pete Johnston >> Research Officer (Interoperability) >> UKOLN, University of Bath, Bath BA2 7AY, UK >> tel: +44 (0)1225 383619 fax: +44 (0)1225 386838 >> mailto:p.johnston@ukoln.ac.uk >> http://www.ukoln.ac.uk/ukoln/staff/p.johnston/ > > > -- > > Eric Hellman, President Openly > Informatics, Inc. > eric@openly.com 2 Broad St., 2nd > Floor > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ > 07003 > http://www.openly.com/1cate/ 1 Click Access To Everything > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From eric at openly.com Wed Nov 23 14:39:18 2005 From: eric at openly.com (Eric Hellman) Date: Wed Nov 23 14:39:28 2005 Subject: [gcs-pcs-list] CrossRef and COinS In-Reply-To: <33DB0F77-612A-45B1-9F07-E2DE016502AE@pobox.com> References: <33DB0F77-612A-45B1-9F07-E2DE016502AE@pobox.com> Message-ID: The people at CrossRef have agreed, on an experimental basis, to allow us to turn on DOI lookup and reverse lookup in the COinS generator. What this means is that you can send the generator a doi and get back a fully filled-out COinS for example: http://generator.ocoins.info/?id=doi:10.1037/0033-2909.129.6.842 (or the longer 1.0 version...) alternatively, you can enter metadata and get a COinS with an embedded doi: http://generator.ocoins.info/?issn=0033-2909&volume=129&date=2003&issue=6&spage=842 If you agree with me that this is a really useful facility, send your compliments and thank yous to Amy Brand and Ed Pentz at CrossRef: epentz@crossref.org, abrand@crossref.org Eric -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything