From eric at openly.com Tue Apr 5 13:14:44 2005 From: eric at openly.com (Eric Hellman) Date: Tue Apr 5 12:14:50 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion Message-ID: I've been talking to a number of people about the work that people on this list have been doing, and I've been surprised at the high level of interest (along with low level of awareness) at brand-name places. I get a lot of inquiries from publishers of many stripes about ways that they can implement openurl, and the idea of plugins, bookmarklets and related technologies has a lot of appeal to them. That interest has motivated to write up a suggested convention for the use of OpenURL to embed metadata-based links in plain HTML: http://www.openly.com/openurlref/latent.html I've showed the suggested convention to a small number of people. The uniform reaction has been: "this would be simple to implement." and: "as long as we don't have to do something similar but different for somebody else". So I think the time is now for a large bunch of us to say "this is what we're going to do" and I think a lot of people will be ready to follow. It certainly doesn't have to be my suggestion, but it has to be clear and simple, and it can't be forked. In terms of strategy, it would be good to have May 1 as a goal for having something final to start publicizing, perhaps with a list of "signers" of the convention that results. If you or your organization are willing to be a signer, this list would be a good place to make that known. Openly is ready to add support for whatever results to our OpenURL Referrer Plugin for Firefox (which has doubled its installed base every month), and to the open-access e-journal we produce for the Materials Research Society. 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 From daniel.chudnov at yale.edu Tue Apr 5 13:13:04 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 5 13:13:07 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: Message-ID: <20050405171304.GC19684@curtis.med.yale.edu> Eric Hellman wrote, on Tue, Apr 05, 2005 at 12:14:44PM -0500: > In terms of strategy, it would be good to have May 1 as a goal for > having something final to start publicizing, perhaps with a list of > "signers" of the convention that results. If you or your organization > are willing to be a signer, this list would be a good place to make > that known. Openly is ready to add support for whatever results to > our OpenURL Referrer Plugin for Firefox (which has doubled its > installed base every month), and to the open-access e-journal we > produce for the Materials Research Society. Good idea. Fwiw, one of the reasons things have been quiet around here (this obscurely named list, that is :) is that some of us have a paper coming out soon walking through why this is a good idea. It's been confirmed for the upcoming issue 43 of Ariadne, due at the end of April. It's possible we could add a blurb to the end of that piece before it is published to highlight whatever convention represents consensus, or at least a pointer to your page or whatever page offers the concrete proposal. The Canary Database (Yale School of Medicine) will also support whatever convention we choose. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From alf at hubmed.org Tue Apr 5 16:25:50 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 5 16:25:56 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: Message-ID: <4252F44E.2030905@hubmed.org> Eric Hellman wrote: > I've been talking to a number of people about the work that people on > this list have been doing, and I've been surprised at the high level of > interest (along with low level of awareness) at brand-name places. I get > a lot of inquiries from publishers of many stripes about ways that they > can implement openurl, and the idea of plugins, bookmarklets and related > technologies has a lot of appeal to them. That interest has motivated to > write up a suggested convention for the use of OpenURL to embed > metadata-based links in plain HTML: > http://www.openly.com/openurlref/latent.html > > I've showed the suggested convention to a small number of people. The > uniform reaction has been: "this would be simple to implement." and: "as > long as we don't have to do something similar but different for somebody > else". > > So I think the time is now for a large bunch of us to say "this is what > we're going to do" and I think a lot of people will be ready to follow. > It certainly doesn't have to be my suggestion, but it has to be clear > and simple, and it can't be forked. > > In terms of strategy, it would be good to have May 1 as a goal for > having something final to start publicizing, perhaps with a list of > "signers" of the convention that results. If you or your organization > are willing to be a signer, this list would be a good place to make that > known. Openly is ready to add support for whatever results to our > OpenURL Referrer Plugin for Firefox (which has doubled its installed > base every month), and to the open-access e-journal we produce for the > Materials Research Society. > > Eric > I think it's a good idea too. However, I don't like using the 'class' attribute for this purpose any more than I liked using the 'title' attribute previously. Here's another suggestion: which seems to fit the HTML specifications (not that using 'class' doesn't either, as I understand it) at http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2 and http://www.w3.org/TR/REC-html40/types.html#type-links Maybe the text/html isn't appropriate if the item at the other end of the resolver doesn't have to be HTML - is that the case? alf. From ross.singer at library.gatech.edu Tue Apr 5 17:14:48 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Apr 5 17:17:51 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <4252F44E.2030905@hubmed.org> References: <4252F44E.2030905@hubmed.org> Message-ID: <4252FFC8.5080900@library.gatech.edu> Alf Eaton wrote: > Here's another suggestion: > href="?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:ctx:mtx:journal&rft.issn=1045-4438"> > > I'm not sure "rel" can be used this way. http://www.w3.org/TR/REC-html40/types.html#type-links rel="alternate" still seems appropriate I'm also not sure about type="text/html". Is there a plan to register z39.88 as an xml mime-type? So I'm not really helping come up with an alternate way to identify these items. "Class" still seems fine. As I told Eric in another email, my biggest concern is the added complexity something like this: rft_val_fmt=info:ofi/fmt:ctx:mtx:journal brings and what its impact might be on mainstream adoption of this proposal. I am torn between the benefits of v. 1.0 and the simplicity of "genre=journal". I wish some sort of happy medium could be found (see RSS 0.92/1.0 vs. RSS 2.0). That being said, WAG the Dog will conform to whatever is decided. -Ross. From alf at hubmed.org Tue Apr 5 17:35:17 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 5 17:35:28 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <4252FFC8.5080900@library.gatech.edu> References: <4252F44E.2030905@hubmed.org> <4252FFC8.5080900@library.gatech.edu> Message-ID: <8e45a103bff7ff33c9766c07db85be0a@hubmed.org> On Apr 5, 2005, at 23:14, Ross Singer wrote: > Alf Eaton wrote: > >> Here's another suggestion: >> > href="?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:ctx:mtx: >> journal&rft.issn=1045-4438"> >> > I'm not sure "rel" can be used this way. > http://www.w3.org/TR/REC-html40/types.html#type-links > > rel="alternate" still seems appropriate At the end of that section it says "Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details." There are some precedents in XFN: http://gmpg.org/xfn/ and CC licences: http://tantek.com/log/2004/02.html#d25t1805 - both linked from http://www.solitude.dk/blogprofile/011/ which began as a discussion about how to link to enclosures: http://www.solitude.dk/archives/20041026-1300/about.php rel="alternate z3988" is another possibilty (the attribute can ba a space-separated list), but either way it's not necessarily the case that an OpenURL link in a web page is going to lead to an alternate version of that page - it might just be linking to another document (a citation for example, or a search result). Also, using just rel="alternate" means that you still need another attribute to identify it as a latent OpenURL link, whereas using rel="z3988" solves both those problems. > I'm also not sure about type="text/html". Is there a plan to register > z39.88 as an xml mime-type? > > So I'm not really helping come up with an alternate way to identify > these items. "Class" still seems fine. > > As I told Eric in another email, my biggest concern is the added > complexity something like this: > > rft_val_fmt=info:ofi/fmt:ctx:mtx:journal > > brings and what its impact might be on mainstream adoption of this > proposal. > > I am torn between the benefits of v. 1.0 and the simplicity of > "genre=journal". I haven't followed the discussion of the OpenURL specification, but I wonder what the reasoning is/was behind the change from 'genre=journal' to 'rft_val_fmt=info:ofi/fmt:ctx:mtx:journal'. Presumably it provides some extra information, but it's difficult to tell what that is (at a glance). alf. From daniel.chudnov at yale.edu Tue Apr 5 18:04:09 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 5 18:04:11 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: Message-ID: <20050405220409.GS19684@curtis.med.yale.edu> Eric Hellman wrote, on Tue, Apr 05, 2005 at 12:14:44PM -0500: > In terms of strategy, it would be good to have May 1 as a goal for > having something final to start publicizing, perhaps with a list of > "signers" of the convention that results. If you or your organization Given that there is some discussion still to be had, and that your link, Eric, is now "out in the wild" (as such things go), perhaps it might be useful to add some sort of clear Status to that page? It could, perhaps, indicate clearly that the specific technique is still open for discussion, that such discussion is welcome on this list, that the actual "proposal" is in working/draft form, and that we are collectively shooting for some working concensus by May 1. If it did not, it might be misinterpreted in the interim as the proposal you suggest we hope to make. :) Just a thought, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From T.Hammond at nature.com Wed Apr 6 04:59:21 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Wed Apr 6 04:59:33 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion Message-ID: <125F7834E11A5741A7D79412EE3504F90F26D1AC@UK1APPS2.nature.com> > Here's another suggestion: > href="?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:ctx:mtx:jo > urnal&rft.issn=1045-4438"> Hi: Was wondering if punctutation in attributes really is problematic as Eric claims or not, i.e. why can't one use 'Z39.88' instead of 'Z3988'. Just asking out of sheer ignorance. Would like to hear any explanation on that. Thanks, 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 eric at openly.com Wed Apr 6 11:06:35 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 6 10:06:39 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <20050405220409.GS19684@curtis.med.yale.edu> References: <20050405220409.GS19684@curtis.med.yale.edu> Message-ID: good idea, dan At 6:04 PM -0400 4/5/05, Daniel Chudnov wrote: >Eric Hellman wrote, on Tue, Apr 05, 2005 at 12:14:44PM -0500: >> In terms of strategy, it would be good to have May 1 as a goal for >> having something final to start publicizing, perhaps with a list of >> "signers" of the convention that results. If you or your organization > >Given that there is some discussion still to be had, and that your >link, Eric, is now "out in the wild" (as such things go), perhaps >it might be useful to add some sort of clear Status to that page? > >It could, perhaps, indicate clearly that the specific technique is still >open for discussion, that such discussion is welcome on this list, >that the actual "proposal" is in working/draft form, and that we are >collectively shooting for some working concensus by May 1. > >If it did not, it might be misinterpreted in the interim as the proposal >you suggest we hope to make. :) > >Just a thought, -Dan > > >-- >Daniel Chudnov >Yale Center for Medical Informatics >(203) 737-5789 -- 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 eric at openly.com Wed Apr 6 11:17:35 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 6 10:17:38 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <125F7834E11A5741A7D79412EE3504F90F26D1AC@UK1APPS2.nature.com> References: <125F7834E11A5741A7D79412EE3504F90F26D1AC@UK1APPS2.nature.com> Message-ID: The idea to use "class" was that since we wanted browsers to perform certain specialized rendering on certain anchor tags, which is what css does, the class attribute was the one most appropriate for overloading with openurl. So we mimic the what css does. Experimentally, if you put the dot in the class attribute, you can't manipulate it with css. The advantage of using class is that users can set their own css style for the Z3988 class, which may be useful. At 9:59 AM +0100 4/6/05, Hammond, Tony wrote: > > Here's another suggestion: >> > href="?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:ctx:mtx:jo >> urnal&rft.issn=1045-4438"> > >Hi: > >Was wondering if punctutation in attributes really is problematic as Eric >claims or not, i.e. why can't one use 'Z39.88' instead of 'Z3988'. Just >asking out of sheer ignorance. Would like to hear any explanation on that. > >Thanks, > >Tony -- 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 eric at openly.com Wed Apr 6 12:21:43 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 6 11:21:46 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <4252F44E.2030905@hubmed.org> References: <4252F44E.2030905@hubmed.org> Message-ID: I think the REL attribute would work, however I don't see why TYPE has anything to do with it. Concerns to address- mostly things I don't know: 1. Does this REL usage conflict with other uses of REL? REL can have a space separated list of names, so my guess is no, but seeing what the spec says and determining what browser software does is a different matter. What other applications make use of REL? A quick google search results in : Google obeys REL="nofollow" Technorati makes use of REL="tag" XFN 2. does the IE DOM expose rel? we know it exposes CLASS. If not, forget about plugins for IE anytime soon. 3. I guess what I don't like about using REL is pretty pedantic: it seems to me that the role of REL is to assign a role or attribute to the resource that is being linked to, which is not what we're doing. We're instructing a processor about how to process the anchor element, which is not the same thing. REL="cited" for example. Its like a programmer confusing an object with its pointer. Anyway, concrete benefits/drawbacks weigh much more heavily with me that attribute semantics. I would appreciate your help drawing up a list for both regarding REL vs. CLASS. Eric At 10:25 PM +0200 4/5/05, Alf Eaton wrote: > >I think it's a good idea too. However, I don't like using the >'class' attribute for this purpose any more than I liked using the >'title' attribute previously. > >Here's another suggestion: >href="?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:ctx:mtx:journal&rft.issn=1045-4438"> > >which seems to fit the HTML specifications (not that using 'class' >doesn't either, as I understand it) at >http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2 >and >http://www.w3.org/TR/REC-html40/types.html#type-links > >Maybe the text/html isn't appropriate if the item at the other end >of the resolver doesn't have to be HTML - is that the case? > >alf. -- 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 eric at openly.com Wed Apr 6 12:27:44 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 6 11:27:50 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <8e45a103bff7ff33c9766c07db85be0a@hubmed.org> References: <4252F44E.2030905@hubmed.org> <4252FFC8.5080900@library.gatech.edu> <8e45a103bff7ff33c9766c07db85be0a@hubmed.org> Message-ID: At 11:35 PM +0200 4/5/05, Alf Eaton wrote: > >I haven't followed the discussion of the OpenURL specification, but >I wonder what the reasoning is/was behind the change from >'genre=journal' to 'rft_val_fmt=info:ofi/fmt:ctx:mtx:journal'. >Presumably it provides some extra information, but it's difficult to >tell what that is (at a glance). > >alf. the first one says "this link is about a journal" the second one says "this openurl uses the "...journal" metadata format to describe the referent. It's sort of like an XML namespace declaration. The metadata format identifier was necessary for extensibility. The reason the metadata format identifier is so long is more complicated. -- 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 eric at openly.com Wed Apr 6 13:05:34 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 6 12:05:40 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion and css3 In-Reply-To: <125F7834E11A5741A7D79412EE3504F90F26D1AC@UK1APPS2.nature.com> References: <125F7834E11A5741A7D79412EE3504F90F26D1AC@UK1APPS2.nature.com> Message-ID: It looks like the CSS3 Generated and Replaced Content Module http://www.w3.org/TR/2003/WD-css3-content-20030514/ is potentially relevant to this discussion. -- 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 alf at hubmed.org Wed Apr 6 19:35:57 2005 From: alf at hubmed.org (Alf Eaton) Date: Wed Apr 6 19:36:03 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: <4252F44E.2030905@hubmed.org> Message-ID: <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> On Apr 6, 2005, at 18:21, Eric Hellman wrote: > 3. I guess what I don't like about using REL is pretty pedantic: it > seems to me that the role of REL is to assign a role or attribute to > the resource that is being linked to, which is not what we're doing. > We're instructing a processor about how to process the anchor element, > which is not the same thing. REL="cited" for example. Its like a > programmer confusing an object with its pointer. I think that's what I don't like about 'class' and 'title', though whether the specification agrees is another question. 'Class' I see as being a hook for CSS, while 'title' is to describe the title of the linked item, or a short description. Does 'rel' describe the relation of the linked item to the current page (as in 'alternate'), or does it describe the link itself (as in 'nofollow', 'tag', etc)? If the latter is true, then 'rel="z3988"' or even rel="openurl" would make perfect sense. About the uppercase Z: is that allowed in XHTML? alf From eric at openly.com Thu Apr 7 11:09:54 2005 From: eric at openly.com (Eric Hellman) Date: Thu Apr 7 10:09:59 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> Message-ID: At 1:35 AM +0200 4/7/05, Alf Eaton wrote: >On Apr 6, 2005, at 18:21, Eric Hellman wrote: > >>3. I guess what I don't like about using REL is pretty pedantic: it >>seems to me that the role of REL is to assign a role or attribute >>to the resource that is being linked to, which is not what we're >>doing. We're instructing a processor about how to process the >>anchor element, which is not the same thing. REL="cited" for >>example. Its like a programmer confusing an object with its pointer. > >I think that's what I don't like about 'class' and 'title', though >whether the specification agrees is another question. 'Class' I see >as being a hook for CSS, while 'title' is to describe the title of >the linked item, or a short description. I agree about CLASS being a hook for css; an important question is whether we want to give future css access to the z3988 marked elements. TITLE would be clearly a misusage. Time to look at the spec: rel = link-types [CI] This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. class = cdata-list [CS] This attribute assigns a class name or set of class names to an element. Any number of elements may be assigned the same class name or names. Multiple class names must be separated by white space characters. (we've left FORM out of this but CLASS can be applied to FORM as well as other elements, but not REL. this has advantages and disadvantages.) here it would really be helpful for other members of the list to weigh in. After all, the point of the convention is to make sense to a spectrum of potential implementers. Either REL or CLASS make sense. > >Does 'rel' describe the relation of the linked item to the current >page (as in 'alternate'), or does it describe the link itself (as in >'nofollow', 'tag', etc)? If the latter is true, then 'rel="z3988"' >or even rel="openurl" would make perfect sense. I think this depends on spec vs. usage. "nofollow" describes the link, I would say, while the xfn usage describes the relation of the linked item to the current page. tag is a mutant. > >About the uppercase Z: is that allowed in XHTML? XHTML says the token values of rel (and class) are case insensitive. So either way perhaps lowercase z should also be allowed. > >alf -- 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 Fri Apr 8 09:55:41 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Apr 8 09:58:46 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> Message-ID: <42568D5D.10405@library.gatech.edu> Eric Hellman wrote: > I agree about CLASS being a hook for css; an important question is > whether we want to give future css access to the z3988 marked > elements. TITLE would be clearly a misusage. While I'm not sure title is a misusage ("This attribute offers advisory information about the element for which it is set." - which certainly stating "z3988" is advisory information), I'm also not sure I care enough to go to bat for it. I don't think it should be written off completely, though. > Time to look at the spec: > > rel = link-types [CI] > This attribute describes the relationship from the current > document to the anchor specified by the href attribute. The value of > this attribute is a space-separated list of link types. > > class = cdata-list [CS] > This attribute assigns a class name or set of class names to an > element. Any number of elements may be assigned the same class name or > names. Multiple class names must be separated by white space characters. > > (we've left FORM out of this but CLASS can be applied to FORM as well > as other elements, but not REL. this has advantages and disadvantages.) FORM seems a little out of the scope of this proposal, doesn't it? We're talking about adding /extra/ tags, not utilizing those that are already there, right? > here it would really be helpful for other members of the list to weigh > in. After all, the point of the convention is to make sense to a > spectrum of potential implementers. Either REL or CLASS make sense. Or (and not keep beating this drum, but...) use both and let one of these be the opportunity to specify which version of OpenURL is contained in the link. Although that may also be apparent in the OpenURL itself, it seems like it'd be easier to trigger events based on a definitive enumerated list of terms ("1.0", "2004", "0.1", "2.3", etc.) rather than on an OpenURL, which may or may not immediately reflect version information. While I definitely see the advantages of 1.0, I just don't see the point in completely eliminating 0.1 from possibility. Especially if we account for it in our design. Much like RSS has multiple versions of the spec in widespread use, I could see OpenURL doing similarly. My take is: allow for both formats in the tag, specify which it is, and let the "market" determine which is easier to implement. Even looking at the "Idiot's Guide to OpenURL 1.0", I just can't see autodiscovery making much headway in "lay" settings if the format is so... dense. Of course, I would love to be wrong on this, and if I am, then the 0.1 can collect dust and never be seen again. >> >> About the uppercase Z: is that allowed in XHTML? > > > XHTML says the token values of rel (and class) are case insensitive. > So either way perhaps lowercase z should also be allowed. Well, except I'm pretty sure Gecko based browsers (maybe IE, too, I'm not sure) are case sensitive in regards to class. I think a decision would have to be made. -Ross. From eric at openly.com Mon Apr 11 14:31:46 2005 From: eric at openly.com (Eric Hellman) Date: Mon Apr 11 14:32:22 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <42568D5D.10405@library.gatech.edu> References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> <42568D5D.10405@library.gatech.edu> Message-ID: At 9:55 AM -0400 4/8/05, Ross Singer wrote: >Eric Hellman wrote: > >>I agree about CLASS being a hook for css; an important question is >>whether we want to give future css access to the z3988 marked >>elements. TITLE would be clearly a misusage. > >While I'm not sure title is a misusage ("This attribute offers >advisory information about the element for which it is set." - which >certainly stating "z3988" is advisory information), I'm also not >sure I care enough to go to bat for it. I don't think it should be >written off completely, though. some browsers us TITLE attribute to display a "tooltip" when the user hovers on the link, so using TITLE for OpenURL marking would be a conflict. >>here it would really be helpful for other members of the list to >>weigh in. After all, the point of the convention is to make sense >>to a spectrum of potential implementers. Either REL or CLASS make >>sense. > >Or (and not keep beating this drum, but...) use both and let one of >these be the opportunity to specify which version of OpenURL is >contained in the link. Although that may also be apparent in the >OpenURL itself, it seems like it'd be easier to trigger events based >on a definitive enumerated list of terms ("1.0", "2004", "0.1", >"2.3", etc.) rather than on an OpenURL, which may or may not >immediately reflect version information. > >While I definitely see the advantages of 1.0, I just don't see the >point in completely eliminating 0.1 from possibility. Especially if >we account for it in our design. Much like RSS has multiple >versions of the spec in widespread use, I could see OpenURL doing >similarly. the point is to make it easier to implement an activating agent. It has to be easier to implement only one standard than to ask for a standard implementation AND a pseudo-standard implementation. Laziness on the part of implementers is sure to result in corner-cutting if you ask for two implementations, and that in turn will result in confusion on the part of providers that are considering implementation. It will look like a forked convention out of the gate, because providers would have to choose an OpenURL version I can think of no benefit to allowing for 0.1 OpenURL, other than having a somewhat shorter URL, and the cost in terms of implementation complexity is substantial. Of course I have a limited perspective, and there may be benefits that I am not aware of. For the same reason, I think we can be a lot more specific about exactly what type of 1.0 OpenURL should be embedded. It seems reasonable to restrict the OpenURL to "KEV", by-value format (or SAP 1) OpenURL. This will help to address "fear" of the more complex versions present in OpenURL 1.0. There's a big difference with RSS in this situation, because the current deployment of latent OpenURL is practically nil. > >>> >>>About the uppercase Z: is that allowed in XHTML? >> >> >>XHTML says the token values of rel (and class) are case >>insensitive. So either way perhaps lowercase z should also be >>allowed. > >Well, except I'm pretty sure Gecko based browsers (maybe IE, too, >I'm not sure) are case sensitive in regards to class. I think a >decision would have to be made. I guess we need to do some experiments on this -- 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 eric at openly.com Wed Apr 13 17:07:28 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 13 17:07:34 2005 Subject: [gcs-pcs-list] revised latent OpenURL suggestion In-Reply-To: References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> <42568D5D.10405@library.gatech.edu> Message-ID: I've added some revisions to the "Latent OpenURL" document at http://www.openly.com/openurlref/latent.html Open issues are 1. Which attribute of anchor element to use for marking? a. CLASS (my suggestion) b. REL (suggested by Alf Eaton, good arguments both ways) c. TITLE (suggested by Ross Singer, used? in experiment.) It seems everyone else is indifferent. 2. Should embedded 0.1 links be supported? (Decent activating agents will, of course have to support making both 0.1 and 1.0 links out of the embedded ones) My view is NO, but Ross reasonably raises the question. Perhaps his points can be addressed by requiring a very simple form of OpenURL 1.0? 3. Is there need for TYPE or version? I don't understand what the motivation for TYPE is. Versioning seems to be addressed by OpenURL 1.0. 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 From daniel.chudnov at yale.edu Wed Apr 13 19:07:02 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 13 19:07:03 2005 Subject: [gcs-pcs-list] revised latent OpenURL suggestion In-Reply-To: References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> <42568D5D.10405@library.gatech.edu> Message-ID: <20050413230702.GD32688@curtis.med.yale.edu> This is thorny stuff, and there doesn't seem to be a single good answer. Below is a near-rant on why I'm coming down on the side of rel="openurl". Eric Hellman wrote, on Wed, Apr 13, 2005 at 05:07:28PM -0400: > > Open issues are > 1. Which attribute of anchor element to use for marking? > a. CLASS (my suggestion) > b. REL (suggested by Alf Eaton, good arguments both ways) > c. TITLE (suggested by Ross Singer, used? in experiment.) > It seems everyone else is indifferent. I like CLASS because everybody knows about it. I also like CLASS because this use fits the HTML spec definition "For general purpose processing by user agents." I dislike CLASS because its usage, I assume, is overwhelmingly for support of stylesheets, not for general purpose processing by user agents. Stylesheet properties cascade; that styles may be applied to a wide range of elements and their object-ish cascading action means the designation of a particular class value on an arbitrary element will be handled similarly to other elements with the same class value. Also, the domain of possible elements with the class="openurl|z3988" value is far, far greater than the single element we want this pattern to work for: . It therefore seems to me that this will mix up a well-established paradigm for clean stylesheet design with an odd property pattern that doesn't quite fit that paradigm. I also dislike CLASS because we could use a different attribute to solve this problem without preventing you from using class='z3988' in your own particular webapps, and without needing the rest of the world to understand what you mean by that. That fits the dominant paradigm. So, -1 on CLASS for me. I like REL because it's in common use already for "autodiscovery" applications, and even though this doesn't quite feel like autodiscovery yet, I think it's a stepping stone to it. So people who know and love autodiscovery will feel comfortable with it, and those are the very people who will hack the early plugins and such that we need to make this thing scale. I also like REL because it almost fits the HTML spec definition "describes the relationship from the current document to the anchor specified by the href attribute." I say "almost" because as we all want to use it, the document containing these "latent" links might itself have multiple latent links (see citeulike). So, in a way, we really want a particular link to describe a relationship between a current _object_ and an anchor. I doubt this distinction would be lost on many people. I also like REL because it only applies to A and LINK elements. I dislike REL because I don't want to have to require profile references. In the XFN example Alf pointed out they don't seem to say a lot about how "you have to also reference this profile", although they do mention profiles. Mostly they just say "say rel='slept-with' if you slept with that person etc." If we can't do this without really _requiring_ the profile piece to be formally stated by most applications using it, then I'm against REL completely. Otherwise, +1 on REL. I like TITLE because it fits the HTML spec, "offers advisory information about the element for which it is set." But, that's just advisory information, not a formal relationship or class designator. So, it's nice if webapps have a little hover-over thing that highlights to GUI browser users that "this is an OpenURL" or the equivalent for the sightless in screen readers. But I don't think that should be the primary place for our "automated" hacks to reside. -1 on specifying TITLE as the primary designator for OpenURLs. +1 on allowing TITLE as an optional descriptor with the value "OpenURL". I could live with just not mentioning it at all, although there seems to be more value in having an optional recommendation than not. > 2. Should embedded 0.1 links be supported? (Decent activating agents > will, of course have to support making both 0.1 and 1.0 links out of > the embedded ones) My view is NO, but Ross reasonably raises the > question. Perhaps his points can be addressed by requiring a very > simple form of OpenURL 1.0? I think we should avoid this issue completely. If publishers want to produce working openurl links, they should stick to the standard. Resolvers should be liberal in what they accept. We shouldn't force the issue. Hacks/plugins which use the spec we're proposing should only have to look for one thing in one place (or, rather, "one pattern, that might occur multiple times in a single document") and not operate differently according, depending. That'll keep the plugin space simple, and potentially fertiler. Yes, I said fertiler. More fertile. > 3. Is there need for TYPE or version? > I don't understand what the motivation for TYPE is. Versioning seems > to be addressed by OpenURL 1.0. I dislike using TYPE because we're not in a position to add value to descriptions of content type. We don't know what content type people will end up with, that's why we want them to choose from a list of services themselves. The remaining open issue is the recommended value of the attribute, which is separate from which attribute it should be set on. I like "z3988" because that's what it is, and people can (potentially) google it and get exactly what we mean. Right now, they'd get a mushroom slicer first, and Eric's document second. If this took off, goodness-be-with the mushroom slicer vendors. I dislike "z3988" because people won't remember it. If they do remember it, they'll mistype it. Even if they mistype it, they might not notice it because 9s and 8s look somewhat familiar. Overall, -1 on "z3988", but I could live with it if there were a better argument than these. I like "openurl" because that's what it is. People can google it and get exactly what we mean. I also like it because people can remember it and type it correctly. I dislike "openurl" because people might also use it as a tag name on rel attributes for folksonomaniacal reasons, which blurs the hackability distinction. Hmm, but actually this concern also applies to "z3988" or any other possible value in rel. What's the worst case? Somebody uses the tag "openurl" on a flickr post (yeah, right) or a blog or linkblog entry. A greasemonkey userscript sees the "openurl" value on the rel attribute and activates a button and stuff. User clicks button and gets a resolver error screen. Come to think of it, that's why we originally tried "rel='alternate'" _and_ "title='OpenURL'"... the one reinforced the other. But, nobody's voting for that combination. Hmm... I can probably live with that, because among the people who might actually be tagging flickr or linkblog posts with the tag "openurl" most should be smart enough to figure out why they reached an error screen, or at least smart enough to shrug it off and hit their back button. Not a problem for the other 300000+ other possible tags. +1 on [whatever]="openurl". I'm indifferent on also using rel="alternate", as in the suggested example rel="alternate z3988" or rel="alternate ...all of which leaves me with voting for rel="openurl" and an optional suggestion of title='OpenURL'. One thing we haven't addressed is whether there should be a recommended behavior for what actually happens when "latent" openurls are "activated". My gut says "don't specify anything", but it's worth raising explicitly. I told you it would be a near-rant. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Apr 13 19:09:44 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 13 19:09:45 2005 Subject: [gcs-pcs-list] revised latent OpenURL suggestion In-Reply-To: <20050413230702.GD32688@curtis.med.yale.edu> References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> <42568D5D.10405@library.gatech.edu> <20050413230702.GD32688@curtis.med.yale.edu> Message-ID: <20050413230944.GE32688@curtis.med.yale.edu> Daniel Chudnov wrote, on Wed, Apr 13, 2005 at 07:07:02PM -0400: > might not notice it because 9s and 8s look somewhat familiar. ^^^^^^^^ i meant: similar -dchud -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Wed Apr 13 20:06:58 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 13 20:07:03 2005 Subject: [gcs-pcs-list] revised latent OpenURL suggestion In-Reply-To: <20050413230702.GD32688@curtis.med.yale.edu> References: <4252F44E.2030905@hubmed.org> <3969ae1bc42cf3a5ad2f2fae002c841a@hubmed.org> <42568D5D.10405@library.gatech.edu> <20050413230702.GD32688@curtis.med.yale.edu> Message-ID: At 7:07 PM -0400 4/13/05, Daniel Chudnov wrote: >Stylesheet properties cascade; that styles may be applied to a wide range >of elements and their object-ish cascading action means the designation >of a particular class value on an arbitrary element will be handled >similarly to other elements with the same class value. that's a good point against CLASS -- 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 T.Hammond at nature.com Fri Apr 15 13:56:35 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Fri Apr 15 13:56:38 2005 Subject: [gcs-pcs-list] Fwd: [ANN] Social Bookmarking Tools (I & II) - in D-Lib Magazine Message-ID: <125F7834E11A5741A7D79412EE3504F90F26D249@UK1APPS2.mpl.root-domain.org> Hi Guys: You will doubtless all have seen this announcement by now, but am just posting it here for the record. Cheers, Tony ### Hi All: A pair of papers just published today in D-Lib Magazine [1] by Nature Publishing Group (NPG) [2] may be of interest: * Social Bookmarking Tools (I): A General Review [3] * Social Bookmarking Tools (II): A Case Study - Connotea [4] * Editorial - Personalized Information Organization [5] These papers describe the current state of play with respect to the new crop of web-based bookmark managers - tools such as del.icio.us and Flickr are well-known exemplars of the genre. These papers describe how such tools can be specialized as web-based reference managers. Connotea [6] is NPG's own contribution of a reference manager tool for scientists whereby bookmarks can be stored online and tagged with user-supplied labels for easy later retrieval. Citation metadata is also supplied automatically by Connotea for a growing number of online journals and books services. Bookmarked references can be shared with other users and can be publicly commented upon. In fact, whole discussion threads can be built up around individual bookmarked references. (The papers are set up as living examples with their own reference lists available online both for comment and further additions.) Import/export opportunities within Connotea include RSS and RIS - support for other formats is under development. Connotea is a free online reference management and social bookmarking service for scientists created by NPG. While somewhat experimental, Connotea already has a large and growing user base and is a fully functioning service. The label 'experimental' is not meant to imply that the service is any way ephemeral or esoteric, rather that the concept of social bookmarking itself and the application of that concept to reference management are both very recent developments. Connotea is under active development, and we are still in the process of discovering how it can be used to full effect. As well as being a free and public service, the core code to Connotea is freely available under an open source license [7]. Moreover there are two public mailing lists: connotea-discuss [8] which is a public forum for discussion on matters relating to the Connotea service, and connotea-code-devel [9] which is aimed at developers working with the Connotea source code. ### D-Lib Magazine [1] is a solely electronic publication with a primary focus on digital library research and development, including but not limited to new technologies, applications, and contextual social and economic issues. D-Lib Magazine is produced by the Corporation for National Research Initiatives (CNRI), has been sponsored by the Defense Advanced Research Project Agency (DARPA), and is currently being funded by the National Science Foundation (NSF). Nature Publishing Group (NPG) [2] is the scientific publishing arm of Macmillan Publishers Ltd, combining the excellence of Nature, Nature Research Journals, Nature Reviews Journals, NPG Academic Journals and NPG Reference publications, to provide the world's premier information resource for the basic biological and physical sciences. NPG is a global company, with headquarters in London and offices in Paris, Munich, New Delhi, Tokyo, Melbourne, San Diego, San Francisco, Washington, New York and Boston. ### Tony Hammond New Technology, Nature Publishing Group 4 Crinan Street, London N1 9XW, UK tel:+44-20-7843-4659 mailto:t.hammond@nature.com [1] http://www.dlib.org/ [2] http://npg.nature.com/ [3] http://www.dlib.org/dlib/april05/hammond/04hammond.html [4] http://www.dlib.org/dlib/april05/lund/04lund.html [5] http://dlib.org/dlib/april05/04editorial.html [6] http://wwww.connotea.org/ [7] http://connotea.sourceforge.net/ [8] https://lists.sourceforge.net/lists/listinfo/connotea-discuss [9] https://lists.sourceforge.net/lists/listinfo/connotea-code-devel ******************************************************************************** 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 Fri Apr 22 17:42:03 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Apr 22 17:42:07 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: References: Message-ID: <20050422214202.GB20353@curtis.med.yale.edu> Eric Hellman wrote, on Tue, Apr 05, 2005 at 12:14:44PM -0500: > In terms of strategy, it would be good to have May 1 as a goal for > having something final to start publicizing, ...and here it is, 4/22, and we're not much closer to having anything final. Why haven't we gotten anywhere? Is this not as interesting as we first thought? Are we the wrong group of people to "decide", or is this the wrong forum for discussion? Did the discussion end up somewhere else that we don't know about here (i sure don't know that, i'm just asking)? I know there are at least as many well-qualified folks on this list who have yet to weigh in as there are those who have already... consider this a friendly nudzh to speak up. :) Yours in latent anticipation, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Fri Apr 22 18:16:59 2005 From: eric at openly.com (Eric Hellman) Date: Fri Apr 22 18:16:59 2005 Subject: [gcs-pcs-list] latent OpenURL suggestion In-Reply-To: <20050422214202.GB20353@curtis.med.yale.edu> References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: Comment received suggests that REL should be used in place of CLASS, and I will have a revision with that change done this weekend. Excellent, comments have been made- I would not characterize the situation as being "no closer". Quality of discussion is what counts, not quantity. At 5:42 PM -0400 4/22/05, Daniel Chudnov wrote: >Eric Hellman wrote, on Tue, Apr 05, 2005 at 12:14:44PM -0500: >> In terms of strategy, it would be good to have May 1 as a goal for >> having something final to start publicizing, > >...and here it is, 4/22, and we're not much closer to having anything >final. > >Why haven't we gotten anywhere? Is this not as interesting as we first >thought? Are we the wrong group of people to "decide", or is this the >wrong forum for discussion? Did the discussion end up somewhere else >that we don't know about here (i sure don't know that, i'm just asking)? > >I know there are at least as many well-qualified folks on this list who >have yet to weigh in as there are those who have already... consider >this a friendly nudzh to speak up. :) > >Yours in latent anticipation, -Dan > > >-- >Daniel Chudnov >Yale Center for Medical Informatics >(203) 737-5789 -- 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 eric at openly.com Sat Apr 23 23:59:06 2005 From: eric at openly.com (Eric Hellman) Date: Sat Apr 23 23:59:13 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: A revised version of the draft latent OpenURL convention is now available at http://www.openly.com/openurlref/latent.html I consider that none of the commenters so far have been enamored of "CLASS" as the marker attribute, and so I've changed to using "REL". One benefit of making this change is that there's no longer any reason not to use the dot in "Z39.88" which is now a NISO/ANSI standard. I've expanded quite a bit on what activating agents have to do to adjust OpenURL 1.0 for use with 0.1. resolvers, and have made the OpenURL type much more specific. I hope this will address concerns that have been expressed about use of OpenURL 1.0 with version 0.1-only resolvers. Bottom line is we have to support the standard version and allowing 0.1 adds nothing. On "Z39.88" versus "OpenURL" I note that a large fraction of google hits for OpenURL have nothing to do with "Z39.88" and ALL of the "Z39.88" hits are relevant. And reading about XFN makes me really worried about relation-token collisions. It seems to me that to use "OpenURL" as the value of the REL marker attribute is just asking for a conflict (i.e. a bug) to happen and is thus not a good thing. If you have any comments to make, the time to make them is now, because implementation will start very soon. -- 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 alf at hubmed.org Mon Apr 25 18:31:24 2005 From: alf at hubmed.org (Alf Eaton) Date: Mon Apr 25 18:31:31 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: I've put a Greasemonkey userscript online to test this format with: http://alf.hubmed.org/latentopenurl.user.js Two things I found: 1) The base URL of the containing page gets added to the front of the anchor's href attrribute, so that has to be stripped out first. 2) I couldn't find a way to use XPath to definitively select an anchor with a rel attribute of 'Z39.88' out of possible multiple rel attributes. At the moment it uses "//a[contains(@rel,'Z39.88')]" but that doesn't distinguish between 'Z39.88', 'Z39.88b' and 'bigZ39.88elephants'. Checking the whole rel attribute string for indexOf(' Z39.88 ') afterwards was the only way I could think of to avoid this. You can test the userscript here: http://www.hubmed.org/search.cgi?q=grease+monkey and here: http://www.hubmed.org/display.cgi?uids=15343370 alf. On Apr 24, 2005, at 05:59, Eric Hellman wrote: > A revised version of the draft latent OpenURL convention is now > available at > > http://www.openly.com/openurlref/latent.html > > I consider that none of the commenters so far have been enamored of > "CLASS" as the marker attribute, and so I've changed to using "REL". > One benefit of making this change is that there's no longer any reason > not to use the dot in "Z39.88" which is now a NISO/ANSI standard. > > I've expanded quite a bit on what activating agents have to do to > adjust OpenURL 1.0 for use with 0.1. resolvers, and have made the > OpenURL type much more specific. I hope this will address concerns > that have been expressed about use of OpenURL 1.0 with version > 0.1-only resolvers. Bottom line is we have to support the standard > version and allowing 0.1 adds nothing. > > On "Z39.88" versus "OpenURL" I note that a large fraction of google > hits for OpenURL have nothing to do with "Z39.88" and ALL of the > "Z39.88" hits are relevant. And reading about XFN makes me really > worried about relation-token collisions. It seems to me that to use > "OpenURL" as the value of the REL marker attribute is just asking for > a conflict (i.e. a bug) to happen and is thus not a good thing. > > If you have any comments to make, the time to make them is now, > because implementation will start very soon. > > -- > > 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 daniel.chudnov at yale.edu Mon Apr 25 20:49:41 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Apr 25 20:49:46 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: On Apr 23, 2005, at 11:59 PM, Eric Hellman wrote: > > On "Z39.88" versus "OpenURL" I note that a large fraction of google > hits for OpenURL have nothing to do with "Z39.88" and ALL of the > "Z39.88" hits are relevant. And reading about XFN makes me really > worried about relation-token collisions. It seems to me that to use > "OpenURL" as the value of the REL marker attribute is just asking for > a conflict (i.e. a bug) to happen and is thus not a good thing. I can live with this. But, I still prefer "OpenURL". :) > If you have any comments to make, the time to make them is now, > because implementation will start very soon. Eric: you are right to correct me by noting that comments received here so far have been quite thoughtful and helpful... my earlier comment wasn't intended to imply otherwise. I am, however, very concerned that because we have had so few people actively involved in this discussion, and so few implementations tested, that we're in no position to claim that we've reached any kind of consensus. One judgement synthesizing 4-6 opinions -- however well-reasoned -- just isn't enough, imho. (#include "std-request-for-more-comments.h") What if: we actively publicize what we end up with on May 1 and suggest a three month "trial period". During that time we invite as much comment as possible and do our best to engage the Broader Community in testing this thing out. We throw it out to the "real" OpenURL list. We link to a bunch of different implementation tools and working websites on some single page somewhere. And so on. By August 1, hopefully many many folks will have seen the light and we can take off the phrase "trial period" and call it a "Community Recommendation" or somesuch. In the interim, perhaps your page might explicitly invite comments and discussion on this here obscurely-named list. Or elsewhere, should there be a better elsewhere (perhaps the openurl list, if welcome). Also, fyi, our ariadne paper is due out within the week, and I'm hoping we can include an addendum directing readers to the spec, and, at minimum, this list. I'd be much more comfortable not calling it a "formal consensus"... -Dan From daniel.chudnov at yale.edu Mon Apr 25 21:08:33 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Apr 25 21:08:36 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: On Apr 25, 2005, at 6:31 PM, Alf Eaton wrote: > I've put a Greasemonkey userscript online to test this format with: > http://alf.hubmed.org/latentopenurl.user.js Great - I will update the page with the dozen resolvers soon. > Two things I found: > > 1) The base URL of the containing page gets added to the front of the > anchor's href attrribute, so that has to be stripped out first. We probably have to live with this, no? Perhaps the relevant part of the spec should say something like: "To activate Latent OpenURLs... ... 2. a. If the HREF attribute contains a non-preferred resolver base URL to the left of the "?", replace it with the base URL of the desired resolver base URL. b. If the HREF begins with "?", prepend the desired resolver base URL to the left of the "?". c. If the HREF does not contain a "?" (that is, if it contains only the bibliographic component of the OpenURL, and no resolver base URL), prepend the desired resolver base URL, followed by a "?", to the OpenURL metadata. > 2) I couldn't find a way to use XPath to definitively select an anchor > with a rel attribute of 'Z39.88' out of possible multiple rel > attributes. At the moment it uses "//a[contains(@rel,'Z39.88')]" but > that doesn't distinguish between 'Z39.88', 'Z39.88b' and > 'bigZ39.88elephants'. Checking the whole rel attribute string for > indexOf(' Z39.88 ') afterwards was the only way I could think of to > avoid this. Will that miss rel='Z39.88' in the js step?? Could you do rel.split(' ') and look for 'Z39.88' in the resulting array? Sorry if I'm missing your point. -Dan From ross.singer at library.gatech.edu Mon Apr 25 21:41:02 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Apr 25 21:41:04 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> On Mon, April 25, 2005 9:08 pm, Daniel Chudnov said: >> Two things I found: >> >> 1) The base URL of the containing page gets added to the front >> of the >> anchor's href attrribute, so that has to be stripped out first. > > We probably have to live with this, no? Perhaps the relevant part > of > the spec should say something like: > > "To activate Latent OpenURLs... > ... > 2. a. If the HREF attribute contains a non-preferred resolver base > URL > to the left of the "?", replace it with the base URL of the > desired > resolver base URL. > b. If the HREF begins with "?", prepend the desired resolver > base > URL to the left of the "?". > c. If the HREF does not contain a "?" (that is, if it contains > only > the bibliographic component of the OpenURL, and no resolver base > URL), > prepend the desired resolver base URL, followed by a "?", to the > OpenURL metadata. > This is probably browser behavior, although that doesn't really change the reality of this "problem". Whereas I can see why this text would be useful, wouldn't it just be easier to say that the "latent" url is the query string (because it is) and, if the ? is included, is only there as a fully resolving URL? These are /latent/ OpenURLs, after all, so they don't need to include the "?" (unless of course, they are doing double duty, then I think your mileage should vary). > > Will that miss rel='Z39.88' in the js step?? Could you do > rel.split(' > ') and look for 'Z39.88' in the resulting array? > Splitting on a whitespace character seems a little non-authoritative and awfully kludgy (plus unnecessary lines of code)... Is there some attribute that we can use that can't have multiple values? -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 ross.singer at library.gatech.edu Mon Apr 25 22:17:58 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Apr 25 22:17:59 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <33847.208.61.25.190.1114481878.squirrel@mail.library.gatech.edu> While I don't think we should necessarily make a hack of OpenURL 1.0 (or simplified version), is there the possibility for "default" behavior of a Z39.88 OpenURL? I guess what I'm targetting is: rft_val_fmt=info:ofi/fmt:ctx:mtx:journal Is there any part of this that could be "assumed" if it was incomplete? I am not asking this merely for this proposal, but maybe this could be asked of the OpenURL community at large. "No" is a perfectly reasonable answer, but as I look over the rest of the spec (at least in "idiot" form), this is my real hangup for adoption. Eric, can you break down what is really going on with this key, val pair? Is there some "wiggle-room" here? Thanks, -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 eric at openly.com Mon Apr 25 22:35:53 2005 From: eric at openly.com (Eric Hellman) Date: Mon Apr 25 22:35:59 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> References: <20050422214202.GB20353@curtis.med.yale.edu> <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> Message-ID: At 9:41 PM -0400 4/25/05, Ross Singer wrote: >This is probably browser behavior, although that doesn't really >change the reality of this "problem". Whereas I can see why this >text would be useful, wouldn't it just be easier to say that the >"latent" url is the query string (because it is) and, if the ? is >included, is only there as a fully resolving URL? > >These are /latent/ OpenURLs, after all, so they don't need to >include the "?" (unless of course, they are doing double duty, >then I think your mileage should vary). I believe "?" MUST be present, because otherwise the query string in HREF would get messed up by BASE. In other words, software has to interpret (base: "http://example.com/page.html" , href: "title=x" ) and (base: "http://example.com/page.html" , href: "http://example.com/title=x" ) as equivalent. software can't tell if a url is "meant" to do double duty or not. -- 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 eric at openly.com Mon Apr 25 22:54:49 2005 From: eric at openly.com (Eric Hellman) Date: Mon Apr 25 22:54:54 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: <33847.208.61.25.190.1114481878.squirrel@mail.library.gatech.edu> References: <20050422214202.GB20353@curtis.med.yale.edu> <33847.208.61.25.190.1114481878.squirrel@mail.library.gatech.edu> Message-ID: this key-val pair just says that the openurl uses the "journal" metadata set. It also cues the resolver that the referent can be described by journal metadata (as opposed to "book" metadata, for example) it could be omitted if the OpenURL has only identifiers (like doi) and no metadata, but it wouldn't be a good idea. It could be set as a default for latent OpenURLs either by convention or by setting an administrative metatag, but on the whole I'd say that results in a more complicated or at least a biased system. There's wiggle-room, but are we eels? At 10:17 PM -0400 4/25/05, Ross Singer wrote: >While I don't think we should necessarily make a hack of OpenURL >1.0 (or simplified version), is there the possibility for >"default" behavior of a Z39.88 OpenURL? > >I guess what I'm targetting is: >rft_val_fmt=info:ofi/fmt:ctx:mtx:journal > >Is there any part of this that could be "assumed" if it was >incomplete? > >I am not asking this merely for this proposal, but maybe this >could be asked of the OpenURL community at large. > >"No" is a perfectly reasonable answer, but as I look over the rest >of the spec (at least in "idiot" form), this is my real hangup for >adoption. > >Eric, can you break down what is really going on with this key, >val pair? Is there some "wiggle-room" here? > >Thanks, >-Ross. -- 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 alf at hubmed.org Tue Apr 26 01:46:16 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 26 01:46:21 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <38fda6dd65f54153d736a61cae259caf@hubmed.org> On Apr 26, 2005, at 03:08, Daniel Chudnov wrote: > >> Two things I found: >> >> 1) The base URL of the containing page gets added to the front of the >> anchor's href attrribute, so that has to be stripped out first. > > We probably have to live with this, no? Perhaps the relevant part of > the spec should say something like: > > "To activate Latent OpenURLs... > ... > 2. a. If the HREF attribute contains a non-preferred resolver base URL > to the left of the "?", replace it with the base URL of the desired > resolver base URL. > b. If the HREF begins with "?", prepend the desired resolver base > URL to the left of the "?". > c. If the HREF does not contain a "?" (that is, if it contains only > the bibliographic component of the OpenURL, and no resolver base URL), > prepend the desired resolver base URL, followed by a "?", to the > OpenURL metadata. > I actually wasn't really saying this was a problem, just pointing out that it was easy to overlook. I think the proposed spec is perfectly clear on how to deal with this: "To activate Latent OpenURLs in an HTML document, ... 2. Replace the part of the HREF attribute before the "?" with the baseurl of the local link server." As long as there's no question mark in the base URL that's added automatically by the browser (which I don't think there can be, it seems to always strip out query values from the base URL), that's fine. It also allows you to replace existing OpenURL links without any additional code. > >> 2) I couldn't find a way to use XPath to definitively select an >> anchor with a rel attribute of 'Z39.88' out of possible multiple rel >> attributes. At the moment it uses "//a[contains(@rel,'Z39.88')]" but >> that doesn't distinguish between 'Z39.88', 'Z39.88b' and >> 'bigZ39.88elephants'. Checking the whole rel attribute string for >> indexOf(' Z39.88 ') afterwards was the only way I could think of to >> avoid this. > > Will that miss rel='Z39.88' in the js step?? Could you do rel.split(' > ') and look for 'Z39.88' in the resulting array? Again, the way it's working now is fine (and is essentially the same as splitting it into an array and checking each part separately, but with less lines of code). I was just surprised that XPath didn't have a built-in way to test for "one of a space-separated list of attribute values". alf. From alf at hubmed.org Tue Apr 26 01:52:45 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 26 01:52:47 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> References: <20050422214202.GB20353@curtis.med.yale.edu> <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> Message-ID: <8644f77e1faefab534789b47759f6f1c@hubmed.org> On Apr 26, 2005, at 03:41, Ross Singer wrote: >> >> Will that miss rel='Z39.88' in the js step?? Could you do >> rel.split(' >> ') and look for 'Z39.88' in the resulting array? >> > Splitting on a whitespace character seems a little > non-authoritative and awfully kludgy (plus unnecessary lines of > code)... > > Is there some attribute that we can use that can't have multiple > values? It does seem like a bit of a hack to have to do this, but it seems to be the same procedure that any parser using rel attributes wil have to do. I don't think it's a reason to go looking for a different attribute anyway - it's not exactly difficult to check for. There seem to be two alternatives: either var links = document.evaluate("//a[contains(@rel,'Z39.88')]", document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null); var rel = ' ' + e.getAttribute('rel') + ' '; if (rel.indexOf(' Z39.88 ') == -1) continue; or var links = document.evaluate("//a[contains(concat(" ", @rel, " "), " Z39.88 ")]", document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null); I imagine the speed of each will probably be similar. alf. From alf at hubmed.org Tue Apr 26 01:54:20 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 26 01:54:23 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> <33805.208.61.25.190.1114479662.squirrel@mail.library.gatech.edu> Message-ID: <64443b291281d3d46846be38d8973062@hubmed.org> On Apr 26, 2005, at 04:35, Eric Hellman wrote: > At 9:41 PM -0400 4/25/05, Ross Singer wrote: >> This is probably browser behavior, although that doesn't really >> change the reality of this "problem". Whereas I can see why this >> text would be useful, wouldn't it just be easier to say that the >> "latent" url is the query string (because it is) and, if the ? is >> included, is only there as a fully resolving URL? >> >> These are /latent/ OpenURLs, after all, so they don't need to >> include the "?" (unless of course, they are doing double duty, >> then I think your mileage should vary). > > I believe "?" MUST be present, because otherwise the query string in > HREF would get messed up by BASE. I agree. It would be impossible to figure out where BASE ended and HREF began otherwise. alf. From alf at hubmed.org Tue Apr 26 12:31:14 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Apr 26 12:31:19 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <6faaeab420b57d2bbc7847e074984ee0@hubmed.org> I just realised that I left http://www.openly.com* out of the list of sites for which the Greasemonkey script would be enabled. There's a new version at the same address, which will now also work on this page: http://www.openly.com/openurlref/latent.html alf. On Apr 26, 2005, at 00:31, Alf Eaton wrote: > I've put a Greasemonkey userscript online to test this format with: > http://alf.hubmed.org/latentopenurl.user.js > > Two things I found: > > 1) The base URL of the containing page gets added to the front of the > anchor's href attrribute, so that has to be stripped out first. > > 2) I couldn't find a way to use XPath to definitively select an anchor > with a rel attribute of 'Z39.88' out of possible multiple rel > attributes. At the moment it uses "//a[contains(@rel,'Z39.88')]" but > that doesn't distinguish between 'Z39.88', 'Z39.88b' and > 'bigZ39.88elephants'. Checking the whole rel attribute string for > indexOf(' Z39.88 ') afterwards was the only way I could think of to > avoid this. > > You can test the userscript here: > http://www.hubmed.org/search.cgi?q=grease+monkey > and here: > http://www.hubmed.org/display.cgi?uids=15343370 > > alf. From yee at uclink.berkeley.edu Tue Apr 26 19:58:25 2005 From: yee at uclink.berkeley.edu (Raymond Yee) Date: Wed Apr 27 00:55:28 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <426ED5A1.9070403@uclink.berkeley.edu> Hi everyone, Dan C. encouraged us to chime in with our thoughts about the proposal. I'm one of the folks who has been following the discussion at a distance. I've been happy to implement a previous incarnation of the latent OpenURL idea, and will implement in our context whatever we can agree on given the following conditions: * the proprosal has been given a good amount of thought by knowledgeable people * we are proceeding on the basis that proposal is possibly flawed but that we are willing to work with that It seems to me that both conditions are true, and therefore in my mind, the proposal as it stands looks good enough to move ahead with. Caveat: I've not looked as deeply into the issues as many others have, but I trust the fine work that has already been done. Thanks to you all for your hard work. -Raymond Eric Hellman wrote: > A revised version of the draft latent OpenURL convention is now > available at > > http://www.openly.com/openurlref/latent.html > > I consider that none of the commenters so far have been enamored of > "CLASS" as the marker attribute, and so I've changed to using "REL". > One benefit of making this change is that there's no longer any reason > not to use the dot in "Z39.88" which is now a NISO/ANSI standard. > > I've expanded quite a bit on what activating agents have to do to > adjust OpenURL 1.0 for use with 0.1. resolvers, and have made the > OpenURL type much more specific. I hope this will address concerns > that have been expressed about use of OpenURL 1.0 with version > 0.1-only resolvers. Bottom line is we have to support the standard > version and allowing 0.1 adds nothing. > > On "Z39.88" versus "OpenURL" I note that a large fraction of google > hits for OpenURL have nothing to do with "Z39.88" and ALL of the > "Z39.88" hits are relevant. And reading about XFN makes me really > worried about relation-token collisions. It seems to me that to use > "OpenURL" as the value of the REL marker attribute is just asking for > a conflict (i.e. a bug) to happen and is thus not a good thing. > > If you have any comments to make, the time to make them is now, > because implementation will start very soon. > -- -- 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) From eric at openly.com Wed Apr 27 01:39:50 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 27 01:39:55 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: At 8:49 PM -0400 4/25/05, Daniel Chudnov wrote: >What if: we actively publicize what we end up with on May 1 and >suggest a three month "trial period". During that time we invite as >much comment as possible and do our best to engage the Broader >Community in testing this thing out. We throw it out to the "real" >OpenURL list. We link to a bunch of different implementation tools >and working websites on some single page somewhere. And so on. Sounds good. Except you know how "3 month trial" periods go. nobody does anything until 2 weeks before the deadline. If it takes longer than two weeks to do meaningful tests, then it's too complicated. so I vote for a shorter trial, perhaps 1 month. That also leaves you time to have a second trial period, or a third if needed. >By August 1, hopefully many many folks will have seen the light and >we can take off the >phrase "trial period" and call it a "Community Recommendation" or somesuch. I like "Convention". Then you can have people "sign" the convention. >In the interim, perhaps your page might explicitly invite comments >and discussion on this here obscurely-named list. Or elsewhere, >should there be a better elsewhere (perhaps the openurl list, if >welcome). The best way to get comments is to directly ask specific people that you know for comment > >Also, fyi, our ariadne paper is due out within the week, and I'm >hoping we can include an addendum directing readers to the spec, >and, at minimum, this list. I'd be much more comfortable not >calling it a "formal consensus"... right -- 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 eric at openly.com Wed Apr 27 17:25:06 2005 From: eric at openly.com (Eric Hellman) Date: Wed Apr 27 17:25:16 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: The web page at http://nsr.mij.mrs.org/refs/jjap/1995/34-L797.html (as well as a couple hundred others on this website) is available for testing activation of embedded latent OpenURLs according to the most recent draft. Also, please note that I have corrected an error in the values for "rft_val_fmt" in the page at http://www.openly.com/openurlref/latent.html I am sooo embarrassed. -- 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 eric at openly.com Thu Apr 28 11:29:32 2005 From: eric at openly.com (Eric Hellman) Date: Thu Apr 28 11:29:38 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: <6C9F6C68AE8E314787E0BACA539F97DF043EB06D@severin.cursci.co.uk> References: <6C9F6C68AE8E314787E0BACA539F97DF043EB06D@severin.cursci.co.uk> Message-ID: forwarded with Matthew's permission, At 1:25 PM +0100 4/28/05, Matthew Cockerill wrote: >Eric, > >Thanks for including me on this. >Certainly, it looks like a potentially useful proposal which could simplify >deployment of dynamically configurable OpenURL links, by making it so that >they can even be included on static pages. > >The issue of the partial links appearing to unintelligent robots as relative >links is a bit of an irritation. >We really need some sort of web equivalant of /dev/null/ >So then you could embed the latent links in the form: > >HREF="http://www.dev.null?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:m >tx:journal&rft.issn=1045-4438"> > >and the null host would then be replaced by the real host - but spiders >would know to ignore the real host. > >I guess a workaround for that might be to use a non-existent protocol: > >HREF="openurl:?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal& >rft.issn=1045-4438"> > >which could then be resolved into an appropritate http: link. > >But in fact, what prevents Z39.88 from being a URI scheme? > >That would fit with Z39.50, which is: >http://www.iana.org/assignments/uri-schemes > >Are the political obstacles to getting openurl accepted as a URI scheme >horrendous/insurmountable. >And failing a top level URI scheme, what about within the info URL scheme: >http://info-uri.info/registry/docs/misc/faq.html#why_create > > >Would that not solve the problem most elegantly. > >(The system could still work otherwise as you describe) > > >On a separate note: >It would also be good to see some specific coded examples of the different >mechanisms by which the resolution of the latent URLs to real URLs could be >implemented. > >e.g. what might client side javascript look like to achieve this? >what sort of Firefox plugin might do the job? > > >Last comment: > >It's good to see nice straightforward pages like this: >http://www.openly.com/1cate/ig.html > >which really tell implementors the practical information they need to get >started in a comprehensible way. > >As I've mentioned before though, it's a shame that a Google search on >OpenURL still produces such a jungle of committees and standards documents, >though, as opposed to a good top level starting point. e.g. the top hit for >a search on OpenURL is the page entitled: >NISO Committee AX (not clear what that means, even - why AX?) >And it really seems like it serves more of a purpose for committee members, >than for the world at large who need to know what OpenURL actually is. > >Matt -- 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 eric at openly.com Thu Apr 28 19:15:42 2005 From: eric at openly.com (Eric Hellman) Date: Thu Apr 28 19:15:47 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: References: <6C9F6C68AE8E314787E0BACA539F97DF043EB06D@severin.cursci.co.uk> Message-ID: comments on Matthew's comments 1. "example.com" and "example.org" are reserved by dns for use as dummy domain names. If an implementer is concerned about phantom hits from stupid indexing robots, they can use a dummy base url using these domains. 2. for the purposes of activating and embedding latent OpenURLs, it doesn't matter what's on the left side of the question mark. openurl: , info:*, and the like might be useful, but I don't think it's useful to say anything about it right now. At 1:25 PM +0100 4/28/05, Matthew Cockerill wrote: >Eric, > >Thanks for including me on this. >Certainly, it looks like a potentially useful proposal which could simplify >deployment of dynamically configurable OpenURL links, by making it so that >they can even be included on static pages. > >The issue of the partial links appearing to unintelligent robots as relative >links is a bit of an irritation. >We really need some sort of web equivalant of /dev/null/ >So then you could embed the latent links in the form: > >HREF="http://www.dev.null?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:m >tx:journal&rft.issn=1045-4438"> > >and the null host would then be replaced by the real host - but spiders >would know to ignore the real host. > >I guess a workaround for that might be to use a non-existent protocol: > >HREF="openurl:?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal& >rft.issn=1045-4438"> > >which could then be resolved into an appropritate http: link. > >But in fact, what prevents Z39.88 from being a URI scheme? > >That would fit with Z39.50, which is: >http://www.iana.org/assignments/uri-schemes > >Are the political obstacles to getting openurl accepted as a URI scheme >horrendous/insurmountable. >And failing a top level URI scheme, what about within the info URL scheme: >http://info-uri.info/registry/docs/misc/faq.html#why_create > > >Would that not solve the problem most elegantly. > >(The system could still work otherwise as you describe) > > >On a separate note: >It would also be good to see some specific coded examples of the different >mechanisms by which the resolution of the latent URLs to real URLs could be >implemented. > >e.g. what might client side javascript look like to achieve this? >what sort of Firefox plugin might do the job? > > >Last comment: > >It's good to see nice straightforward pages like this: >http://www.openly.com/1cate/ig.html > >which really tell implementors the practical information they need to get >started in a comprehensible way. > >As I've mentioned before though, it's a shame that a Google search on >OpenURL still produces such a jungle of committees and standards documents, >though, as opposed to a good top level starting point. e.g. the top hit for >a search on OpenURL is the page entitled: >NISO Committee AX (not clear what that means, even - why AX?) >And it really seems like it serves more of a purpose for committee members, >than for the world at large who need to know what OpenURL actually is. > >Matt -- 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 -- 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 alf at hubmed.org Thu Apr 28 19:25:40 2005 From: alf at hubmed.org (Alf Eaton) Date: Thu Apr 28 19:25:47 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: References: <6C9F6C68AE8E314787E0BACA539F97DF043EB06D@severin.cursci.co.uk> Message-ID: <72f1b6ad61951dd63b016cbc4a508db3@hubmed.org> What about putting a '#' at the beginning of the latent link (or instead of the '?' perhaps?). Then at least it would only point to a non-existent anchor in its containg page, which spiders shouldn't follow. alf. On Apr 29, 2005, at 01:15, Eric Hellman wrote: > comments on Matthew's comments > > 1. "example.com" and "example.org" are reserved by dns for use as > dummy domain names. If an implementer is concerned about phantom hits > from stupid indexing robots, they can use a dummy base url using these > domains. > > 2. for the purposes of activating and embedding latent OpenURLs, it > doesn't matter what's on the left side of the question mark. openurl: > , info:*, and the like might be useful, but I don't think it's useful > to say anything about it right now. > > > > > At 1:25 PM +0100 4/28/05, Matthew Cockerill wrote: >> Eric, >> >> Thanks for including me on this. >> Certainly, it looks like a potentially useful proposal which could >> simplify >> deployment of dynamically configurable OpenURL links, by making it so >> that >> they can even be included on static pages. >> >> The issue of the partial links appearing to unintelligent robots as >> relative >> links is a bit of an irritation. >> We really need some sort of web equivalant of /dev/null/ >> So then you could embed the latent links in the form: >> >> > HREF="http://www.dev.null?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/ >> fmt:kev:m >> tx:journal&rft.issn=1045-4438"> >> >> and the null host would then be replaced by the real host - but >> spiders >> would know to ignore the real host. >> >> I guess a workaround for that might be to use a non-existent protocol: >> >> > HREF="openurl:?url_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx: >> journal& >> rft.issn=1045-4438"> >> >> which could then be resolved into an appropritate http: link. >> >> But in fact, what prevents Z39.88 from being a URI scheme? >> >> That would fit with Z39.50, which is: >> http://www.iana.org/assignments/uri-schemes >> >> Are the political obstacles to getting openurl accepted as a URI >> scheme >> horrendous/insurmountable. >> And failing a top level URI scheme, what about within the info URL >> scheme: >> http://info-uri.info/registry/docs/misc/faq.html#why_create >> >> >> Would that not solve the problem most elegantly. >> >> (The system could still work otherwise as you describe) >> >> >> On a separate note: >> It would also be good to see some specific coded examples of the >> different >> mechanisms by which the resolution of the latent URLs to real URLs >> could be >> implemented. >> >> e.g. what might client side javascript look like to achieve this? >> what sort of Firefox plugin might do the job? >> >> >> Last comment: >> >> It's good to see nice straightforward pages like this: >> http://www.openly.com/1cate/ig.html >> >> which really tell implementors the practical information they need to >> get >> started in a comprehensible way. >> >> As I've mentioned before though, it's a shame that a Google search on >> OpenURL still produces such a jungle of committees and standards >> documents, >> though, as opposed to a good top level starting point. e.g. the top >> hit for >> a search on OpenURL is the page entitled: >> NISO Committee AX (not clear what that means, even - why AX?) >> And it really seems like it serves more of a purpose for committee >> members, >> than for the world at large who need to know what OpenURL actually is. >> >> Matt > > > -- > > 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 > > > -- > > 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 Thu Apr 28 20:26:44 2005 From: eric at openly.com (Eric Hellman) Date: Thu Apr 28 20:26:49 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs Message-ID: >What about putting a '#' at the beginning of the latent link (or >instead of the '?' perhaps?). Then at least it would only point to a >non-existent anchor in its containg page, which spiders shouldn't >follow. > >alf. 1. we really need the "?" 2. href="#?url_ver=Z39.88-2004..." would fail xhtml validation, if href is typed as URI in an xhtml schema, I think. -- 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 Thu Apr 28 23:21:34 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Apr 28 23:21:36 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs Message-ID: <1524.208.61.25.190.1114744894.squirrel@mail.library.gatech.edu> On Thu, April 28, 2005 8:26 pm, Eric Hellman said: >>What about putting a '#' at the beginning of the latent link (or instead of the '?' perhaps?). Then at least it would only point >> to a >>non-existent anchor in its containg page, which spiders shouldn't follow. >> >>alf. > > 1. we really need the "?" > > 2. href="#?url_ver=Z39.88-2004..." would fail xhtml validation, if > href is typed as URI in an xhtml schema, I think. Plus, if you think about it, this is inherently inaccurate. If # points to an internal anchor, this is just plain wrong. I'm still not entirely sure where the problem with the "?" is: 1) If it is not present (I realize this is not popular), it's obviously an OpenURL (if you have anchor text with this, it's your own damn fault, I'd say) 2) If the "?" is present, get the query string of the URL. There are plenty of conditionals already in this proposal, checking for the query string isn't that much more overhead. I don't have a strong opinion one way or the other, but it scenario #2 seems easy enough to work with. -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 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 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 T.Hammond at nature.com Fri Apr 29 05:03:20 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Fri Apr 29 05:03:29 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs Message-ID: <125F7834E11A5741A7D79412EE3504F90F26D2CF@UK1APPS2.mpl.root-domain.org> Hi: Must confess I haven't been following this argument too closely, but would agree with Eric that if there is a relative URI to be embedded then href="?url_ver=Z39.88-2004..." would surely be the cleanest/simplest way to go. (I also endorse the use of 'example.*' as Eric mentions for any example URI structures.) I do not think putting 'openurl:' (yet another URI wannabe - Lord knows we have have enough of them), or 'info:' (which is for registered namespaces only) on the LHS would be practicable solutions. Cheers, Tony > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Eric Hellman > Sent: 29 April 2005 01:27 > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] RE: Latent OpenURLs > > > >What about putting a '#' at the beginning of the latent link (or > >instead of the '?' perhaps?). Then at least it would only point to a > >non-existent anchor in its containg page, which spiders shouldn't > >follow. > > > >alf. > > 1. we really need the "?" > > 2. href="#?url_ver=Z39.88-2004..." would fail xhtml validation, if > href is typed as URI in an xhtml schema, I think. > -- > > 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 > ******************************************************************************** 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 alf at hubmed.org Fri Apr 29 05:11:14 2005 From: alf at hubmed.org (Alf Eaton) Date: Fri Apr 29 05:11:30 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: <125F7834E11A5741A7D79412EE3504F90F26D2CF@UK1APPS2.mpl.root-domain.org> References: <125F7834E11A5741A7D79412EE3504F90F26D2CF@UK1APPS2.mpl.root-domain.org> Message-ID: <2675848ea608ca064ba1e4ee3bcf16c7@hubmed.org> I think the point is that it's not a relative URI, it's a remote link, but the way that's embedded at the moment makes it seem relative. Eric, could you explain why "we really need the "?"" ? alf. On Apr 29, 2005, at 11:03, Hammond, Tony wrote: > Hi: > > Must confess I haven't been following this argument too closely, but > would > agree with Eric that if there is a relative URI to be embedded then > > href="?url_ver=Z39.88-2004..." > > would surely be the cleanest/simplest way to go. > > (I also endorse the use of 'example.*' as Eric mentions for any > example URI > structures.) > > I do not think putting 'openurl:' (yet another URI wannabe - Lord > knows we > have have enough of them), or 'info:' (which is for registered > namespaces > only) on the LHS would be practicable solutions. > > Cheers, > > Tony > > > >> -----Original Message----- >> From: gcs-pcs-list-bounces@cipolo.med.yale.edu >> [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf >> Of Eric Hellman >> Sent: 29 April 2005 01:27 >> To: gcs-pcs-list@cipolo.med.yale.edu >> Subject: Re: [gcs-pcs-list] RE: Latent OpenURLs >> >> >>> What about putting a '#' at the beginning of the latent link (or >>> instead of the '?' perhaps?). Then at least it would only point to a >>> non-existent anchor in its containg page, which spiders shouldn't >>> follow. >>> >>> alf. >> >> 1. we really need the "?" >> >> 2. href="#?url_ver=Z39.88-2004..." would fail xhtml validation, if >> href is typed as URI in an xhtml schema, I think. >> -- >> >> 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 >> > > *********************************************************************** > ********* > 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 > *********************************************************************** > ********* > _______________________________________________ > 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 Apr 29 15:10:10 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Apr 29 15:10:12 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: References: <20050422214202.GB20353@curtis.med.yale.edu> Message-ID: <20050429191010.GD4791@curtis.med.yale.edu> Alf Eaton wrote, on Tue, Apr 26, 2005 at 12:31:24AM +0200: > I've put a Greasemonkey userscript online to test this format with: > http://alf.hubmed.org/latentopenurl.user.js Alf et al.: the "resolvable" page now has greasemonkey scripts for the dozen resolvers long-since listed there. http://curtis.med.yale.edu/dchud/resolvable/ These are nearly exactly like Alf's example, save for the replaced values appropriate to each resolver, and, running in fx-1.0.3 on linux, I got repeated "invalid return" errors at the "if (!links) return;" step. Ross suggested switching to: if (links) { [[everything else]] } ...which works. The canary site seems to be working fine also. I haven't tested on any other platform. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Apr 29 18:44:26 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Apr 29 18:44:28 2005 Subject: [gcs-pcs-list] new article: "Opening up OpenURLs with Autodiscovery" Message-ID: <20050429224425.GI4791@curtis.med.yale.edu> All- The aforementioned article on our beloved topic is now available in Ariadne 43: Opening up OpenURLs with Autodiscovery Daniel Chudnov, Richard Cameron, Jeremy Frumkin, Ross Singer and Raymond Yee demonstrate a 'gather locally, share globally' approach to OpenURLs and metadata autodiscovery in scholarly and non-scholarly environments. http://www.ariadne.ac.uk/issue43/chudnov/ Fyi, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Fri Apr 29 23:18:39 2005 From: eric at openly.com (Eric Hellman) Date: Fri Apr 29 23:18:44 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: <2675848ea608ca064ba1e4ee3bcf16c7@hubmed.org> References: <125F7834E11A5741A7D79412EE3504F90F26D2CF@UK1APPS2.mpl.root-domain.org> <2675848ea608ca064ba1e4ee3bcf16c7@hubmed.org> Message-ID: At 11:11 AM +0200 4/29/05, Alf Eaton wrote: >I think the point is that it's not a relative URI, it's a remote >link, but the way that's embedded at the moment makes it seem >relative. > >Eric, could you explain why "we really need the "?"" ? > >alf. Here's one example of a situation where "?" is needed. I'm sure its not the only one. Suppose there is an agent operating on the HTML in between the publisher and the activating agent. For example, consider the case where the activating agent is a firefox plugin, but the web page is being accessed through a rewriting proxy server. The rewriting proxy server, seeing the anchor tag with the latent OpenURL, will interpret href according to BASE, and may insert an explicit baseURL pointing to the proxy. Without "?", the OpenURL gets corrupted; with "?" everything still works. -- 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 Sat Apr 30 00:35:03 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sat Apr 30 00:35:06 2005 Subject: [gcs-pcs-list] RE: Latent OpenURLs In-Reply-To: References: <125F7834E11A5741A7D79412EE3504F90F26D2CF@UK1APPS2.mpl.root-domain.org> <2675848ea608ca064ba1e4ee3bcf16c7@hubmed.org> Message-ID: <34363.208.61.25.190.1114835703.squirrel@mail.library.gatech.edu> Eric, This is an excellent point. You're right that there are doubtlessly more, but this is an example that would be so commonplace as to make our proposal useless. It's also something that would never have crossed my mind. Thanks, -Ross. On Fri, April 29, 2005 11:18 pm, Eric Hellman said: > At 11:11 AM +0200 4/29/05, Alf Eaton wrote: >>I think the point is that it's not a relative URI, it's a remote >>link, but the way that's embedded at the moment makes it seem >>relative. >> >>Eric, could you explain why "we really need the "?"" ? >> >>alf. > > Here's one example of a situation where "?" is needed. I'm sure > its > not the only one. > > Suppose there is an agent operating on the HTML in between the > publisher and the activating agent. For example, consider the case > where the activating agent is a firefox plugin, but the web page > is > being accessed through a rewriting proxy server. > > The rewriting proxy server, seeing the anchor tag with the latent > OpenURL, will interpret href according to BASE, and may insert an > explicit baseURL pointing to the proxy. > > Without "?", the OpenURL gets corrupted; with "?" everything still > works. > > > -- > > 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 > > ---------------------------------------------------------------------- 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 Sat Apr 30 07:55:15 2005 From: alf at hubmed.org (Alf Eaton) Date: Sat Apr 30 07:55:23 2005 Subject: [gcs-pcs-list] revised latent OpenURL draft In-Reply-To: <20050429191010.GD4791@curtis.med.yale.edu> References: <20050422214202.GB20353@curtis.med.yale.edu> <20050429191010.GD4791@curtis.med.yale.edu> Message-ID: On Apr 29, 2005, at 21:10, Daniel Chudnov wrote: > running in fx-1.0.3 on linux, I > got repeated "invalid return" errors at the "if (!links) return;" step. > Ross suggested switching to: > > if (links) { > [[everything else]] > } > You're probably running an older version of Greasemonkey. If you get the 0.3b version it shouldn't give this error. alf.