From daniel.chudnov at yale.edu Tue Feb 1 00:33:03 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 1 00:33:09 2005 Subject: [gcs-pcs-list] simple appropriate-resolver prototype/demonstrator Message-ID: <6cb57d809b522fa9e44f8a551592e8a7@yale.edu> I've marked up a simple prototype/demonstrator of "appropriate resolver" bookmarklets and at least one information resource that supports them. http://curtis.med.yale.edu/dchud/resolvable/ The basis for the bookmarklets' insertion of local resolver information is a simple a[@name] element with rel='alternate' and title='OpenURL' attributes. The list of resolvers comes from a wiki page filled in by volunteers responding to a solicitation on the code4lib mailing list. More service demonstrators are on the way. In the meantime it would be interesting to try to connect, using similar means, to some of the resources other folks here provide. :) -Dan From daniel.chudnov at yale.edu Tue Feb 1 08:07:29 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 1 08:08:10 2005 Subject: [gcs-pcs-list] Fwd: simple appropriate-resolver prototype/demonstrator Message-ID: Eric suggests avoiding the "name" attribute (wisely, probably :). -dc Begin forwarded message: > From: Eric Hellman > Date: February 1, 2005 1:39:07 AM EST > To: Daniel Chudnov > Subject: Re: simple appropriate-resolver prototype/demonstrator > > using the "name" attribute for link data is problematic because the > value is supposed to be unique in a document., and "should" be a name > token. I know it's not declared as IDREF, but the intent is there. was > there a reason not to put openurl uri data in the href attribute of an > empty anchor and flag it for plug-ins/bookmarklets using the "rel" or > "title" attribute? I like the idea of straight html as opposed to > embedded xml. Plugins will be relying on browsers to build the dom > tree and you probably don't want to really mess with that. > > As an aside, the openurl committee discussed briefly how to do this (I > may even have introduced it as a topic), but Herbert was REALLY > opposed to doing anything in this direction as part of the standard, > and no one really felt strongly otherwise. Probably a good thing. See > if Tony Hammond remembers. > > feel free to pass on to the gcs-pcs list From daniel.chudnov at yale.edu Tue Feb 1 08:06:39 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 1 08:09:26 2005 Subject: [gcs-pcs-list] Fwd: simple appropriate-resolver prototype/demonstrator Message-ID: <3369408c025d6ca8f647397e666b5de0@yale.edu> Eric suggests avoiding the "name" attribute (wisely, probably :). -dc Begin forwarded message: > From: Eric Hellman > Date: February 1, 2005 1:39:07 AM EST > To: Daniel Chudnov > Subject: Re: simple appropriate-resolver prototype/demonstrator > > using the "name" attribute for link data is problematic because the > value is supposed to be unique in a document., and "should" be a name > token. I know it's not declared as IDREF, but the intent is there. was > there a reason not to put openurl uri data in the href attribute of an > empty anchor and flag it for plug-ins/bookmarklets using the "rel" or > "title" attribute? I like the idea of straight html as opposed to > embedded xml. Plugins will be relying on browsers to build the dom > tree and you probably don't want to really mess with that. > > As an aside, the openurl committee discussed briefly how to do this (I > may even have introduced it as a topic), but Herbert was REALLY > opposed to doing anything in this direction as part of the standard, > and no one really felt strongly otherwise. Probably a good thing. See > if Tony Hammond remembers. > > feel free to pass on to the gcs-pcs list From ross.singer at library.gatech.edu Tue Feb 1 10:00:06 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Feb 1 10:02:19 2005 Subject: [gcs-pcs-list] simple appropriate-resolver prototype/demonstrator In-Reply-To: <6cb57d809b522fa9e44f8a551592e8a7@yale.edu> References: <6cb57d809b522fa9e44f8a551592e8a7@yale.edu> Message-ID: <41FF9976.7000501@library.gatech.edu> Dan, This is cool! I've updated the WAG the Dog localizer to include these links (in addition to the normal localization and the alternative approach: the tag). Unfortunately, the bookmarklet only works in Google Scholar and on journals and citations right now. Metadata about books is retrieved in an Iframe (which the bookmarklet doesn't address). An extension would take care of this, though. So you're "localizing the localizer" (which would be convenient, say, if a localized page was furl'ed or something). I think a better way to picture the localizer is, rather than an alternative, more of a way to shoe-horn non-compliant sites to do our bidding. -Ross. Daniel Chudnov wrote: > I've marked up a simple prototype/demonstrator of "appropriate > resolver" bookmarklets and at least one information resource that > supports them. > > http://curtis.med.yale.edu/dchud/resolvable/ > > The basis for the bookmarklets' insertion of local resolver > information is a simple a[@name] element with rel='alternate' and > title='OpenURL' attributes. The list of resolvers comes from a wiki > page filled in by volunteers responding to a solicitation on the > code4lib mailing list. > > More service demonstrators are on the way. In the meantime it would > be interesting to try to connect, using similar means, to some of the > resources other folks here provide. :) > > > -Dan > > _______________________________________________ > 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 Tue Feb 1 12:19:38 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 1 12:19:41 2005 Subject: [gcs-pcs-list] simple appropriate-resolver prototype/demonstrator In-Reply-To: <41FF9976.7000501@library.gatech.edu> References: <6cb57d809b522fa9e44f8a551592e8a7@yale.edu> <41FF9976.7000501@library.gatech.edu> Message-ID: <41FFBA2A.3010803@yale.edu> Ross Singer wrote: > I've updated the WAG the Dog localizer to include these links (in > addition to the normal localization and the alternative approach: the > tag). Does the localizer place link tags inside the html body? Is that "legal"? /me goes to try it out... > So you're "localizing the localizer" (which would be convenient, say, if > a localized page was furl'ed or something). Or citeulike'd, or connotea'd, etc. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Tue Feb 1 12:24:35 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Feb 1 12:26:51 2005 Subject: [gcs-pcs-list] simple appropriate-resolver prototype/demonstrator In-Reply-To: <41FFBA2A.3010803@yale.edu> References: <6cb57d809b522fa9e44f8a551592e8a7@yale.edu> <41FF9976.7000501@library.gatech.edu> <41FFBA2A.3010803@yale.edu> Message-ID: <41FFBB53.5020302@library.gatech.edu> Daniel Chudnov wrote: > Ross Singer wrote: > >> I've updated the WAG the Dog localizer to include these links (in >> addition to the normal localization and the alternative approach: >> the tag). > > > Does the localizer place link tags inside the html body? Is that > "legal"? /me goes to try it out... D'oh! It's not. I thought it was (read: I couldn't find otherwise), but now I see I am wrong: http://www.w3.org/TR/REC-html40/struct/links.html#edef-LINK "This element defines a link. Unlike A, it may only appear in the HEAD section of a document, although it may appear any number of times." What I may do, however, it populate the HEAD with all of these, and then use a in concert with it... Or not, I'm not really sold on this method over any other. > >> So you're "localizing the localizer" (which would be convenient, say, >> if a localized page was furl'ed or something). > > > Or citeulike'd, or connotea'd, etc. :) You're with me. -Ross. From daniel.chudnov at yale.edu Fri Feb 4 15:26:47 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 4 15:37:06 2005 Subject: [gcs-pcs-list] another openurl demo: citeulike Message-ID: Richard has kindly (considering the time in the UK at present) taken some time to implement the "bookmarklet-discoverable" form of OpenURL linking at his citeulike.org. To try it out, grab a bookmarklet from here: http://curtis.med.yale.edu/dchud/resolvable/ ...and use it on any page that references a published article here: http://www.citeulike.org/ ...seems to work very well, even on the main page. Very slick! A round for the house on this Friday afternoon (EST)... :) -Dan From ross.singer at library.gatech.edu Fri Feb 4 17:23:28 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Feb 4 17:25:44 2005 Subject: [gcs-pcs-list] another openurl demo: citeulike In-Reply-To: References: Message-ID: <4203F5E0.7060709@library.gatech.edu> Nice. I have also set up the WAG the Dog localizer to process these A tags in the "default" filter, as well. Performance is an issue on the first example from CiteULike (every citation checks to see if it's available locally in fulltext... ). I'll address this later. The full record works well, though: http://rsinger.library.gatech.edu/localizer/index.php?waggerURL=http%3A//www.citeulike.org/article/87186 Note: I think this might only work for a couple more days... I plan to change the way I pass URLs to the localizer to account for urls that are urlencoded in other urls (any suggestions anyone? I am currently planning to use base64 encoding.). This is nice, though, because it sort of proves that you can pass around (most) localized web pages. If the page requires cookies or a sophisticated header (Google) it'll break. It's great to see this much progress so fast. -Ross. Daniel Chudnov wrote: > Richard has kindly (considering the time in the UK at present) taken > some time to implement the "bookmarklet-discoverable" form of OpenURL > linking at his citeulike.org. To try it out, grab a bookmarklet from > here: > > http://curtis.med.yale.edu/dchud/resolvable/ > > ...and use it on any page that references a published article here: > > http://www.citeulike.org/ > > ...seems to work very well, even on the main page. Very slick! > > A round for the house on this Friday afternoon (EST)... :) > > -Dan > > _______________________________________________ > 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 Feb 4 17:46:36 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 4 17:46:40 2005 Subject: [gcs-pcs-list] another openurl demo: citeulike In-Reply-To: <4203F5E0.7060709@library.gatech.edu> References: <4203F5E0.7060709@library.gatech.edu> Message-ID: On Feb 4, 2005, at 5:23 PM, Ross Singer wrote: > > The full record works well, though: > http://rsinger.library.gatech.edu/localizer/index.php? > waggerURL=http%3A//www.citeulike.org/article/87186 Nice! The added proxy-link bit you've added looks really useful. Just for fun I also threw some demonstration posts into two different weblog engines: pyblosxom: http://curtis.med.yale.edu/dchud/log/project/groupware wordpress: http://futility.mine.nu/back/2005/02/04/126/ Ross, I'd like to add the wagger to the list of services on the discoverable-bookmarklet page... but not if it's going to break in a few days. Let me know if we can come up with an agreeable workaround. -Dan From ross.singer at library.gatech.edu Fri Feb 4 20:46:26 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Feb 4 20:46:28 2005 Subject: [gcs-pcs-list] another openurl demo: citeulike In-Reply-To: References: <4203F5E0.7060709@library.gatech.edu> Message-ID: <1211.68.219.247.84.1107567986.squirrel@68.219.247.84> Wow, that works, too. Things are working! Dan, feel free to link. The only thing that won't work is to send a "localized page" as a link. As I just did. I'm obviously throwing the localizer around willy-nilly, so I won't change the basic access to it. The service itself won't change, just the way you throw a remote URL at it will. -Ross. On Fri, February 4, 2005 5:46 pm, Daniel Chudnov said: > On Feb 4, 2005, at 5:23 PM, Ross Singer wrote: >> >> The full record works well, though: >> http://rsinger.library.gatech.edu/localizer/index.php? >> waggerURL=http%3A//www.citeulike.org/article/87186 > > Nice! The added proxy-link bit you've added looks really useful. > > Just for fun I also threw some demonstration posts into two > different > weblog engines: > > pyblosxom: > http://curtis.med.yale.edu/dchud/log/project/groupware > > wordpress: > http://futility.mine.nu/back/2005/02/04/126/ > > Ross, I'd like to add the wagger to the list of services on the > discoverable-bookmarklet page... but not if it's going to break in > a > few days. Let me know if we can come up with an agreeable > workaround. > > -Dan > > > ---------------------------------------------------------------------- This email was composed using the GTEL Webmail client. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or priviledged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Georgia Tech Library and Information Center http://www.library.gatech.edu ---------------------------------------------------------------------- From alf at hubmed.org Mon Feb 7 16:44:32 2005 From: alf at hubmed.org (Alf Eaton) Date: Mon Feb 7 16:44:38 2005 Subject: [gcs-pcs-list] Appropriate resolver links in HubMed Message-ID: <1abab3b08af8276bb78e9ea312461a2c@hubmed.org> I've just added the links for the 'appropriate resolver' bookmarklets into HubMed's abstract pages - here's an example page to try out: http://www.hubmed.org/display.cgi?uids=15069086 though I don't particularly like putting the data in the 'name' attribute either. The bookmarklets don't seem to work in Safari at the moment, unfortunately. Adapting a bookmarklet I made earlier, this example seems to work ok in both Safari and Firefox (at least): javascript: var links=document.getElementsByTagName('a'); for(var i=0;i References: <1abab3b08af8276bb78e9ea312461a2c@hubmed.org> Message-ID: <2a7a77bea106f0bcb5a5c35cc11bf4e2@yale.edu> On Feb 7, 2005, at 4:44 PM, Alf Eaton wrote: > I've just added the links for the 'appropriate resolver' bookmarklets > into HubMed's abstract pages - here's an example page to try out: > http://www.hubmed.org/display.cgi?uids=15069086 Great! I'll add Hubmed to the list of examples. > though I don't particularly like putting the data in the 'name' > attribute either. Perhaps the name part doesn't matter, and this little bookmarklet prototype should just tweak any existing href with the right rel and title tags? > The bookmarklets don't seem to work in Safari at the moment, > unfortunately. Adapting a bookmarklet I made earlier, this example > seems to work ok in both Safari and Firefox (at least): It indeed works in safari! Sadly, though, it doens't seem to be working in IE6 (win2k) for me. Try it here: http://curtis.med.yale.edu/dchud/resolvable/index2.cgi Can anyone verify/fix so that it works in the Big Three (IE, FX, Safari)? > I also wanted to point to a couple of bookmarklets I made last month, > which were along the same lines but altered existing SFX and OpenURL > links instead of inserting new graphics: I saw these when you posted them; the question of how to indicate a mungeable openurl on-screen is somewhat tricky. Perhaps a ubiquitous, simple, subtle graphic like the orange RSS boxes (okay, not so subtle...) or the tiny-caps-text wide rectangles thingies (that say "MT | POWERED" or "ATOM | 0.3" or whatnot) would be a helpful sign we could all try? Many thanks, -Dan From ross.singer at library.gatech.edu Tue Feb 8 23:00:47 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Feb 8 23:00:50 2005 Subject: [gcs-pcs-list] Appropriate resolver links in HubMed In-Reply-To: <2a7a77bea106f0bcb5a5c35cc11bf4e2@yale.edu> References: <1abab3b08af8276bb78e9ea312461a2c@hubmed.org> <2a7a77bea106f0bcb5a5c35cc11bf4e2@yale.edu> Message-ID: <4976.66.156.31.21.1107921647.squirrel@66.156.31.21> On Tue, February 8, 2005 7:40 pm, Daniel Chudnov said: >> though I don't particularly like putting the data in the 'name' >> attribute either. > > Perhaps the name part doesn't matter, and this little bookmarklet > prototype should just tweak any existing href with the right rel > and > title tags? > I'm not sure I have any problem with the "name" attribute... Obviously, you might run into the danger of it not being unique, but it is sort of nice to be able to use the OpenURL as an anchor to link to, as well. I'm still taking in some of this... I haven't formed an opinion about putting the OpenURL in the href attribute. It seems logical enough. My hangup has been using the "class" attribute to define the thing. Why not use the "type" attribute and create a new mime-type? I don't know exactly what that might be, but rel="alternate" type="text/openurl-0.1" (or text/openurl-1.0 or text/xml-openurl-x.x if we want to link to external XML document with our OpenURL) seems more appropriate. We'd have to apply for some mimetypes, I guess, but I don't really know how that works. Although I can probably learn to love "class='OpenURL'", as well. Another alternative, possibly, would be the "Object" tag: http://www.w3.org/TR/html4/struct/objects.html#h-13.3 I have no idea if browsers try to do something wonky with this tag, though. -Ross. ---------------------------------------------------------------------- This email was composed using the GTEL Webmail client. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or priviledged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Georgia Tech Library and Information Center http://www.library.gatech.edu ---------------------------------------------------------------------- From alf at hubmed.org Wed Feb 9 10:19:32 2005 From: alf at hubmed.org (Alf Eaton) Date: Wed Feb 9 10:19:40 2005 Subject: [gcs-pcs-list] Appropriate resolver links in HubMed In-Reply-To: <2a7a77bea106f0bcb5a5c35cc11bf4e2@yale.edu> References: <1abab3b08af8276bb78e9ea312461a2c@hubmed.org> <2a7a77bea106f0bcb5a5c35cc11bf4e2@yale.edu> Message-ID: On Feb 9, 2005, at 01:40, Daniel Chudnov wrote: >> though I don't particularly like putting the data in the 'name' >> attribute either. > > Perhaps the name part doesn't matter, and this little bookmarklet > prototype should just tweak any existing href with the right rel and > title tags? Here's a version of the bookmarklet that replaces existing links (at least in HubMed - test here: http://www.hubmed.org/display.cgi?uids=15069086 ): javascript: var links=document.getElementsByTagName('a'); for(var i=0;i Hi All, I've just finishing WAGging Elsevier's Scirus (http://www.scirus.com/). For all journal articles, WAG the Dog will now create an OpenURL and, like Google Scholar, will check and display local options. For PubMed articles, I'm also creating a link to a WAGged version of the appropriate HubMed page. I certainly have some ideas for the keyword links on the right, but it's time to go home now. I can't actually send a WAGged page, because for some reason it doesn't want to format correctly. -Ross.