From daniel.chudnov at yale.edu Wed Jan 5 20:59:34 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jan 5 20:59:35 2005 Subject: [gcs-pcs-list] back to work. Message-ID: <41DC9B86.5060804@yale.edu> A few quick comments: there's been a little problem with the list. If anyone's had trouble post/sub/unsub/etc-ing, please let me know, and accept my apologies. I think it's fixed now. Second, and back on topic, last (year) Richard wrote: > If anyone has any thoughts, or can think of why any of these > [autodiscovery] methods would be unsuitable for a particular domain > then shall we talk about it on the list? In cleaning out a half-dozen far-flung weblogs, wikis, and forums (fora?) over the past few months from a torrent of spam, I've started to think more about whether autodiscovery will just lead to more torrents of abusive noise. But, we'll come to that bridge soon enough... there is other ongoing work that leads me to worry less. Something to keep in mind though, especially upon seeing the pattern where broad application of simple autodiscovery in apps like weblogs quickly leads to trackback spam and so on. I'm still very excited about the possibilities of autodiscovery, if not more so since the holiday break. In the next few weeks I'm hoping to code up as many autodiscovery prototypes as possible, and would invite all interested to join in. Or, if you're otherwise busy with projects you think might interest others here, do tell. :) Best wishes for the gregorian new year, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From T.Hammond at nature.com Thu Jan 6 06:29:05 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Thu Jan 6 06:29:08 2005 Subject: [gcs-pcs-list] Hello List Message-ID: <125F7834E11A5741A7D79412EE3504F90F26CE40@UK1APPS2.nature.com> Just wanted to say 'Hi Everybody' after getting successfully subscribed to the list. I would also like to echo Dan's general excitement about autodiscovery possibilities. We're especially interested in seeing what can be done with the new OpenURL Framework (it's been a long time in the building), RSS, and how tools like our new experimental bookmarking system Connotea (http://www.connotea.org/) can be integrated with other services out there like CiteULike, Unalog, etc. as well as with blogs and wikis. Cheers, Tony Tony Hammond New Technology, Nature Publishing Group 4 Crinan Street, London N1 9XW, UK tel:+44-20-7843-4659 mailto:t.hammond@nature.com > -----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: 06 January 2005 02:00 > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: [gcs-pcs-list] back to work. > > > A few quick comments: there's been a little problem with the > list. If > anyone's had trouble post/sub/unsub/etc-ing, please let me know, and > accept my apologies. I think it's fixed now. > > Second, and back on topic, last (year) Richard wrote: > > > If anyone has any thoughts, or can think of why any of > these > [autodiscovery] methods would be unsuitable for a > particular domain > then shall we talk about it on the list? > > In cleaning out a half-dozen far-flung weblogs, wikis, and forums > (fora?) over the past few months from a torrent of spam, I've > started to > think more about whether autodiscovery will just lead to more > torrents > of abusive noise. But, we'll come to that bridge soon > enough... there > is other ongoing work that leads me to worry less. Something > to keep in > mind though, especially upon seeing the pattern where broad > application > of simple autodiscovery in apps like weblogs quickly leads to > trackback > spam and so on. > > I'm still very excited about the possibilities of > autodiscovery, if not > more so since the holiday break. In the next few weeks I'm hoping to > code up as many autodiscovery prototypes as possible, and > would invite > all interested to join in. Or, if you're otherwise busy with > projects > you think might interest others here, do tell. :) > > Best wishes for the gregorian new year, > > -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 > ******************************************************************************** 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 daniel.chudnov at yale.edu Thu Jan 6 16:52:25 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Jan 6 16:52:31 2005 Subject: [gcs-pcs-list] sample inline openurl Message-ID: <41DDB319.6090901@yale.edu> To get the ball rolling some more on autodiscovery goodness, here's a sample inline openurl reference, generated by an sfx instance here at Yale. http://www.inkdroid.org:8888/274 This is pretty useful as-is. Tweaking, shortening a bit and removing vendor- and holdings-specific stuff for brevity, it becomes: Entrez:PubMed 6 [Individual outpatient care versus group education programs. Which leads to greater change in dietary and physical activity habits for obese children?] 468 0021-7557 474 80 article 0021-7557 JORNAL DE PEDIATRIA ORGAO OFICIAL I don't quite remember if this exactly matches the openurl spec but it could easily be made to. Aside from this there so many options for fitting this into html source I'll just ignore much of that for now. As for embedding this into a tag, it seems we're limited by the spec: http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes ...unless we reference a profile, or just stuff it into a . That would all be well and good for a contemporary-resolver result screen, where its context object is just a singular object. For a longer result set, a single meta tag could identify a GetRecord-able service location, and that same openurl above could just become: sid=Entrez:PubMed&id=pmid:15622423 ...and CSS could turn off rendering or whatnot. That way you could put multiple openurls on the page and external apps could route them through the service location specified in the meta tag as needed. I'll stop there because that's a lot of stuff and we have several new members (and several old members who might not have bargained for this level of detail). Does any of this start to click for anyone? Btw, to other recent list-joiners... the seed of this list was a BoF at the recent DLF meeting in Baltimore, the topic of which was roughly "'Gather, Create, Share' systems for personal collections." The first 15-20 members were at that meeting and expressed an interest in tracking progress. I've separately invited other folks to join in the discussion as this seemed a good place to start. New members who haven't yet are hereby invited to say hi and give a blurb on what you've been working on in this area. Or not. :) That's the administrivia for the day, I hope it's still palatable to all. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Thu Jan 6 17:29:18 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Jan 6 17:31:17 2005 Subject: [gcs-pcs-list] Greetings and whatnot In-Reply-To: <41DDB319.6090901@yale.edu> References: <41DDB319.6090901@yale.edu> Message-ID: <41DDBBBE.1010909@library.gatech.edu> Hello everybody. Given Dan's mandate (or invitation or whatever) to speak up, here I go. I am, as I'm sure are all of you are, extremely excited about the potential of autodiscovery. When I read Dan and Jeremy's article on this topic, it completely validated all my incoherent and unintelligible rantings about deemphasizing the notion of "library as destination" (follow me here) and, instead, focusing on exporting "the library" to wherever the user happens to be. Even more important than filling me with an unwarranted sense of self-worth, their article provides a tangible way to achieve this. And, a simple way, to boot! While I knew that forcing users into our webspaces was a bad and inefficient practice that would forever relegate us into "niche" status, I really had no idea how to avoid that. Then I read about autodiscovery and my entire view of the way libraries should work changed. And I think the vigor that I embraced this philosophy is really creeping my coworkers out. But enough about me... Actually, not enough about me... I haven't said why I'm here, yet. 1) This fits well into what I've been working on with internet resource localization (first Google Scholar; next, the world!), because, frankly, it would make that project a million times easier. 2) I am working on a local faculty publications (articles/books/etc.) citation database, and since I already have all the citation information there (and will be including an openurl for local access to the resource, anyway), adding openurl autodiscovery would be a snap. Plus it would make the database much more useful. It would also allow the framework to be shared with other institutions, opening the possibility to create larger aggregated databases with links to local openurl resolvers. As always, I am beginning to lose coherence, so I'm going to leave it at that. So, anyway, I am glad to be here. -Ross. From credding at Princeton.EDU Thu Jan 6 18:04:07 2005 From: credding at Princeton.EDU (Clay Redding) Date: Thu Jan 6 18:04:10 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <41DDB319.6090901@yale.edu> References: <41DDB319.6090901@yale.edu> Message-ID: <41DDC3E7.6000103@princeton.edu> Dan, I think this makes perfect sense. I only have a rhetorical, no-brainer observation that doesn't necessarily warrant a response. The beauty of XHTML modularization would mean that we could actually embed your inside the XHTML with its own namespace. The downside of XHTML, of course, is that even without modularization, browsers don't seem to know what to do with it in terms of rendering it for HTML display or simply treating it as data. I've used XForms as an XHTML module, and it only worked with the X-Smiles browser, which accepts modularization and the W3C's Compound Document Format concept for mixing multiple namespaces in one document. Other browsers choked on it in various ways. I hear Mozilla/'Fox has XForms on its map, so maybe modularization isn't too far away. But in terms of making extensions and browser-specific code, I would think that namespaces and modularization would provide the ideal hooks. Like you said, simple inline tags like , , and/or would work adequately in the meantime. Does anyone know the genesis of how Firefox began to recognize RSS feeds in the element? Was it through a Bugzilla request?Perhaps getting them to recognize OpenURL or OAI services in a similar manner is in order? Clay Daniel Chudnov wrote: > To get the ball rolling some more on autodiscovery goodness, here's a > sample inline openurl reference, generated by an sfx instance here at > Yale. > > http://www.inkdroid.org:8888/274 > > This is pretty useful as-is. Tweaking, shortening a bit and removing > vendor- and holdings-specific stuff for brevity, it becomes: > > > Entrez:PubMed > 6 > [Individual outpatient care versus group > education programs. Which leads to greater change in dietary and > physical activity habits for obese children?] > 468 > 0021-7557 > 474 > 80 > > article > 0021-7557 > JORNAL DE PEDIATRIA ORGAO OFICIAL > > > I don't quite remember if this exactly matches the openurl spec but it > could easily be made to. Aside from this there so many options for > fitting this into html source I'll just ignore much of that for now. > As for embedding this into a tag, it seems we're limited by the > spec: > > http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes > > ...unless we reference a profile, or just stuff it into a . > > That would all be well and good for a contemporary-resolver result > screen, where its context object is just a singular object. For a > longer result set, a single meta tag could identify a GetRecord-able > service location, and that same openurl above could just become: > > sid=Entrez:PubMed&id=pmid:15622423 > > ...and CSS could turn off rendering or whatnot. That way you could > put multiple openurls on the page and external apps could route them > through the service location specified in the meta tag as needed. > > I'll stop there because that's a lot of stuff and we have several new > members (and several old members who might not have bargained for this > level of detail). Does any of this start to click for anyone? > > Btw, to other recent list-joiners... the seed of this list was a BoF > at the recent DLF meeting in Baltimore, the topic of which was roughly > "'Gather, Create, Share' systems for personal collections." The first > 15-20 members were at that meeting and expressed an interest in > tracking progress. I've separately invited other folks to join in the > discussion as this seemed a good place to start. New members who > haven't yet are hereby invited to say hi and give a blurb on what > you've been working on in this area. Or not. :) > > That's the administrivia for the day, I hope it's still palatable to all. > > -Dan > > From daniel.chudnov at yale.edu Fri Jan 7 11:30:48 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Jan 7 11:28:28 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <41DDC3E7.6000103@princeton.edu> References: <41DDB319.6090901@yale.edu> <41DDC3E7.6000103@princeton.edu> Message-ID: <41DEB938.3050701@yale.edu> Clay Redding wrote: > > modularization isn't too far away. But in terms of making extensions > and browser-specific code, I would think that namespaces and > modularization would provide the ideal hooks. Like you said, simple > inline tags like , , and/or > would work adequately in the meantime. To paraphrase my favorite web framework [1] I'd vote for a philosophy of "no magic" and "do as little as possible". or
seemed like the best candidates to me for now because they're already wired in and we wouldn't be abusing their intent too greatly. I'd love to also try to try a full-on xhtml module, but what's the simplest possible non-magical thing we can do that would work in the most places right now? > Does anyone know the genesis of how Firefox began to recognize RSS feeds > in the element? Was it through a Bugzilla request?Perhaps > getting them to recognize OpenURL or OAI services in a similar manner is > in order? I don't know what the actual process was, but there was an earlier plugin called MozLinker that did roughly the same thing, sans interface polish. Maybe they just moved the code into the trunk? -Dan [1] http://www.mems-exchange.org/software/quixote/overview.html -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From camster at citeulike.org Sun Jan 9 14:08:04 2005 From: camster at citeulike.org (Richard Cameron) Date: Sun Jan 9 14:08:08 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <41DDB319.6090901@yale.edu> References: <41DDB319.6090901@yale.edu> Message-ID: On 6 Jan 2005, at 21:52, Daniel Chudnov wrote: > To get the ball rolling some more on autodiscovery goodness, here's a > sample inline openurl reference, generated by an sfx instance here at > Yale. > > http://www.inkdroid.org:8888/274 I'd say this looks jolly good. It just seems to just do the job without being overly complicated. > Aside from this there so many options for fitting this into html > source I'll just ignore much of that for now. As for embedding this > into a tag, it seems we're limited by the spec: > > http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes What's wrong with using "Alternate" like RSS does [except from the point you make below about that only letting you embed one article on an HTML page]? > sid=Entrez:PubMed&id=pmid:15622423 > > ...and CSS could turn off rendering or whatnot. That way you could > put multiple openurls on the page and external apps could route them > through the service location specified in the meta tag as needed. The one question I've got is a bit woolly, and probably really isn't even a question: How do external applications associate which bits of the web page correspond to the tag? It's easy to write a Firefox extension which just renders your tag as something visible, and thus the user sees a button at an appropriate place on the page, but would you go about doing things for IE? Suppose, for instance, you wanted to work with PubMed. When you search, you get a list of articles back with checkboxes associated with each of them. If PubMed buy into your autodiscovery scheme, and someone wants to write, say, a bookmarklet for IE which detects which articles the user has checked and does something with them (whatever that something might be), how would that work? How can you work out which tag should go with which checkbox? Richard. From ross.singer at library.gatech.edu Sun Jan 9 21:58:36 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sun Jan 9 21:58:38 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: References: <41DDB319.6090901@yale.edu> Message-ID: <2819.208.61.25.254.1105325916.squirrel@208.61.25.254> I'm not sure I see the limitations with the link tag... Can't you link to more than one, say, stylesheet on a page? Am I misreading this? I admit to being currently under the influence of NyQuil. -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 daniel.chudnov at yale.edu Mon Jan 10 17:30:45 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Jan 10 17:30:48 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: References: <41DDB319.6090901@yale.edu> Message-ID: <41E30215.8080803@yale.edu> Richard Cameron wrote: > > What's wrong with using "Alternate" like RSS does [except from the point > you make below about that only letting you embed one article on an HTML > page]? A few general concerns. Maybe they're not valid. - it's already used for RSS. :) - it might be unwieldy for arbitrary search result screens or exhibit pages with multiple object references to have a big long list of tags in the HEAD. - it might be awkward for interface designers to stuff dynamic page (like search result) references up in a page template element. shouldn't be, but might. > How do external applications associate which bits of the web page > correspond to the tag? It's easy to write a > Firefox extension which just renders your tag as something visible, and > thus the user sees a button at an appropriate place on the page, but > would you go about doing things for IE? Couldn't we write an IE extension? > Suppose, for instance, you wanted to work with PubMed. When you search, > you get a list of articles back with checkboxes associated with each of > them. If PubMed buy into your autodiscovery scheme, and someone wants to > write, say, a bookmarklet for IE which detects which articles the user > has checked and does something with them (whatever that something might > be), how would that work? How can you work out which class='openurl'> tag should go with which checkbox? To this point it seems that wrapping object references (be they search hits or full-page displays) in a
or the like (is there a better attr on the div element?) might be useful. Might also be awkward for coders/designers but there's an argument that it makes some semantic sense. One of the experiments on my autodiscovery whiteboard actually is a demo medline interface. We can test stuff out there, I'll try to have it running within a few days. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Mon Jan 10 17:34:52 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Jan 10 17:34:54 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <2819.208.61.25.254.1105325916.squirrel@208.61.25.254> References: <41DDB319.6090901@yale.edu> <2819.208.61.25.254.1105325916.squirrel@208.61.25.254> Message-ID: <41E3030C.5030005@yale.edu> Ross Singer wrote: > I'm not sure I see the limitations with the link tag... Can't you > link to more than one, say, stylesheet on a page? Aside from those mentioned in my last message, Richard's point about the metadata being physically/semantically separated from the objects themselves is probably the biggest concern here. I think you're right that pages can have arbitrarily many link elements. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Mon Jan 10 20:29:29 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Jan 10 20:29:31 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <41E3030C.5030005@yale.edu> References: <41DDB319.6090901@yale.edu> <2819.208.61.25.254.1105325916.squirrel@208.61.25.254> <41E3030C.5030005@yale.edu> Message-ID: <2175.208.61.25.76.1105406969.squirrel@208.61.25.76> On Mon, January 10, 2005 5:34 pm, Daniel Chudnov said: > Aside from those mentioned in my last message, Richard's point > about the > metadata being physically/semantically separated from the objects > themselves is probably the biggest concern here. I think you're > right > that pages can have arbitrarily many link elements. > I guess I understand this concern, but I'm not sure that the alternative is any better. We frequently link to things that are fundamental to the structure/integrity of a document (for instance, a DTD or schema) that isn't located anywhere inside the document. I am little more concerned about placing this data that we probably don't wish to display in a block element and then hide it from the viewer. If we were to lose the stylesheet or whatever, it would make a mess of the page (granted, losing the stylesheet would probably make a mess of the page, anyway, but...). Also, by placing it in a span or div, we don't actually say anything about the data that is in that span or div. This won't really help "the semantic web" at all, because I'm not sure how anyone (or anything) is going to know that this data shouldn't be displayed. Going back to Richard's concern about getting applications to respond to , I think by using these everyday block elements and everyday attributes, you are much more likely to run into "namespace" issues. How many
blocks are already using one of our arbitrary "class" names? How do you enforce any sort of authority on this? It just seems too "hack"-y to me. Again, it may the NyQuil talking (and, oh, the things NyQuil says!), but I think extending the tag to meet our nefarious needs (or, if we'd rather keep the data in the page, perhaps a combination of and tags - a reference in the meta tag to where it should appear in the page = the a tag) would keep things simpler, cleaner and more usable in the future. Maybe I'm not fully understanding the implications of what I'm pushing here, but I don't really think creating hacks around display elements will be sustainable. -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 daniel.chudnov at yale.edu Mon Jan 10 22:48:14 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Jan 10 22:45:52 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <2175.208.61.25.76.1105406969.squirrel@208.61.25.76> References: <41DDB319.6090901@yale.edu> <2819.208.61.25.254.1105325916.squirrel@208.61.25.254> <41E3030C.5030005@yale.edu> <2175.208.61.25.76.1105406969.squirrel@208.61.25.76> Message-ID: <41E34C7E.8040701@yale.edu> Ross Singer wrote: > > displayed. Going back to Richard's concern about getting > applications to respond to , I think by > using these everyday block elements and everyday attributes, you > are much more likely to run into "namespace" issues. How many >
blocks are already using one of our arbitrary "class" names? > How do you enforce any sort of authority on this? I dunno. But, there are a lot of people on this list who have a hand in a lot of content, so if we can produce a compelling case for one or more of these approaches, it's possible we can demonstrate something that other people might try. In the meantime, there's nothing... > It just seems too "hack"-y to me. Again, it may the NyQuil > talking (and, oh, the things NyQuil says!), but I think extending > the tag to meet our nefarious needs (or, if we'd rather > keep the data in the page, perhaps a combination of and > tags - a reference in the meta tag to where it should appear in > the page = the a tag) would keep things simpler, cleaner and more > usable in the future. Double-checking the html spec for the tag [1] I'm reminded we get all the same link-types available in the head's link element. Definitely worth exploiting. In any case, let's throw 'em all against the wall and see what sticks. Probably easier to convince folks in code than in prose. :) Now, I think I need some of that NyQuil. -Dan [1] http://www.w3.org/TR/html401/struct/links.html#edef-A -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From arhyno at uwindsor.ca Tue Jan 11 09:41:23 2005 From: arhyno at uwindsor.ca (arhyno@uwindsor.ca) Date: Tue Jan 11 09:42:17 2005 Subject: [gcs-pcs-list] sample inline openurl In-Reply-To: <41E34C7E.8040701@yale.edu> Message-ID: >Double-checking the html spec for the tag [1] I'm reminded we get >all the same link-types available in the head's link element. >Definitely worth exploiting. > It's worth looking at the spec on link types [1] as well. I posted these to unalog [2] but the FOAF work on autodiscovery [3] might have some connection here. Ian Davis mentions profiles [4] in describing his experiments with FOAF in HTML and I wonder if defining profiles is a part of the process that needs to be worked in. From a sheer coding perspective, the link element may be a bit more of a pain to deal in things like bookmarklets but I suspect that content suppliers would find it the easiest to implement. CC/PP [5] has also been a W3C recommendation for almost a year now, I don't think it is getting much traction among the database community yet but it strikes me that its goal to provide a " delivery context" to a Web server is a key layer in routing semantics back and forth. The cell phone folks are keen on CC/PP and that has to be a powerful lobby group for getting services implemented. art [1] http://www.w3.org/TR/REC-html40/types.html#type-links [2] http://unalog.com [3] http://rdfweb.org/topic/Autodiscovery [4] http://internetalchemy.org/2003/02/foafAutodiscovery [5] http://www.w3.org/2004/01/ccpp-pressrelease From T.Hammond at nature.com Tue Jan 11 09:45:59 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Tue Jan 11 09:46:58 2005 Subject: [gcs-pcs-list] FW: Google Scholar, Firefox, and OpenURLs Message-ID: <125F7834E11A5741A7D79412EE3504F90F26CE73@UK1APPS2.nature.com> I'm sure you guys have all seen this, but thought I'd make doubly sure. Cheers, Tony -----Original Message----- From: openurl-bounces@caltech.edu [mailto:openurl-bounces@caltech.edu] On Behalf Of Eric Hellman Sent: 11 January 2005 07:49 To: 'openurl@caltech.edu' Subject: Re: Google Scholar, Firefox, and OpenURLs Peter Binkley's "proof-of-concept" got us pretty excited about Firefox and the possibilities of using plug-ins to put OpenURL's EVERYWHERE they belong - including Google Scholar. One of our engineers, Tom Ventimiglia, has spent a fair amount of time working on what Peter started to see how far it would go. Tom has added 1. NISO OpenURL 1.0 support. OpenURL 1.0 lets you do some really interesting things such as put the "referring entity" and "referent" url's into the openURL. 2. Integration of DOIs and PMIDs into OpenURLs. This results in real usability of the resulting OpenURL's when you're doing research such as in the biomedical area. This pulls information from all links provided by Google, not just the first one. 3. An "Options" window for entering library-specific configuration (linkserver url, link text, image, openurl version). 4. Profiles to allow users to quickly change the tool's configuration. 5. Automatic updates via Firefox's update service. We thought this was very important since you never know what google is going to do with their html. "OpenURL Referrer" is available at http://www.openly.com/openurlref/ It can be used with OpenURL 0.1 or 1.0 linkservers such as 1Cate, SFX, Sirsi Resolver, LinkFinderPlus, LinkSource, OLink, LinkSolver, OL2, Swetswise Linker, ArticleLinker, etc. It's free; full source and data are available under the Mozilla "Tri-license" (MPL+GPL+LGPL). The interesting thing looking forward is not so much that this works for Google Scholar (which has to be considered promising but incomplete at this stage), but that it could work pretty well for some of information services that haven't "gotten it" yet. Eric At 12:44 PM -0700 11/30/04, Binkley, Peter wrote: >As a proof-of-concept I've built a Firefox extension that adds OpenURL >links to the results lists in Google Scholar. It can be downloaded >here: http://www.ualberta.ca/~pbinkley/gso/ . The functionality is >pretty basic but it shows what might be possible. > >Ideally, Google will build this functionality directly into Google >Scholar, and we'll be able to integrate Google Scholar fully with our >local access systems. In the meantime, this extension is fun to play >with. It is by no means perfect, but it is perhaps a taste of what we >have to look forward to. > >You'll need the latest version of Firefox to use it (1.0, not the 1.0 >preview). > >Peter > >Peter Binkley >Digital Initiatives Technology Librarian >Information Technology Services >4-30 Cameron Library >University of Alberta Libraries >Edmonton, Alberta >Canada T6G 2J8 >Phone: (780) 492-3743 >Fax: (780) 492-9243 >e-mail: peter.binkley@ualberta.ca -- 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 ******************************************************************************** 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 ross.singer at library.gatech.edu Fri Jan 14 16:30:49 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Jan 14 16:32:50 2005 Subject: [gcs-pcs-list] [Fwd: [lib-systems] Google Scholar Localizer] Message-ID: <41E83A09.7000900@library.gatech.edu> I'm forwarding this on to this list because I just added functionality that is in line with the discussion here. After every paragraph, a is inserted with a link to an openurl. What's returned is OpenURL 0.1 as an XML document (your mileage may vary on validity, it hasn't been extensively tested). So on this page: http://scholar.google.com/scholar?q=hegel%27s+dialectic&ie=UTF-8&oe=UTF-8&hl=en&btnG=Search The first result creates a link that looks like: The last result creates a link that looks like: If you actually follow the link, you'll get the XML. -Ross. -------------- next part -------------- An embedded message was scrubbed... From: Ross Singer Subject: [lib-systems] Google Scholar Localizer Date: Fri, 14 Jan 2005 12:58:28 -0500 Size: 6554 Url: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20050114/9ff1d0d4/lib-systemsGoogleScholarLocalizer.eml