From daniel.chudnov at yale.edu Tue Sep 6 16:57:31 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Sep 6 16:57:37 2005 Subject: [gcs-pcs-list] "COinS browser extensions" page updated Message-ID: <20050906205730.GI25554@curtis.med.yale.edu> All - the "COinS Browser Extensions for Your Library" page has been updated to use the COinS spec and generate both bookmarklets and greasemonkey scripts. And renamed. It now also includes a bookmarklet/script for the alpha OCLC resolver registry recently announced on the openurl list (cool because it includes 900 resolvers and maps by IP range). http://curtis.med.yale.edu/dchud/resolvable/ The greasemonkey script is essentially Alf's script with different values swapped in as appropriate. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From andrew-forman at uiowa.edu Wed Sep 7 10:30:00 2005 From: andrew-forman at uiowa.edu (Forman, Andrew B) Date: Wed Sep 7 10:30:09 2005 Subject: [gcs-pcs-list] COinS browser extension - IE woes Message-ID: <183294552478444386C2B6B95D597E05015141E3@IOWAEVS02.iowa.uiowa.edu> Having been unable to get any of the bookmarklets working in IE6 (*snif*), I started hacking at the javascript to make it both IE and FF friendly. Below is what I've come up with (customized for uiowa of course =): InfoLink COinS a Andrew Forman University of Iowa Libraries ISST Development 319 335 9152 -------------- 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/20050907/997f3c8a/smime.bin From andrew-forman at uiowa.edu Wed Sep 7 11:31:01 2005 From: andrew-forman at uiowa.edu (Forman, Andrew B) Date: Wed Sep 7 11:31:08 2005 Subject: [gcs-pcs-list] COinS browser extension - IE woes Message-ID: <183294552478444386C2B6B95D597E050151428E@IOWAEVS02.iowa.uiowa.edu> D'oh, even with this rewrite, I cannot get IE to dynamically insert the image when the link is invoked from my favorites list (although it works fine on the same page =\). There is an IE bug on this -- that dynamically inserted images don't load (#269802). So, for now, I've a text version: InfoLink COinS Txt A Andrew Forman University of Iowa Libraries ISST Development 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 Forman, Andrew B Sent: Wednesday, September 07, 2005 9:30 AM To: gcs-pcs-list@cipolo.med.yale.edu Subject: [gcs-pcs-list] COinS browser extension - IE woes Having been unable to get any of the bookmarklets working in IE6 (*snif*), I started hacking at the javascript to make it both IE and FF friendly. Below is what I've come up with (customized for uiowa of course =): InfoLink COinS a Andrew Forman University of Iowa Libraries ISST Development 319 335 9152 -------------- 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/20050907/1200ea3d/smime.bin From eric at openly.com Thu Sep 22 12:25:05 2005 From: eric at openly.com (Eric Hellman) Date: Thu Sep 22 12:39:04 2005 Subject: [gcs-pcs-list] COinS at the NISO Meeting, COinS Generator In-Reply-To: <183294552478444386C2B6B95D597E05015141E3@IOWAEVS02.iowa.uiowa.edu> References: <183294552478444386C2B6B95D597E05015141E3@IOWAEVS02.iowa.uiowa.edu> Message-ID: At the NISO workshop on OpenURL and Metasearch http://www.niso.org/news/events_workshops/OpenURL-05-wkshp.html there was a lot of high-level interest in COinS. In addition to Ross Singer's talk on COinS and WAG the dog), there was favorable notice of COinS in talks by Raymond Yee (Interactive University of UC Berkeley), Oliver Pesch (Chief Strategist, E-Resources, EBSCO Information Services), Mike Hoover (Senior Linking and Integration Engineer, ProQuest Information and Learning). The meeting also served as a good deadline for us to get our COinS generator running. The COinS Generator is ready for comment at http://generator.ocoins.info/ The COinS generator is running on a fully functional instance of Openly's 1Cate Link Resolver, so you can send it OpenURL 0.1 or 1.0 links and get back COinS info. We have Amazon Web Services and Pubmed Web Service turned on, so you can send it stuff like http://generator.ocoins.info/?isbn=0312311109 or http://generator.ocoins.info/?id=pmid:11025561&sid=pubmed and it will do appropriate lookups. doi lookup is planned. Please take a look and send us suggestions/corrections and comment. -- 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 lists at hubmed.org Thu Sep 22 18:58:21 2005 From: lists at hubmed.org (Alf Eaton) Date: Thu Sep 22 18:58:31 2005 Subject: [gcs-pcs-list] COinS at the NISO Meeting, COinS Generator In-Reply-To: References: <183294552478444386C2B6B95D597E05015141E3@IOWAEVS02.iowa.uiowa.edu> Message-ID: <09C5DAA0-8E74-49B0-B723-8822B274C7EA@hubmed.org> On 22 Sep 2005, at 18:25, Eric Hellman wrote: > The COinS Generator is ready for comment at http:// > generator.ocoins.info/ The COinS generator is running on a fully > functional instance of Openly's 1Cate Link Resolver, so you can > send it OpenURL 0.1 or 1.0 links and get back COinS info. We have > Amazon Web Services and Pubmed Web Service turned on, so you can > send it stuff like > http://generator.ocoins.info/?id=pmid:11025561&sid=pubmed Just a small point: it's probably best not to have those line breaks in there, even if they improve readability. Movable Type (at least) will convert those into
and break whatever you're trying to insert. alf. From daniel.chudnov at yale.edu Tue Sep 27 09:49:52 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Sep 27 09:47:00 2005 Subject: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH Message-ID: <98C7F70C-3A9B-4B3F-BEDA-25E3A73A0AA6@yale.edu> In hopes of pushing COinS a step further, I've written up a draft spec of "COinS-PMH", which combines COinS-with-identifiers, an html autodiscovery link, and a subset/profile of the OAI-PMH (the verbs ListMetadataFormats and GetRecord): http://curtis.med.yale.edu/dchud/log/project/rogue/rogue-no.1- coins-pmh The goal is to provide a simple, consistent, machine processable way to move directly from an item of interest on a web page (identified using COinS) to alternate formal representations of that item for use by other systems (javascript plugins, Scholar's Box-esque tools, third-party sites like "bookmarking" services, courseware, etc.). In other words it's more for inter-site / inter-service uses we cannot predict than for intra-site metadata or object access (which already exists, but is typically bound up in inconsistent HTML interfaces). For those of you at the BoF at the 2004 DLF meeting in Baltimore (from whence this list came'st): you may recognize this is as a further attempt to enable "see an object you like, do what you can with it" kinds of services. If folks are interested and nobody here minds, please send feedback via this list. If folks are really interested and wish to help make the spec work, please consider the ROGUE 05 specification process as the intended mechanism for moving quickly to a completed spec. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Sep 27 12:02:53 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Sep 27 12:00:43 2005 Subject: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH In-Reply-To: References: <98C7F70C-3A9B-4B3F-BEDA-25E3A73A0AA6@yale.edu> Message-ID: <4D1558AD-BED8-4743-B970-6CD2B0489FF0@yale.edu> (with Eric's permission to respond on-list...) On Sep 27, 2005, at 11:17 AM, Eric Hellman wrote: > This is nicely focused, and I can see this as a sensible migration > path. > > Here's a situation where it might need refinement. I have an HTML > CV with 200 publications on it, and I've added COinS to every item. > I know that 2 of the publications are archived and available in my > corporate OAI server. I would like to add hints to the document > about where to find those documents, so I add the appropriate link > tag to the head of the document. But a COinS-PMH processor is now > faced with the task of checking 250 ids to find the 3 that are in > the indicated archive, and it almost never finishes in time to > provide the services it's supposed to. > > I'm no expert on OAI, but can't we use an archive pointer inside > the ContextObject (metadata-by-reference?)? That's a good point about the many-requests-few-hits scenario. Perhaps COinS-PMH should state that it's intended for "scenarios in which the publisher has access to a majority of items described in COiNS". But, even that doesn't solve the many-requests issue. Perhaps that's just another functional border. A processor doesn't necessarily act upon all COinS in a page at once... indeed (obviously) I'd primarily imagined COinS-PMH as a means to get to "more information about one item", not a whole raft- at-once. [...which is what OAI-PMH is for, right? Theoretically, you could embed a mini-OAI server inside individual pages, or make a single page be equivalent to an OAI set, and then call ListRecords on either...] As for the archive pointer question, I'm not expert in OAI or OpenURL, so I'm not sure. I'd suspect it comes down to which piece does the processing where, and what burden you are asking of publishers/tool developers. One great thing about COinS is that you don't have to grok all of OpenURL either to publish or process COinS. If embedding the service request into the COinS itself increases the burden of understanding OpenURL on either the publisher or the tool developer, then it's less likely to succeed (even if it's "better"). Could you provide an example of what this might look like? As an aside, that's one lengthy CV. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From Peter.Binkley at ualberta.ca Tue Sep 27 14:22:42 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Tue Sep 27 14:23:13 2005 Subject: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH Message-ID: <908893006339C0409519E4065DF3B24901570D11@mailserver.ualibrary.ualberta.ca> But would it be appropriate for every COinS in Eric's CV to be a COinS-PMH COinS? The main problem Dan's addressing is to provide rich metadata about the thing you're looking at (in this case, the CV), not necessarily about every link out from that thing. Should there maybe be a class for COinS-PMH COinS spans (COinS allows multiple classes): Eric wants a way to supplement the knowledge of a remote link-resolver with local information. I think this is a more general problem, and shouldn't be packed into the COinS-PMH idea. 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: Tuesday, September 27, 2005 10:03 AM > To: Eric Hellman > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH > > (with Eric's permission to respond on-list...) > > On Sep 27, 2005, at 11:17 AM, Eric Hellman wrote: > > > This is nicely focused, and I can see this as a sensible migration > > path. > > > > Here's a situation where it might need refinement. I have > an HTML CV > > with 200 publications on it, and I've added COinS to every item. > > I know that 2 of the publications are archived and available in my > > corporate OAI server. I would like to add hints to the > document about > > where to find those documents, so I add the appropriate link tag to > > the head of the document. But a COinS-PMH processor is now > faced with > > the task of checking 250 ids to find the 3 that are in the > indicated > > archive, and it almost never finishes in time to provide > the services > > it's supposed to. > > > > I'm no expert on OAI, but can't we use an archive pointer > inside the > > ContextObject (metadata-by-reference?)? > > That's a good point about the many-requests-few-hits scenario. > Perhaps COinS-PMH should state that it's intended for > "scenarios in which the publisher has access to a majority of > items described in > COiNS". But, even that doesn't solve the many-requests issue. > Perhaps that's just another functional border. > > A processor doesn't necessarily act upon all COinS in a page > at once... indeed (obviously) I'd primarily imagined > COinS-PMH as a means to get to "more information about one > item", not a whole raft- at-once. > > [...which is what OAI-PMH is for, right? Theoretically, you > could embed a mini-OAI server inside individual pages, or > make a single page be equivalent to an OAI set, and then call > ListRecords on either...] > > As for the archive pointer question, I'm not expert in OAI or > OpenURL, so I'm not sure. I'd suspect it comes down to which > piece does the processing where, and what burden you are > asking of publishers/tool developers. One great thing about > COinS is that you don't have to grok all of OpenURL either to > publish or process COinS. If embedding the service request > into the COinS itself increases the burden of understanding > OpenURL on either the publisher or the tool developer, then > it's less likely to succeed (even if it's "better"). Could > you provide an example of what this might look like? > > As an aside, that's one lengthy CV. :) > > -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 lists at hubmed.org Tue Sep 27 15:15:29 2005 From: lists at hubmed.org (Alf Eaton) Date: Tue Sep 27 15:16:15 2005 Subject: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH In-Reply-To: <4D1558AD-BED8-4743-B970-6CD2B0489FF0@yale.edu> References: <98C7F70C-3A9B-4B3F-BEDA-25E3A73A0AA6@yale.edu> <4D1558AD-BED8-4743-B970-6CD2B0489FF0@yale.edu> Message-ID: <146CA5C7-AA60-429F-A1B3-F97C175EB0F1@hubmed.org> On 27 Sep 2005, at 18:02, Daniel Chudnov wrote: > On Sep 27, 2005, at 11:17 AM, Eric Hellman wrote: > > >> This is nicely focused, and I can see this as a sensible migration >> path. >> >> Here's a situation where it might need refinement. I have an HTML >> CV with 200 publications on it, and I've added COinS to every >> item. I know that 2 of the publications are archived and available >> in my corporate OAI server. I would like to add hints to the >> document about where to find those documents, so I add the >> appropriate link tag to the head of the document. But a COinS-PMH >> processor is now faced with the task of checking 250 ids to find >> the 3 that are in the indicated archive, and it almost never >> finishes in time to provide the services it's supposed to. >> >> I'm no expert on OAI, but can't we use an archive pointer inside >> the ContextObject (metadata-by-reference?)? >> > > That's a good point about the many-requests-few-hits scenario. > Perhaps COinS-PMH should state that it's intended for "scenarios in > which the publisher has access to a majority of items described in > COiNS". But, even that doesn't solve the many-requests issue. > Perhaps that's just another functional border. > > A processor doesn't necessarily act upon all COinS in a page at > once... indeed (obviously) I'd primarily imagined COinS-PMH as a > means to get to "more information about one item", not a whole raft- > at-once. If I understand the suggested spec properly, then this is my question: What is the advantage of having in the header of the page (where you'd expect to find meta links for the current document itself, which I think is what Peter is saying), rather than or even within each COinS span for the which the appropriate COinS-PMH server is known? alf. From daniel.chudnov at yale.edu Tue Sep 27 18:27:23 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Sep 27 18:24:58 2005 Subject: [gcs-pcs-list] new spec: COinS+metadata = COinS-PMH In-Reply-To: <146CA5C7-AA60-429F-A1B3-F97C175EB0F1@hubmed.org> References: <98C7F70C-3A9B-4B3F-BEDA-25E3A73A0AA6@yale.edu> <4D1558AD-BED8-4743-B970-6CD2B0489FF0@yale.edu> <146CA5C7-AA60-429F-A1B3-F97C175EB0F1@hubmed.org> Message-ID: These are good questions. I don't know the right answers. Speaking directly to this one, though... On Sep 27, 2005, at 3:15 PM, Alf Eaton wrote: > On 27 Sep 2005, at 18:02, Daniel Chudnov wrote: >> >> A processor doesn't necessarily act upon all COinS in a page at >> once... indeed (obviously) I'd primarily imagined COinS-PMH as a >> means to get to "more information about one item", not a whole >> raft-at-once. > > What is the advantage of having > > in the header of the page (where you'd expect to find meta links > for the current document itself, which I think is what Peter is > saying), rather than > > or even > > within each COinS span for the which the appropriate COinS-PMH > server is known? One advantage is that it doesn't change what a COinS is. If you put more stuff inside COinS in a further-specified way, then COinS itself grows or becomes something different. This way COinS stays COinS, as- is, and if a COinS has an identifier, and there's a COinS-PMH meta link, you can PMH that particular COinS. Maybe it's not a bad thing if COinS grows or becomes something different, but it'd be another category of New Work To Do. I'd prefer to keep each piece simple (for more dynamic post-coordination a la web2.0), but, sure, that's not always the best option. Another advantage is that for a fairly homogenous site - say, unalog.com or canarydatabase.org - every item I'll be posting a COinS for will have metadata I'd like to expose from a homogeneous PMH address. In that scenario, the extra s inside COinS become redundant. That doesn't address Eric's point about different servers for different COinS, which your alternate suggestion solves more cleanly. Yet, that brings us back to the extending-COinS problem. COinS itself says nothing about post-processing content left inside or nearby a COinS... some COinS agents might replace/remove everything inside a COinS each time they process it. (e.g. Eric's "Using COinS to Provide OpenURL links" says replace the span content, but the bookmarklets.) So, we'd just have to contend with that. Hmm, lots of ways this could go. I'm thrilled that nobody's shot it down as not interesting just yet. -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789