From daniel.chudnov at yale.edu Wed Jul 6 17:09:31 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jul 6 17:11:10 2005 Subject: [gcs-pcs-list] on the span version Message-ID: <20050706210930.GG24159@curtis.med.yale.edu> At the risk of continuing discussion... I've said before that since there's no obviously preferable solution, I'll go along with whatever consensus arises, should there be one. That said, I think there are several things wrong with this spec. 0. We are mainly trying to make it easy to identify objects, so it should say that. 1. It's too jargony. Few outside of our community will implement it. 2. It mixes the "how to publish openurls in html" bit with the "how to process correctly published openurls" bit. This confuses things. 3. It's a mistake to remove the properly-published-openurl bit in an "activated" openurl. I think this also means that "latent" isn't the right term. As for (1) above, I've said before [*] that I prefer anchors with @rel='openurl', and stick by that preference due to its simplicity, modulo the willingness to go along with something else. :) What I want is for this to be relevant to All Publishers, especially publishers already publishing openurls, to whom we could (upon spec completion) say "you will publish your OpenURLs this way" in our licenses, rather than saying nothing and allowing anything, which is what we do now. To accomplish that, this document needs sell this interpretation of the problem and its agreed-upon solution to the people who work out contracts with publishers. Which hits the "too jargony" issue again, as those folks typically wouldn't understand this document. If nothing else I'd prefer to see a clear division between sections: "for everyone: what is this for?", "for publishers: how to publish OpenURLs in HTML", and "for developers: how to process OpenURLs in HTML published according to this spec." Separately we could provide a "detailed discussion" that goes on about "how this is really about ContextObjects" at great length. For that "how to process" bit: we should not assume the sole use case we all know too well, of jumping from a link to a resolver screen. In the current spec, this alternate use case fails: - Somebody at some university saves a lot of web pages with "activated" links, maybe using "scrapbook" or "slogger" or a "researchers' box" or somesuch. The saved pages work great until they take a new contract at a different university. Then all the activated links still point to their old institutional resolver and there's no "latent" stub to re-configure in place. And, the previous institution's resolver doesn't even republish the ContextObject/openurl itself using our spec, so they can't just reroute it to their current institution that way, either. :P So, rather than adding to misinterpretations of "idempotent", I'd suggest that we recommend that those processing/activating identified contextobjects should: - leave the original span/whatever stubs in place, and - append your processor's output (i.e. don't overwrite another processor's separate output) The first line fits the broken use case better, and also allows for different UI paradigms, like little XUL icons popping up elsewhere on the screen completely outside of an html stream, for instance. The latter bit allows for multiple parallel or chained processing steps while preserving the initial hook for deferred (i.e. "much later") processing. It also means the "latent" vs. "activated" dichotomy isn't quite so central, so maybe we should just call it "publishing OpenURLs in HTML 4.01/XHTML 1.0" and also say something like "this might all be easier someday in XHTML 2.0." (Hmm, maybe this is also an argument for span over anchors... you can stuff several anchors inside a span, right? ...goes to spec... wait, no you can't, both A and SPAN are inline elements that don't allow much of a content model, we want something that's a block element. Indeed, putting As inside of SPANs is invalid. [**] Is that correct? So, maybe div? Sigh...) I'll offer to draft/rewrite the separate sections/docs described above should anyone think it worthwhile. Or, if enough people say "enough is enough, and this is enough", I'll go along with what's there so we can all go work on other stuff. I haven't heard enough of *that*, yet. -Dan [*] http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2005-April/000055.html [**] http://www.w3.org/TR/html4/struct/global.html#edef-SPAN -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Wed Jul 6 17:44:10 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 6 17:44:16 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <20050706210930.GG24159@curtis.med.yale.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> Message-ID: At 5:09 PM -0400 7/6/05, Daniel Chudnov wrote: >(Hmm, maybe this is also an argument for span over anchors... you can >stuff several anchors inside a span, right? ...goes to spec... wait, >no you can't, both A and SPAN are inline elements that don't allow >much of a content model, we want something that's a block element. >Indeed, putting As inside of SPANs is invalid. [**] Is that correct? >So, maybe div? Sigh...) SPAN and A have slightly different content models. A may not be nested; SPAN may be nested. SPAN may contain A, A may contain SPAN. We DON'T want a block element be cause we want to be able to put it inside inline elements. -- 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 Jul 6 17:59:26 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 6 17:59:33 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <20050706210930.GG24159@curtis.med.yale.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> Message-ID: At 5:09 PM -0400 7/6/05, Daniel Chudnov wrote: >So, rather than adding to misinterpretations of "idempotent", I'd suggest >that we recommend that those processing/activating identified contextobjects >should: > > - leave the original span/whatever stubs in place, and > - append your processor's output (i.e. don't overwrite another > processor's separate output) > >The first line fits the broken use case better, and also allows for >different UI paradigms, like little XUL icons popping up elsewhere on >the screen completely outside of an html stream, for instance. This is an excellent point, and as you note, it is not possible to "leave the original stub in place" using A, while it is simple using SPAN. If there is content in the element, I'm not so sure that leaving it in is always the right thing to do. replacing it is certainly the easiest thing to do; I certainly can't just leave it unchanged. Having worked with this for almost 2 months, now, I'm finding enough instances of SPAN working better than A, that despite my initial dislike for using SPAN (and the slightly unsemantic use of class and title), I'm forced to conclude that the SPAN version is going to be better. I will take your comments and see what I can do to de-jargon and genarally improve the document. -- 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 Jul 7 00:40:02 2005 From: eric at openly.com (Eric Hellman) Date: Thu Jul 7 00:41:59 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <20050706210930.GG24159@curtis.med.yale.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> Message-ID: I've revised the document at http://www.openly.com/openurlref/latent.html I have labelled the new version as "FINAL CALL". While far from perfect, I think it's "good enough", so please everybody speak now or forever hold your peace. comments interspersed At 5:09 PM -0400 7/6/05, Daniel Chudnov wrote: >0. We are mainly trying to make it easy to identify objects, so it > should say that. added introductory text to orient newcomers. It now says what the goal is. > >1. It's too jargony. Few outside of our community will implement it. can't argue there. unfortunately we're stuck with NISO-openurl jargon. if there are any bits where you think I can further de-jargonify the document without breaking from the standard, I would welcome the assistance. I think that not using the NISO standard would be politically very troublesome within the community and it won't fly outside at all if it doesn't fly inside. > >2. It mixes the "how to publish openurls in html" bit with the > "how to process correctly published openurls" bit. This confuses > things. you are correct. I have made these two things into separate sections. It's really only the first part that is a spec. > >3. It's a mistake to remove the properly-published-openurl bit > in an "activated" openurl. I think this also means that "latent" > isn't the right term. I have changed the recommendation on activation so that it is recommended to retain the span element with embedded metadata. This is subject to it not causing implementation difficulties of course. I think the recommendation to replace the content of the span element is correct. anything the publisher wants not to be replaced can be put outside the span; otherwise there is no way for the publisher to provide content that SHOULD be replaced in an OpenURL Activation. Of course "latent" isn't exactly the right term, but it's the very best and least wrong of all the wrong terms. > > >As for (1) above, I've said before [*] that I prefer anchors with >@rel='openurl', and stick by that preference due to its simplicity, >modulo the willingness to go along with something else. :) based on problems and feedback, this may be most elegant, but it is not the simplest when considered along with the implementation milieu. > >What I want is for this to be relevant to All Publishers, especially >publishers already publishing openurls, to whom we could (upon spec >completion) say "you will publish your OpenURLs this way" in our licenses, >rather than saying nothing and allowing anything, which is what we do now. >To accomplish that, this document needs sell this interpretation of >the problem and its agreed-upon solution to the people who work out >contracts with publishers. Which hits the "too jargony" issue again, >as those folks typically wouldn't understand this document. Once the ball gets rolling, it will become relevant to All Publishers; the key is to get the ball rolling. "Publishers" skip over and don't care about the parts they don't understand, the key is to give them a piece that they can understand. > >If nothing else I'd prefer to see a clear division between sections: >"for everyone: what is this for?", "for publishers: how to publish >OpenURLs in HTML", and "for developers: how to process OpenURLs in >HTML published according to this spec." Separately we could provide >a "detailed discussion" that goes on about "how this is really about >ContextObjects" at great length. I've moved the document in this direction- you can judge whether I've succeeded. > >For that "how to process" bit: we should not assume the sole use case >we all know too well, of jumping from a link to a resolver screen. you are correct, and I have tried to remove this assumption form the document. >In the current spec, this alternate use case fails: > > - Somebody at some university saves a lot of web pages with "activated" > links, maybe using "scrapbook" or "slogger" or a "researchers' box" > or somesuch. The saved pages work great until they take a new contract > at a different university. Then all the activated links still point > to their old institutional resolver and there's no "latent" stub to > re-configure in place. And, the previous institution's resolver doesn't > even republish the ContextObject/openurl itself using our spec, so they > can't just reroute it to their current institution that way, either. :P I believe this is fixed. I have indicated in another message that it can't be fixed with the A version of the proposal. > >So, rather than adding to misinterpretations of "idempotent", I'd suggest >that we recommend that those processing/activating identified contextobjects >should: > > - leave the original span/whatever stubs in place, and yes, this is fixed. > - append your processor's output (i.e. don't overwrite another > processor's separate output) if a processor doesn't want to be overwritten, they are free to write outside the span. I think that you need to give a processor the option to allow downstream overwriting. >I'll offer to draft/rewrite the separate sections/docs described above >should anyone think it worthwhile. any rewrites are welcome > >Or, if enough people say "enough is enough, and this is enough", I'll go >along with what's there so we can all go work on other stuff. I haven't >heard enough of *that*, yet. -- 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 gcs-pcs at agogme.com Thu Jul 7 19:39:57 2005 From: gcs-pcs at agogme.com (Thomas Dukleth) Date: Thu Jul 7 19:41:40 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <20050706210930.GG24159@curtis.med.yale.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> Message-ID: <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> 7 July 2005 Daniel Chudnov recommended, "- append your processor's output (i.e. don't overwrite another processor's separate output)." Under what circumstances would preserving previous processors' output be desirable? I can imagine rewriting proxy servers, JavaScript embedded directly in the document (a method I have implemented), and multiple plugins all operating on the same document. I would suppose the user would prefer to follow the OpenURL most directly under his control according to a hierarchy of action upon the document. What advantage would there be in having the link provided by each processor? How would the links be distinguished so the user could choose by his preferred processor? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA www.agogme.com 212-674-3783 On Wed, July 6, 2005 9:09 pm, Daniel Chudnov wrote: > At the risk of continuing discussion... > > I've said before that since there's no obviously preferable solution, > I'll go along with whatever consensus arises, should there be one. > That said, I think there are several things wrong with this spec. > > 0. We are mainly trying to make it easy to identify objects, so it > should say that. > > 1. It's too jargony. Few outside of our community will implement it. > > 2. It mixes the "how to publish openurls in html" bit with the > "how to process correctly published openurls" bit. This confuses > things. > > 3. It's a mistake to remove the properly-published-openurl bit > in an "activated" openurl. I think this also means that "latent" > isn't the right term. > > > As for (1) above, I've said before [*] that I prefer anchors with > @rel='openurl', and stick by that preference due to its simplicity, > modulo the willingness to go along with something else. :) > > What I want is for this to be relevant to All Publishers, especially > publishers already publishing openurls, to whom we could (upon spec > completion) say "you will publish your OpenURLs this way" in our licenses, > rather than saying nothing and allowing anything, which is what we do now. > To accomplish that, this document needs sell this interpretation of > the problem and its agreed-upon solution to the people who work out > contracts with publishers. Which hits the "too jargony" issue again, > as those folks typically wouldn't understand this document. > > If nothing else I'd prefer to see a clear division between sections: > "for everyone: what is this for?", "for publishers: how to publish > OpenURLs in HTML", and "for developers: how to process OpenURLs in > HTML published according to this spec." Separately we could provide > a "detailed discussion" that goes on about "how this is really about > ContextObjects" at great length. > > For that "how to process" bit: we should not assume the sole use case > we all know too well, of jumping from a link to a resolver screen. > In the current spec, this alternate use case fails: > > - Somebody at some university saves a lot of web pages with "activated" > links, maybe using "scrapbook" or "slogger" or a "researchers' box" > or somesuch. The saved pages work great until they take a new contract > at a different university. Then all the activated links still point > to their old institutional resolver and there's no "latent" stub to > re-configure in place. And, the previous institution's resolver doesn't > even republish the ContextObject/openurl itself using our spec, so they > can't just reroute it to their current institution that way, either. :P > > So, rather than adding to misinterpretations of "idempotent", I'd suggest > that we recommend that those processing/activating identified > contextobjects > should: > > - leave the original span/whatever stubs in place, and > - append your processor's output (i.e. don't overwrite another > processor's separate output) > > The first line fits the broken use case better, and also allows for > different UI paradigms, like little XUL icons popping up elsewhere on > the screen completely outside of an html stream, for instance. > > The latter bit allows for multiple parallel or chained processing steps > while preserving the initial hook for deferred (i.e. "much later") > processing. It also means the "latent" vs. "activated" dichotomy isn't > quite so central, so maybe we should just call it "publishing OpenURLs > in HTML 4.01/XHTML 1.0" and also say something like "this might all be > easier someday in XHTML 2.0." > > (Hmm, maybe this is also an argument for span over anchors... you can > stuff several anchors inside a span, right? ...goes to spec... wait, > no you can't, both A and SPAN are inline elements that don't allow > much of a content model, we want something that's a block element. > Indeed, putting As inside of SPANs is invalid. [**] Is that correct? > So, maybe div? Sigh...) > > I'll offer to draft/rewrite the separate sections/docs described above > should anyone think it worthwhile. > > Or, if enough people say "enough is enough, and this is enough", I'll go > along with what's there so we can all go work on other stuff. I haven't > heard enough of *that*, yet. > > -Dan > > > [*] > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2005-April/000055.html > > [**] http://www.w3.org/TR/html4/struct/global.html#edef-SPAN > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Thu Jul 7 22:55:56 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Jul 7 22:56:04 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> References: <20050706210930.GG24159@curtis.med.yale.edu> <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> Message-ID: <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: > Under what circumstances would preserving previous processors' > output be > desirable? I think it is very possible that a user may belong to multiple institutions/communities. For instance, I work at Georgia Tech, my wife (well, last semester, anyway) attended UGA, we both are patrons of the Atlanta-Fulton County Public Library all of which may (and most assuredly do) have different subscriptions to different things. My coworker (obviously) works at Georgia Tech, attends Florida State and lives in Columbia, SC making her a patron of the Richland County Public Library. She should therefore have access to any of these communities' resources as she browses (most likely meaning multiple activating agents). I think this screenshot: http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg shows this quite well (although, in reality, doesn't, but never mind reality). The point of this whole exercise is strip "institutional identity" from openurls, so overwriting the (latent|autodiscoverable) (openurl|contextobject) seems to defeat the purpose. -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 gcs-pcs at agogme.com Fri Jul 8 11:11:03 2005 From: gcs-pcs at agogme.com (Thomas Dukleth) Date: Fri Jul 8 11:11:08 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> Message-ID: <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> 7 July 2005 I had been thinking of a context that I did not describe well. A context where OpenURLs had become very popular, and yes, everyone would have access to multiple resolvers. Latent OpenURLs would be found quite ubiquitously in HTML documents. The documents where a user may then find latent OpenURLs may be unlikely to originate from any institution to which he is affiliated. Consider the following example. An HTML document with latent OpenURLs appears on a server at some institution. The server providing access to documents at that institution rewrites every served page as it is transmitted and appends hard encoded OpenURLs pointing to that institution's resolver and the resolver of a consortium to which that institution belongs. Now there are two OpenURLs for each latent OpenURL in the document. Someone copies the document from the originating institution and posts the document on a public webserver. This webserver adds a JavaScript header to every document, where the JavaScript application acts as an activating agent. This application appends a dynamically generated default OpenURL for each latent OpenURL in the document. Now there are three OpenURLs for each latent OpenURL in the document. A user accesses the document on the public webserver through his own institution's proxy server. This proxy server rewrites the transmitted pages and appends hard encoded OpenURLs pointing to that institution's resolver and the resolver of a consortium to which that institution belongs. Now there are five OpenURLs for each latent OpenURL in the document. The user's own browser has a latent OpenURL plugin. The plugin appends three dynamically generated OpenURLs pointing to his institution's resolver, the resolver of a consortium to which that institution belongs, and the resolver of his local public library for each latent OpenURL in the document. Now there are eight OpenURLs for each latent OpenURL in the document. Three of the.eight are irrelevant to the user and two of the eight are redundant. The user then saves the document to his local file system and attaches it to an email message that he sends to a friend. The friend fetches the email message with the attached document on his palmtop computer system. The low resource web browser in the palmtop system does not support a latent OpenURL plugin. The friend is unable to use the four hard encoded resolvers because he has no affiliation with the corresponding institutions. The dynamically generated OpenURLs from the sender's plugins were not transmitted with the document. The palmtop web browser does have JavaScript with DOM support. The friend is able to configure the JavaScript application embedded in the document from the default resolver to the resolver for his institution and the local public library. There are now six OpenURLs for each latent OpenURL in the document. Four of the six are irrelevant to the friend. Too many of the OpenURLs in this example are merely noise to the ultimate user because they do not correspond to an institution affiliated to the user. While images and text labels can identify an institution, an unnecessary degree of noise is bad for the an efficient use of latent OpenURLs. Certainly this example may be artificially contrived but the problem it exemplifies would not be uncommon and could be much worse if latent OpenURLs become very popular. Allowing the overwriting of the OpenURLs created by previous processors or activating agents would avoid this problem. Preserving the original query string in an attribute of the latent OpenURL span tag is a good advantage of using the span tag but that is an independent issue from appending or overwriting the previously generated OpenURLs for that span tag. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA www.agogme.com 212-674-3783 On Fri, July 8, 2005 2:55 am, Ross Singer wrote: > On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: >> Under what circumstances would preserving previous processors' >> output be >> desirable? > > I think it is very possible that a user may belong to multiple > institutions/communities. > > For instance, I work at Georgia Tech, my wife (well, last > semester, anyway) attended UGA, we both are patrons of the > Atlanta-Fulton County Public Library all of which may (and most > assuredly do) have different subscriptions to different things. > > My coworker (obviously) works at Georgia Tech, attends Florida > State and lives in Columbia, SC making her a patron of the > Richland County Public Library. She should therefore have access > to any of these communities' resources as she browses (most likely > meaning multiple activating agents). > > I think this screenshot: > http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg > shows this quite well (although, in reality, doesn't, but never > mind reality). > > The point of this whole exercise is strip "institutional identity" > from openurls, so overwriting the (latent|autodiscoverable) > (openurl|contextobject) seems to defeat the purpose. > > -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 gcs-pcs at agogme.com Fri Jul 8 13:13:47 2005 From: gcs-pcs at agogme.com (Thomas Dukleth) Date: Fri Jul 8 13:15:06 2005 Subject: [gcs-pcs-list] append or overwrite previous output option In-Reply-To: <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> References: <20050706210930.GG24159@curtis.med.yale.edu> <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> Message-ID: <2530.165.247.46.71.1120842827.squirrel@mail.zettai.net> 8 July 2005 Daniel Chudnov recommended, "- append your processor's output (i.e. don't overwrite another processor's separate output)." I took that recommendation as recommendation for a standard for latent OpenURL processors or activating agents. If the recommendation were adopted as a standard implementation, a user may not have the option of overwriting another processor's output. My suggestion here is merely that one should consider the potential undesirable effects of such a recommendation. Perhaps a better recommendation would be that activating agents should provide the user with the option of either appending or overwriting the previous processors' output lest we end up with a world of less flexible activating agents than we would otherwise. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA www.agogme.com 212-674-3783 On Fri, July 8, 2005 3:11 pm, Thomas Dukleth wrote: > 7 July 2005 > > > I had been thinking of a context that I did not describe well. A context > where OpenURLs had become very popular, and yes, everyone would have > access to multiple resolvers. Latent OpenURLs would be found quite > ubiquitously in HTML documents. The documents where a user may then find > latent OpenURLs may be unlikely to originate from any institution to which > he is affiliated. > > Consider the following example. > > An HTML document with latent OpenURLs appears on a server at some > institution. The server providing access to documents at that institution > rewrites every served page as it is transmitted and appends hard encoded > OpenURLs pointing to that institution's resolver and the resolver of a > consortium to which that institution belongs. Now there are two OpenURLs > for each latent OpenURL in the document. > > Someone copies the document from the originating institution and posts the > document on a public webserver. This webserver adds a JavaScript header > to every document, where the JavaScript application acts as an activating > agent. This application appends a dynamically generated default OpenURL > for each latent OpenURL in the document. Now there are three OpenURLs for > each latent OpenURL in the document. > > A user accesses the document on the public webserver through his own > institution's proxy server. This proxy server rewrites the transmitted > pages and appends hard encoded OpenURLs pointing to that institution's > resolver and the resolver of a consortium to which that institution > belongs. Now there are five OpenURLs for each latent OpenURL in the > document. > > The user's own browser has a latent OpenURL plugin. The plugin appends > three dynamically generated OpenURLs pointing to his institution's > resolver, the resolver of a consortium to which that institution belongs, > and the resolver of his local public library for each latent OpenURL in > the document. Now there are eight OpenURLs for each latent OpenURL in the > document. Three of the.eight are irrelevant to the user and two of the > eight are redundant. > > The user then saves the document to his local file system and attaches it > to an email message that he sends to a friend. The friend fetches the > email message with the attached document on his palmtop computer system. > The low resource web browser in the palmtop system does not support a > latent OpenURL plugin. The friend is unable to use the four hard encoded > resolvers because he has no affiliation with the corresponding > institutions. The dynamically generated OpenURLs from the sender's > plugins were not transmitted with the document. The palmtop web browser > does have JavaScript with DOM support. The friend is able to configure > the JavaScript application embedded in the document from the default > resolver to the resolver for his institution and the local public library. > There are now six OpenURLs for each latent OpenURL in the document. Four > of the six are irrelevant to the friend. > > Too many of the OpenURLs in this example are merely noise to the ultimate > user because they do not correspond to an institution affiliated to the > user. While images and text labels can identify an institution, an > unnecessary degree of noise is bad for the an efficient use of latent > OpenURLs. Certainly this example may be artificially contrived but the > problem it exemplifies would not be uncommon and could be much worse if > latent OpenURLs become very popular. Allowing the overwriting of the > OpenURLs created by previous processors or activating agents would avoid > this problem. Preserving the original query string in an attribute of the > latent OpenURL span tag is a good advantage of using the span tag but that > is an independent issue from appending or overwriting the previously > generated OpenURLs for that span tag. > > > Thomas Dukleth > Agogme > 109 E 9th Street, 3D > New York, NY 10003 > USA > www.agogme.com > 212-674-3783 > > > On Fri, July 8, 2005 2:55 am, Ross Singer wrote: >> On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: >>> Under what circumstances would preserving previous processors' >>> output be >>> desirable? >> >> I think it is very possible that a user may belong to multiple >> institutions/communities. >> >> For instance, I work at Georgia Tech, my wife (well, last >> semester, anyway) attended UGA, we both are patrons of the >> Atlanta-Fulton County Public Library all of which may (and most >> assuredly do) have different subscriptions to different things. >> >> My coworker (obviously) works at Georgia Tech, attends Florida >> State and lives in Columbia, SC making her a patron of the >> Richland County Public Library. She should therefore have access >> to any of these communities' resources as she browses (most likely >> meaning multiple activating agents). >> >> I think this screenshot: >> http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg >> shows this quite well (although, in reality, doesn't, but never >> mind reality). >> >> The point of this whole exercise is strip "institutional identity" >> from openurls, so overwriting the (latent|autodiscoverable) >> (openurl|contextobject) seems to defeat the purpose. >> >> -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 >> ---------------------------------------------------------------------- >> > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From alf at hubmed.org Fri Jul 8 14:17:19 2005 From: alf at hubmed.org (Alf Eaton) Date: Fri Jul 8 14:18:18 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> References: <20050706210930.GG24159@curtis.med.yale.edu> <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> Message-ID: It would be up to your local script - say a Greasemonkey script - whether or not to overwrite the existing OpenURLs, so this scenario isn't really a problem (I don't think). There's no reason why you should have to keep the existing links if you don't want to. alf. On 08 Jul 2005, at 17:11, Thomas Dukleth wrote: > 7 July 2005 > > > I had been thinking of a context that I did not describe well. A > context > where OpenURLs had become very popular, and yes, everyone would have > access to multiple resolvers. Latent OpenURLs would be found quite > ubiquitously in HTML documents. The documents where a user may > then find > latent OpenURLs may be unlikely to originate from any institution > to which > he is affiliated. > ... > There are now six OpenURLs for each latent OpenURL in the > document. Four > of the six are irrelevant to the friend. > > Too many of the OpenURLs in this example are merely noise to the > ultimate > user because they do not correspond to an institution affiliated to > the > user. While images and text labels can identify an institution, an > unnecessary degree of noise is bad for the an efficient use of latent > OpenURLs. Certainly this example may be artificially contrived but > the > problem it exemplifies would not be uncommon and could be much > worse if > latent OpenURLs become very popular. Allowing the overwriting of the > OpenURLs created by previous processors or activating agents would > avoid > this problem. Preserving the original query string in an attribute > of the > latent OpenURL span tag is a good advantage of using the span tag > but that > is an independent issue from appending or overwriting the previously > generated OpenURLs for that span tag. > > > Thomas Dukleth > Agogme > 109 E 9th Street, 3D > New York, NY 10003 > USA > www.agogme.com > 212-674-3783 > > > On Fri, July 8, 2005 2:55 am, Ross Singer wrote: > > >> On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: >> >> >>> Under what circumstances would preserving previous processors' >>> output be >>> desirable? >>> >>> >> >> I think it is very possible that a user may belong to multiple >> institutions/communities. >> >> For instance, I work at Georgia Tech, my wife (well, last >> semester, anyway) attended UGA, we both are patrons of the >> Atlanta-Fulton County Public Library all of which may (and most >> assuredly do) have different subscriptions to different things. >> >> My coworker (obviously) works at Georgia Tech, attends Florida >> State and lives in Columbia, SC making her a patron of the >> Richland County Public Library. She should therefore have access >> to any of these communities' resources as she browses (most likely >> meaning multiple activating agents). >> >> I think this screenshot: >> http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg >> shows this quite well (although, in reality, doesn't, but never >> mind reality). >> >> The point of this whole exercise is strip "institutional identity" >> from openurls, so overwriting the (latent|autodiscoverable) >> (openurl|contextobject) seems to defeat the purpose. >> >> -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 >> --------------------------------------------------------------------- >> - >> >> >> > _______________________________________________ > 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 Fri Jul 8 14:38:57 2005 From: eric at openly.com (Eric Hellman) Date: Fri Jul 8 14:41:33 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: References: <20050706210930.GG24159@curtis.med.yale.edu> <1174.165.247.42.225.1120779597.squirrel@mail.zettai.net> <1896.66.156.31.66.1120791356.squirrel@mail.library.gatech.edu> <4362.165.247.44.58.1120835463.squirrel@mail.zettai.net> Message-ID: I agree that handling of multiple processors will be important, and that SPAN is much more flexible than A in allowing processors to "leave the hooks in". I seriously never thought of this but after reading Dan's contribution it seems so obvious in retrospect. If we ever get to the success point of having *too many* processors, I think there are plenty of ways to trim away the unwanted stuff, whereas if the hooks are removed, there's no way to get them back. At 8:17 PM +0200 7/8/05, Alf Eaton wrote: >It would be up to your local script - say a Greasemonkey script - >whether or not to overwrite the existing OpenURLs, so this scenario >isn't really a problem (I don't think). There's no reason why you >should have to keep the existing links if you don't want to. > >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 Peter.Binkley at ualberta.ca Fri Jul 8 14:46:06 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Fri Jul 8 14:48:27 2005 Subject: [gcs-pcs-list] on the span version Message-ID: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> In fact the current draft says that the agent *must* overwrite (at least, it doesn't allow for any other action): in step 2, it says "and replace the content of the SPAN element, with an HTML anchor element ("A").". So Thomas's scenario of proliferating OpenURLs should never happen. No one has suggested a scenario in which it is desirable to preserve links generated by earlier agents in the chain, but in case such a scenario arises, should the draft be amended to allow each agent to decide whether to overwrite or append? No harm is done by preserving earlier links: if your agent preserves them and you send the file to me, my agent can overwrite them if I wish, or keep them if I'm curious. Peter Peter Binkley Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley@ualberta.ca > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Alf Eaton > Sent: Friday, July 08, 2005 12:17 PM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] on the span version > > It would be up to your local script - say a Greasemonkey > script - whether or not to overwrite the existing OpenURLs, > so this scenario isn't really a problem (I don't think). > There's no reason why you should have to keep the existing > links if you don't want to. > > alf. > > On 08 Jul 2005, at 17:11, Thomas Dukleth wrote: > > > > 7 July 2005 > > > > > > I had been thinking of a context that I did not describe well. A > > context where OpenURLs had become very popular, and yes, everyone > > would have access to multiple resolvers. Latent OpenURLs would be > > found quite ubiquitously in HTML documents. The documents where a > > user may then find latent OpenURLs may be unlikely to > originate from > > any institution to which he is affiliated. > > > > ... > > > > There are now six OpenURLs for each latent OpenURL in the > document. > > Four of the six are irrelevant to the friend. > > > > Too many of the OpenURLs in this example are merely noise to the > > ultimate user because they do not correspond to an institution > > affiliated to the user. While images and text labels can > identify an > > institution, an unnecessary degree of noise is bad for the an > > efficient use of latent OpenURLs. Certainly this example may be > > artificially contrived but the problem it exemplifies would not be > > uncommon and could be much worse if latent OpenURLs become very > > popular. Allowing the overwriting of the OpenURLs created > by previous > > processors or activating agents would avoid this problem. > Preserving > > the original query string in an attribute of the latent > OpenURL span > > tag is a good advantage of using the span tag but that is an > > independent issue from appending or overwriting the previously > > generated OpenURLs for that span tag. > > > > > > Thomas Dukleth > > Agogme > > 109 E 9th Street, 3D > > New York, NY 10003 > > USA > > www.agogme.com > > 212-674-3783 > > > > > > On Fri, July 8, 2005 2:55 am, Ross Singer wrote: > > > > > >> On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: > >> > >> > >>> Under what circumstances would preserving previous processors' > >>> output be > >>> desirable? > >>> > >>> > >> > >> I think it is very possible that a user may belong to multiple > >> institutions/communities. > >> > >> For instance, I work at Georgia Tech, my wife (well, last > semester, > >> anyway) attended UGA, we both are patrons of the Atlanta-Fulton > >> County Public Library all of which may (and most assuredly > do) have > >> different subscriptions to different things. > >> > >> My coworker (obviously) works at Georgia Tech, attends > Florida State > >> and lives in Columbia, SC making her a patron of the > Richland County > >> Public Library. She should therefore have access to any of these > >> communities' resources as she browses (most likely meaning > multiple > >> activating agents). > >> > >> I think this screenshot: > >> http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg > >> shows this quite well (although, in reality, doesn't, but > never mind > >> reality). > >> > >> The point of this whole exercise is strip "institutional identity" > >> from openurls, so overwriting the (latent|autodiscoverable) > >> (openurl|contextobject) seems to defeat the purpose. > >> > >> -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 > >> > --------------------------------------------------------------------- > >> - > >> > >> > >> > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Fri Jul 8 15:59:39 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Jul 8 16:05:47 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <20050706210930.GG24159@curtis.med.yale.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> Message-ID: <42CEDB2B.3080100@library.gatech.edu> The more I think about this, the more I question placing this data in HTML attributes. I think using SPAN still is a good idea (or good enough) for activation, because the container element can be arbitrary (assuming it's consistent, of course). I like SPAN because I don't know of any default behavior that a random browser might assign to it. Innocuous. I especially like this after spending half the day investigating using OBJECT for this task -- only to be thwarted by Safari. This put me on the notion of really only using the SPAN as a container for commented ContextObjects (following the SCRIPT model). This frees us from trying to shove a lot of data into HTML attributes that may or may not be scaleable or intuitive. To mashup Eric's example with Herbert and Oren's ContextObject model: The span's attribute could also be "title". Since an activating agent would need to know what to do with this, anyway, it seems like storing the innards in a comment serves the purpose while also not exposing a bunch of gobbledygook to an unsuspecting browser. Note: I am not necessarily endorsing the content that I have put inside my comment block there, just showing a possibility. In fact, I would probably want to put the ContextObject format in the span tag somewhere (or in the comment block... somewhere). And with this, I offer the name "Embedded ContextObjects" -Ross. Daniel Chudnov wrote: >At the risk of continuing discussion... > >I've said before that since there's no obviously preferable solution, >I'll go along with whatever consensus arises, should there be one. >That said, I think there are several things wrong with this spec. > >0. We are mainly trying to make it easy to identify objects, so it > should say that. > >1. It's too jargony. Few outside of our community will implement it. > >2. It mixes the "how to publish openurls in html" bit with the > "how to process correctly published openurls" bit. This confuses > things. > >3. It's a mistake to remove the properly-published-openurl bit > in an "activated" openurl. I think this also means that "latent" > isn't the right term. > > >As for (1) above, I've said before [*] that I prefer anchors with >@rel='openurl', and stick by that preference due to its simplicity, >modulo the willingness to go along with something else. :) > >What I want is for this to be relevant to All Publishers, especially >publishers already publishing openurls, to whom we could (upon spec >completion) say "you will publish your OpenURLs this way" in our licenses, >rather than saying nothing and allowing anything, which is what we do now. >To accomplish that, this document needs sell this interpretation of >the problem and its agreed-upon solution to the people who work out >contracts with publishers. Which hits the "too jargony" issue again, >as those folks typically wouldn't understand this document. > >If nothing else I'd prefer to see a clear division between sections: >"for everyone: what is this for?", "for publishers: how to publish >OpenURLs in HTML", and "for developers: how to process OpenURLs in >HTML published according to this spec." Separately we could provide >a "detailed discussion" that goes on about "how this is really about >ContextObjects" at great length. > >For that "how to process" bit: we should not assume the sole use case >we all know too well, of jumping from a link to a resolver screen. >In the current spec, this alternate use case fails: > > - Somebody at some university saves a lot of web pages with "activated" > links, maybe using "scrapbook" or "slogger" or a "researchers' box" > or somesuch. The saved pages work great until they take a new contract > at a different university. Then all the activated links still point > to their old institutional resolver and there's no "latent" stub to > re-configure in place. And, the previous institution's resolver doesn't > even republish the ContextObject/openurl itself using our spec, so they > can't just reroute it to their current institution that way, either. :P > >So, rather than adding to misinterpretations of "idempotent", I'd suggest >that we recommend that those processing/activating identified contextobjects >should: > > - leave the original span/whatever stubs in place, and > - append your processor's output (i.e. don't overwrite another > processor's separate output) > >The first line fits the broken use case better, and also allows for >different UI paradigms, like little XUL icons popping up elsewhere on >the screen completely outside of an html stream, for instance. > >The latter bit allows for multiple parallel or chained processing steps >while preserving the initial hook for deferred (i.e. "much later") >processing. It also means the "latent" vs. "activated" dichotomy isn't >quite so central, so maybe we should just call it "publishing OpenURLs >in HTML 4.01/XHTML 1.0" and also say something like "this might all be >easier someday in XHTML 2.0." > >(Hmm, maybe this is also an argument for span over anchors... you can >stuff several anchors inside a span, right? ...goes to spec... wait, >no you can't, both A and SPAN are inline elements that don't allow >much of a content model, we want something that's a block element. >Indeed, putting As inside of SPANs is invalid. [**] Is that correct? >So, maybe div? Sigh...) > >I'll offer to draft/rewrite the separate sections/docs described above >should anyone think it worthwhile. > >Or, if enough people say "enough is enough, and this is enough", I'll go >along with what's there so we can all go work on other stuff. I haven't >heard enough of *that*, yet. > > -Dan > > >[*] http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2005-April/000055.html > >[**] http://www.w3.org/TR/html4/struct/global.html#edef-SPAN > > > > From gcs-pcs at agogme.com Fri Jul 8 16:00:41 2005 From: gcs-pcs at agogme.com (Thomas Dukleth) Date: Fri Jul 8 16:05:48 2005 Subject: [gcs-pcs-list] append or overwrite previous output option In-Reply-To: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> Message-ID: <2111.165.247.46.71.1120852841.squirrel@mail.zettai.net> 8 July 2005 Daniel Chudnov recommended, "- append your processor's output (i.e. don't overwrite another processor's separate output)." Eric Hellman seemed to endorse the idea in his reply to Daniel, although, Eric had not modified his draft proposal accordingly. I asked why this was recommended, although, I could have suggested some possible reasons. I wanted to know Daniel's or other people's reasons. Ross Singer had provided a reasonable answer about accessing multiple resolvers supplied by multiple activating agents for multiple affiliations along the lines I would have suggested. Any good activating agent should allow for multiple affiliations, but it may help if even transient affiliations are may preserved by appending in the document being viewed. If Daniel had any additional reasons in mind, I would be pleased to know what those reasons are. I suggested a hazard scenario for the future if every activating agent only appends. I suggested that the recommendation of a user option for appending or overwriting the previous activating agent output would be better. However, following the example that Ross gave, appending might be a good default for now. I want the future ubiquity of latent OpenURLs to develop as quickly as possible without being unprepared for the hazard that I had suggested. The recent discussion has certainly shown the clear advantage of using the span tag to preserve the query string within an attribute of the span tag in an unmodified form in case a buggy activating agent might mangle the query string or loose information changing between OpenURL versions 1.0 and 0.1. There are still some problems I have with one detail of Eric's proposal that I have commented about previously. I have not had adequate time to report additional lack of nesting usage difficulties well, while I have recently been doing work to help prepare the Koha ILS project to use MARC correctly. I will try to report these additional lack of nesting usage difficulties in the next few days so that we can move the discussion forward. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA www.agogme.com 212-674-3783 On Fri, July 8, 2005 6:46 pm, Binkley, Peter wrote: > In fact the current draft says that the agent *must* overwrite (at > least, it doesn't allow for any other action): in step 2, it says "and > replace the content of the SPAN element, with an HTML anchor element > ("A").". So Thomas's scenario of proliferating OpenURLs should never > happen. > > No one has suggested a scenario in which it is desirable to preserve > links generated by earlier agents in the chain, but in case such a > scenario arises, should the draft be amended to allow each agent to > decide whether to overwrite or append? No harm is done by preserving > earlier links: if your agent preserves them and you send the file to me, > my agent can overwrite them if I wish, or keep them if I'm curious. > > Peter > > Peter Binkley > Digital Initiatives Technology Librarian > Information Technology Services > 4-30 Cameron Library > University of Alberta Libraries > Edmonton, Alberta > Canada T6G 2J8 > Phone: (780) 492-3743 > Fax: (780) 492-9243 > e-mail: peter.binkley@ualberta.ca > > > >> -----Original Message----- >> From: gcs-pcs-list-bounces@cipolo.med.yale.edu >> [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf >> Of Alf Eaton >> Sent: Friday, July 08, 2005 12:17 PM >> To: gcs-pcs-list@cipolo.med.yale.edu >> Subject: Re: [gcs-pcs-list] on the span version >> >> It would be up to your local script - say a Greasemonkey >> script - whether or not to overwrite the existing OpenURLs, >> so this scenario isn't really a problem (I don't think). >> There's no reason why you should have to keep the existing >> links if you don't want to. >> >> alf. >> >> On 08 Jul 2005, at 17:11, Thomas Dukleth wrote: >> >> >> > 7 July 2005 >> > >> > >> > I had been thinking of a context that I did not describe well. A >> > context where OpenURLs had become very popular, and yes, everyone >> > would have access to multiple resolvers. Latent OpenURLs would be >> > found quite ubiquitously in HTML documents. The documents where a >> > user may then find latent OpenURLs may be unlikely to >> originate from >> > any institution to which he is affiliated. >> > >> >> ... >> >> >> > There are now six OpenURLs for each latent OpenURL in the >> document. >> > Four of the six are irrelevant to the friend. >> > >> > Too many of the OpenURLs in this example are merely noise to the >> > ultimate user because they do not correspond to an institution >> > affiliated to the user. While images and text labels can >> identify an >> > institution, an unnecessary degree of noise is bad for the an >> > efficient use of latent OpenURLs. Certainly this example may be >> > artificially contrived but the problem it exemplifies would not be >> > uncommon and could be much worse if latent OpenURLs become very >> > popular. Allowing the overwriting of the OpenURLs created >> by previous >> > processors or activating agents would avoid this problem. >> Preserving >> > the original query string in an attribute of the latent >> OpenURL span >> > tag is a good advantage of using the span tag but that is an >> > independent issue from appending or overwriting the previously >> > generated OpenURLs for that span tag. >> > >> > >> > Thomas Dukleth >> > Agogme >> > 109 E 9th Street, 3D >> > New York, NY 10003 >> > USA >> > www.agogme.com >> > 212-674-3783 >> > >> > >> > On Fri, July 8, 2005 2:55 am, Ross Singer wrote: >> > >> > >> >> On Thu, July 7, 2005 7:39 pm, Thomas Dukleth said: >> >> >> >> >> >>> Under what circumstances would preserving previous processors' >> >>> output be >> >>> desirable? >> >>> >> >>> >> >> >> >> I think it is very possible that a user may belong to multiple >> >> institutions/communities. >> >> >> >> For instance, I work at Georgia Tech, my wife (well, last >> semester, >> >> anyway) attended UGA, we both are patrons of the Atlanta-Fulton >> >> County Public Library all of which may (and most assuredly >> do) have >> >> different subscriptions to different things. >> >> >> >> My coworker (obviously) works at Georgia Tech, attends >> Florida State >> >> and lives in Columbia, SC making her a patron of the >> Richland County >> >> Public Library. She should therefore have access to any of these >> >> communities' resources as she browses (most likely meaning >> multiple >> >> activating agents). >> >> >> >> I think this screenshot: >> >> http://www.ariadne.ac.uk/issue43/chudnov/figure-8.jpg >> >> shows this quite well (although, in reality, doesn't, but >> never mind >> >> reality). >> >> >> >> The point of this whole exercise is strip "institutional identity" >> >> from openurls, so overwriting the (latent|autodiscoverable) >> >> (openurl|contextobject) seems to defeat the purpose. >> >> >> >> -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 >> >> >> --------------------------------------------------------------------- >> >> - >> >> >> >> >> >> >> > _______________________________________________ >> > gcs-pcs-list mailing list >> > gcs-pcs-list@cipolo.med.yale.edu >> > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > >> > >> >> >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From eric at openly.com Fri Jul 8 16:27:00 2005 From: eric at openly.com (Eric Hellman) Date: Fri Jul 8 16:28:10 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> Message-ID: What is most important is that the hooks (which are in the attributes of the SPAN, not its content) remain so that further services may use the information. for example, a sidebar application might want to read and process the metadata after a link-adding plugin had done its work. What dan pointed out was that the instructions I had written for the previous draft ignored applications other than link-adding or link-repointing and that replacing contained content would differ depending on the application. Further editing of the document seems desirable now that we've thought on this a bit. At 12:46 PM -0600 7/8/05, Binkley, Peter wrote: >In fact the current draft says that the agent *must* overwrite (at >least, it doesn't allow for any other action): in step 2, it says "and >replace the content of the SPAN element, with an HTML anchor element >("A").". So Thomas's scenario of proliferating OpenURLs should never >happen. > >No one has suggested a scenario in which it is desirable to preserve >links generated by earlier agents in the chain, but in case such a >scenario arises, should the draft be amended to allow each agent to >decide whether to overwrite or append? No harm is done by preserving >earlier links: if your agent preserves them and you send the file to me, >my agent can overwrite them if I wish, or keep them if I'm curious. > >Peter -- 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 Fri Jul 8 16:36:36 2005 From: eric at openly.com (Eric Hellman) Date: Fri Jul 8 16:37:05 2005 Subject: [gcs-pcs-list] append or overwrite previous output option In-Reply-To: <2111.165.247.46.71.1120852841.squirrel@mail.zettai.net> References: <908893006339C0409519E4065DF3B2491E82FE@mailserver.ualibrary.ualberta.ca> <2111.165.247.46.71.1120852841.squirrel@mail.zettai.net> Message-ID: At 8:00 PM +0000 7/8/05, Thomas Dukleth wrote: >8 July 2005 > > >Daniel Chudnov recommended, "- append your processor's output (i.e. don't >overwrite another processor's separate output)." > >Eric Hellman seemed to endorse the idea in his reply to Daniel, although, >Eric had not modified his draft proposal accordingly. There is the technical difficulty of how you tell what a previous processor has generated. In the case of SPAN, a processor can add content inside or outside the SPAN element- outside if the goal was to avoid being overwritten downstream, and inside if it was judged to be better to allow a downstream processor overwrite. The key here is that the flexibility exists to allow processors to behave intelligently without removing the metadata that may be needed downstream. -- 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 Fri Jul 8 18:01:20 2005 From: alf at hubmed.org (Alf Eaton) Date: Fri Jul 8 18:02:02 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <42CEDB2B.3080100@library.gatech.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> <42CEDB2B.3080100@library.gatech.edu> Message-ID: On 08 Jul 2005, at 21:59, Ross Singer wrote: > The more I think about this, the more I question placing this data > in HTML attributes. > > I think using SPAN still is a good idea (or good enough) for > activation, because the container element can be arbitrary > (assuming it's consistent, of course). I like SPAN because I don't > know of any default behavior that a random browser might assign to > it. Innocuous. I especially like this after spending half the day > investigating using OBJECT for this task -- only to be thwarted by > Safari. > > This put me on the notion of really only using the SPAN as a > container for commented ContextObjects (following the SCRIPT > model). This frees us from trying to shove a lot of data into HTML > attributes that may or may not be scaleable or intuitive. > > To mashup Eric's example with Herbert and Oren's ContextObject model: > > > That seems like a nice idea. I'm just wondering at the moment how much harder that's going to make it to parse with Javascript, as the data will be stored as text within a comment node, rather than being a standard part of the DOM. I don't know how easy it is then to parse that text as XML rather than having to use regexes to pick out the information. alf. From ross.singer at library.gatech.edu Fri Jul 8 18:44:13 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Jul 8 18:45:08 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: References: <20050706210930.GG24159@curtis.med.yale.edu> <42CEDB2B.3080100@library.gatech.edu> Message-ID: <50222.66.156.31.66.1120862653.squirrel@mail.library.gatech.edu> On Fri, July 8, 2005 6:01 pm, Alf Eaton said: > > That seems like a nice idea. I'm just wondering at the moment how > much harder that's going to make it to parse with Javascript, as > the > data will be stored as text within a comment node, rather than > being > a standard part of the DOM. I don't know how easy it is then to > parse > that text as XML rather than having to use regexes to pick out the > information. > var parser = new DOMParser(); var results = parser.parseFromString(commentNode.nodeValue, "text/xml"); or somesuch should do this just fine in Mozilla. I have been seeing similar functionality being created for IE. This might be a solvable problem. -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 Tue Jul 12 00:04:52 2005 From: eric at openly.com (Eric Hellman) Date: Tue Jul 12 00:05:04 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <42CEDB2B.3080100@library.gatech.edu> References: <20050706210930.GG24159@curtis.med.yale.edu> <42CEDB2B.3080100@library.gatech.edu> Message-ID: Ross et. al, first of all, note that Z39.88-2004 (NISO OpenURL) includes a definition of an XML ContextObject Format. Take a look before you leap. there are many reasons that embedded XML ContextObjects *in HTML* introduce a level of complexity that I very much do not want to deal with. I list here some of the issues that would need to be dealt with a caveat that there are sure to be more that would be discovered during an implementation. 1. if you have an article title with "--" in it, the context object will be unhidden in all browsers that I have tested. This is in fact correct browser behavior. We discovered this problem when a customer showed us such real OpenURL with "--" in the title data that un-hid some debugging data that we had placed in an html comment. Basically you would have to invent a convention for how to put xml into an html comment. 2. html authoring applications do not support xml parsing of content embedded in html comments. The practical effect of this would be lots of invalid xml because it would be very difficult to check. 3. encoding of the xml ContextObject is supposed to be UTF-8, so how do you put UTF-8 encoded data in an HTML page that uses latin-1 or let us say Shift-JIS? If you are using the DOM, you may not have independant control of the encoding of the comment data 4. how would you handle multiple processors? would other content in the SPAN be forbidden? Would a second comment in the SPAN be forbidden? How would you add real comments to the comment- in a separate comment? I don't think you can use "C-style comments with XML content inside an HTML Comment inside XHTML in a serious proposal. XHTML is a different story of course, as there's no need to hide the ContextObject XML. This would definitely be the future direction. At 3:59 PM -0400 7/8/05, Ross Singer wrote: >The more I think about this, the more I question placing this data >in HTML attributes. > >I think using SPAN still is a good idea (or good enough) for >activation, because the container element can be arbitrary (assuming >it's consistent, of course). I like SPAN because I don't know of >any default behavior that a random browser might assign to it. >Innocuous. I especially like this after spending half the day >investigating using OBJECT for this task -- only to be thwarted by >Safari. > >This put me on the notion of really only using the SPAN as a >container for commented ContextObjects (following the SCRIPT model). >This frees us from trying to shove a lot of data into HTML >attributes that may or may not be scaleable or intuitive. > >To mashup Eric's example with Herbert and Oren's ContextObject model: > > > > >The span's attribute could also be "title". Since an activating >agent would need to know what to do with this, anyway, it seems like >storing the innards in a comment serves the purpose while also not >exposing a bunch of gobbledygook to an unsuspecting browser. > >Note: I am not necessarily endorsing the content that I have put >inside my comment block there, just showing a possibility. In fact, >I would probably want to put the ContextObject format in the span >tag somewhere (or in the comment block... somewhere). > >And with this, I offer the name "Embedded ContextObjects" > >-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 Peter.Binkley at ualberta.ca Tue Jul 12 16:34:00 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Tue Jul 12 16:34:23 2005 Subject: [gcs-pcs-list] on the span version Message-ID: <908893006339C0409519E4065DF3B2491E830C@mailserver.ualibrary.ualberta.ca> Is there any mileage in enabling a link to an external XML ContextObject? The parsing could then be simplified: Other comments would be allowed, provided they didn't begin with "ContextObject". The XML parsing would be simple, since it would be dealing with a proper XML doc that could be validated, reused, etc. The main document could only have its links activated by an agent that had network access to the context objects, of course. More trouble than it's worth, given that XHTML solves the problem? Peter Peter Binkley Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley@ualberta.ca > -----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: Monday, July 11, 2005 10:05 PM > To: Ross Singer > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] on the span version > > Ross et. al, > > first of all, note that Z39.88-2004 (NISO OpenURL) includes a > definition of an XML ContextObject Format. Take a look before > you leap. > > there are many reasons that embedded XML ContextObjects *in > HTML* introduce a level of complexity that I very much do not > want to deal with. I list here some of the issues that would > need to be dealt with a caveat that there are sure to be more > that would be discovered during an implementation. > > 1. if you have an article title with "--" in it, the context > object will be unhidden in all browsers that I have tested. > This is in fact correct browser behavior. We discovered this > problem when a customer showed us such real OpenURL with "--" > in the title data that un-hid some debugging data that we had > placed in an html comment. Basically you would have to > invent a convention for how to put xml into an html comment. > > 2. html authoring applications do not support xml parsing of > content embedded in html comments. The practical effect of > this would be lots of invalid xml because it would be very > difficult to check. > > 3. encoding of the xml ContextObject is supposed to be UTF-8, > so how do you put UTF-8 encoded data in an HTML page that > uses latin-1 or let us say Shift-JIS? If you are using the > DOM, you may not have independant control of the encoding of > the comment data > > 4. how would you handle multiple processors? would other > content in the SPAN be forbidden? Would a second comment in > the SPAN be forbidden? How would you add real comments to the > comment- in a separate comment? I don't think you can use > "C-style comments with XML content inside an HTML Comment > inside XHTML in a serious proposal. > > > XHTML is a different story of course, as there's no need to > hide the ContextObject XML. This would definitely be the > future direction. > > > > At 3:59 PM -0400 7/8/05, Ross Singer wrote: > >The more I think about this, the more I question placing this data > >in HTML attributes. > > > >I think using SPAN still is a good idea (or good enough) for > >activation, because the container element can be arbitrary (assuming > >it's consistent, of course). I like SPAN because I don't know of > >any default behavior that a random browser might assign to it. > >Innocuous. I especially like this after spending half the day > >investigating using OBJECT for this task -- only to be thwarted by > >Safari. > > > >This put me on the notion of really only using the SPAN as a > >container for commented ContextObjects (following the SCRIPT model). > >This frees us from trying to shove a lot of data into HTML > >attributes that may or may not be scaleable or intuitive. > > > >To mashup Eric's example with Herbert and Oren's ContextObject model: > > > > > > > > > >The span's attribute could also be "title". Since an activating > >agent would need to know what to do with this, anyway, it seems like > >storing the innards in a comment serves the purpose while also not > >exposing a bunch of gobbledygook to an unsuspecting browser. > > > >Note: I am not necessarily endorsing the content that I have put > >inside my comment block there, just showing a possibility. In fact, > >I would probably want to put the ContextObject format in the span > >tag somewhere (or in the comment block... somewhere). > > > >And with this, I offer the name "Embedded ContextObjects" > > > >-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 > _______________________________________________ > 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 Tue Jul 12 17:58:18 2005 From: eric at openly.com (Eric Hellman) Date: Tue Jul 12 18:08:21 2005 Subject: [gcs-pcs-list] on the span version In-Reply-To: <908893006339C0409519E4065DF3B2491E830C@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B2491E830C@mailserver.ualibrary.ualberta.ca> Message-ID: This is the "by-reference" ContextObject in the SAP-2 profile of NISO OpenURL. It's a whole lot easier to understand a dense technical document once you've reinvented the things it describes. So having made this leap, we're left with the question of whether putting the OpenURL in the "title" attribute is better than putting it into an html comment. Yes, it is, lots better. Which brings us back to the original question, what is the simplest, sufficient, convention that has a chance to gain wide adoption, and won't close off future extention and development? Eric At 2:34 PM -0600 7/12/05, Binkley, Peter wrote: >Is there any mileage in enabling a link to an external XML >ContextObject? The parsing could then be simplified: > > > >Other comments would be allowed, provided they didn't begin with >"ContextObject". The XML parsing would be simple, since it would be >dealing with a proper XML doc that could be validated, reused, etc. The >main document could only have its links activated by an agent that had >network access to the context objects, of course. More trouble than it's >worth, given that XHTML solves the problem? > >Peter > >Peter Binkley >Digital Initiatives Technology Librarian >Information Technology Services >4-30 Cameron Library >University of Alberta Libraries >Edmonton, Alberta >Canada T6G 2J8 >Phone: (780) 492-3743 >Fax: (780) 492-9243 >e-mail: peter.binkley@ualberta.ca -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Fri Jul 15 17:43:50 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Jul 15 17:44:53 2005 Subject: [gcs-pcs-list] not saying "replace" Message-ID: <20050715214349.GD23382@curtis.med.yale.edu> Eric restated my main point, far more concisely: we should recommend that agents "leave the hooks in", and by "the hooks" I mean "the bits we tell people how to do within the first yellow box in Eric's doc." The bits about embedding fuller metadata streams inline seem good too, but as we bluesky'd near the end of the "opening up openurls" paper, it seems like a better architecture might involve (1) easily-found identifiers in the HTML stream and (2) a top-level meta/alt link to an OAI repository or service registry. And I really want to get to (2) soon but (1) is the single foot put down here. I think the following discussion of "how to use it" should be only discussion, not specification, and that the text is too specific. It might instead only say: 1. select all span elements with class="Z3988". 2. for each selected span, extract the value of the title attribute 3. operate on that value, which is the OpenURL ContextObject, as you wish, but *do not* overwrite the original class and title values of the span element. This allows for different actions to be taken on the same element in a variety of potential scenarios. I think the discussion of the past week indicates that diverse scenarios might lend themselves to overwriting, appending, the popping up of little XUL icons entirely apart from the HTML stream, pipelined processing, and ISO9000-Compliant N-Tier Enterprise OpenURL Architectures. So, anything that goes beyond exactly what we want people to do: "(1) publish them this way, (2) look for them like that, and (3) leave 'em how you found 'em" goes too far and should not be in the spec at all. Or, a variety of processing scenarios could be written up and linked to from the proposal itself, but not in the proposal, as that will be confusing. On the title... I think the earlier point by herbertv and others outside of this list that these are really just ContextObjects is indeed critical, and at the risk of repeating myself, this isn't about "latent" OpenURLs or even latent "OpenURLs". What it is is "how to publish OpenURL ContextObjects in HTML". But imho nobody Out There will want to read about that, so we should come up with a snappy acronym that reminds people of friendly products everyone uses, like, say, a common household solvent. I'm thinking "OUCO", pronounced like "Ouzo", for "OpenURL ContextObjects", but surely somebody can do better. "OUCO: More fun than AJAX!" -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Fri Jul 15 18:44:33 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Jul 15 18:44:37 2005 Subject: [gcs-pcs-list] not saying "replace" In-Reply-To: <20050715214349.GD23382@curtis.med.yale.edu> References: <20050715214349.GD23382@curtis.med.yale.edu> Message-ID: <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> On my train ride home, I thought of: COinS Context Objects in Spans Pretty simple, absolutely accurate. It beat out my other idea: coelacanth Context Objects: Embedded/ Latent Allowing Citations As Needed To Html Of course, the latter is already ready for it's O'Reilly book. -Ross. On Fri, July 15, 2005 5:43 pm, Daniel Chudnov said: > Eric restated my main point, far more concisely: we should > recommend > that agents "leave the hooks in", and by "the hooks" I mean "the > bits > we tell people how to do within the first yellow box in Eric's > doc." > > The bits about embedding fuller metadata streams inline seem good > too, > but as we bluesky'd near the end of the "opening up openurls" > paper, > it seems like a better architecture might involve (1) easily-found > identifiers in the HTML stream and (2) a top-level meta/alt link > to > an OAI repository or service registry. And I really want to get > to > (2) soon but (1) is the single foot put down here. > > I think the following discussion of "how to use it" should be only > discussion, not specification, and that the text is too specific. > It > might instead only say: > > 1. select all span elements with class="Z3988". > > 2. for each selected span, extract the value of the title > attribute > > 3. operate on that value, which is the OpenURL ContextObject, as > you > wish, but *do not* overwrite the original class and title > values of > the span element. This allows for different actions to be > taken > on the same element in a variety of potential scenarios. > > > I think the discussion of the past week indicates that diverse > scenarios > might lend themselves to overwriting, appending, the popping up of > little > XUL icons entirely apart from the HTML stream, pipelined > processing, and > ISO9000-Compliant N-Tier Enterprise OpenURL Architectures. So, > anything > that goes beyond exactly what we want people to do: "(1) publish > them > this way, (2) look for them like that, and (3) leave 'em how you > found > 'em" goes too far and should not be in the spec at all. Or, a > variety of > processing scenarios could be written up and linked to from the > proposal > itself, but not in the proposal, as that will be confusing. > > On the title... I think the earlier point by herbertv and others > outside > of this list that these are really just ContextObjects is indeed > critical, > and at the risk of repeating myself, this isn't about "latent" > OpenURLs > or even latent "OpenURLs". What it is is "how to publish OpenURL > ContextObjects in HTML". But imho nobody Out There will want to > read > about that, so we should come up with a snappy acronym that > reminds people > of friendly products everyone uses, like, say, a common household > solvent. > > I'm thinking "OUCO", pronounced like "Ouzo", for "OpenURL > ContextObjects", > but surely somebody can do better. > > "OUCO: More fun than AJAX!" > > -dc > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > ---------------------------------------------------------------------- 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 Sat Jul 16 13:10:20 2005 From: eric at openly.com (Eric Hellman) Date: Sat Jul 16 13:10:28 2005 Subject: [gcs-pcs-list] not saying "replace" In-Reply-To: <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> Message-ID: I think that's a winner. Can also call it "OpenURL COinS" until people are familiar with it. Slogan: "Put COinS in your (webpage|blog|website)!" connotation: very valuable in aggregate, but cheap and inexpensive individually no significant acronym interference (Coinsurance is a totally different area). no trademark problems. At 6:44 PM -0400 7/15/05, Ross Singer wrote: >On my train ride home, I thought of: >COinS > >Context >Objects >in >Spans > >Pretty simple, absolutely accurate. -- 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 Sat Jul 16 13:16:50 2005 From: alf at hubmed.org (Alf Eaton) Date: Sat Jul 16 13:43:15 2005 Subject: [gcs-pcs-list] not saying "replace" In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> Message-ID: <6580C2E8-4A77-4898-AD43-0F65664C7FE4@hubmed.org> Piggy Bank has 'data coins', also used to refer to invisible data, but in this case displayed when data is available . That's the only possible confusion I can think of. alf. On 16 Jul 2005, at 19:10, Eric Hellman wrote: > I think that's a winner. Can also call it "OpenURL COinS" until > people are familiar with it. > > Slogan: > "Put COinS in your (webpage|blog|website)!" > > connotation: > very valuable in aggregate, but cheap and inexpensive individually > > no significant acronym interference (Coinsurance is a totally > different area). > > no trademark problems. > > > At 6:44 PM -0400 7/15/05, Ross Singer wrote: > >> On my train ride home, I thought of: >> COinS >> >> Context >> Objects >> in >> Spans >> >> Pretty simple, absolutely accurate. >> > > > > -- > > 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 alf at hubmed.org Mon Jul 18 11:03:51 2005 From: alf at hubmed.org (Alf Eaton) Date: Mon Jul 18 11:05:32 2005 Subject: [gcs-pcs-list] Require Version 1.0 OpenURLs in Public Contexts In-Reply-To: References: <1439.165.247.47.109.1118120478.squirrel@165.247.47.109> <4610.165.247.28.221.1118156062.squirrel@165.247.28.221> Message-ID: Coming back to this point, would it be possible to require in the specification that latent OpenURLs (in s) begin with 'ctx_ver='? If that was the case, then the class attribute wouldn't be necessary at all, which would also mean that the LOURL [:-)] might be easier to identify. eg can use the XPath selector //span[@title] and if (span_title.indexOf('ctx_ver=') == 0) to see if it's an OpenURL. There's no longer any possibility of breaking existing links, such as to ProQuest, as they wouldn't be in a in the first place. alf. On 07 Jun 2005, at 17:20, Eric Hellman wrote: > it's the position in the query String that is flexible. > "url_ver=Z39.88-2004" will appear in all valid 1.0 OpenURLs. In > other words, you can shuffle the order of the token delimited by > "&" without changing the meaning of the OpenURL. "-2003" was a > draft version of the standard. > > > At 10:54 AM -0400 6/7/05, Thomas Dukleth wrote: > >> 7 June 2005 >> >> >> I guess that I misinterpreted the KEV documentation regarding the >> difference between version 0.1 and version 1.0 OpenURLs as it >> relates to >> the required form of the query string. Is the issue that the >> documented >> KEV usage is not strictly required for version 1.0 OpenURLs or >> that even >> the KEV documentation does not require url_ver=Z39.88-2004 to >> appear at >> the beginning of the query string? I assume this is not merely a >> question >> of the placement of url_ver=Z39.88-2004 as a required element >> somewhere in >> the query string but that url_ver=Z39.88-2004 is not required to >> appear at >> in the query string at all for version 1.0 OpenURLs. I also >> assume the >> issue is not about whether -2004 appears as part of the value as I >> have >> seen -2003 used in examples identified as version 1.0 OpenURLs. >> My tests >> only ever tested for the presence of url_ver=Z39.88 at the >> beginning of >> the query string, ignoring any date modifier. >> >> Regardless of where my misinterpretation arose, is there a means to >> reliably identify version 1.0 OpenURLs as OpenURLs from the >> information in >> the query string? >> >> >> Thomas Dukleth >> >> >> Thomas Dukleth >> Agogme >> 109 E 9th Street, 3D >> New York, NY 10003 >> USA >> http://www.agogme.com >> > > > -- > > 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 Mon Jul 18 14:26:57 2005 From: eric at openly.com (Eric Hellman) Date: Mon Jul 18 14:40:26 2005 Subject: [gcs-pcs-list] Require Version 1.0 OpenURLs in Public Contexts In-Reply-To: References: <1439.165.247.47.109.1118120478.squirrel@165.247.47.109> <4610.165.247.28.221.1118156062.squirrel@165.247.28.221> Message-ID: yes, but I don't think its a good idea. Advantages: 1. could use class for something else. Disadvantages 1. could never use ContextObject in span@title for any other purpose. 2. restriction is another step away from OpenURL Standard, other restrictions we impose for 0.1 compatibility could be (and probably should be) relaxed in future. 3. @title startsWith filter likely to be less efficient than @class equals filter in many DOM implementations 4. would add complexity in situations where ContextObject has already been synthesized for other purposes, such as linking. At 5:03 PM +0200 7/18/05, Alf Eaton wrote: >Coming back to this point, would it be possible >to require in the specification that latent >OpenURLs (in s) begin with 'ctx_ver='? If >that was the case, then the class attribute >wouldn't be necessary at all, which would also >mean that the LOURL [:-)] might be easier to >identify. > >eg >title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> >can use the XPath selector >//span[@title] >and >if (span_title.indexOf('ctx_ver=') == 0) >to see if it's an OpenURL. > >There's no longer any possibility of breaking >existing links, such as to ProQuest, as they >wouldn't be in a in the first place. > >alf. > >On 07 Jun 2005, at 17:20, Eric Hellman wrote: > >>it's the position in the query String that is >>flexible. "url_ver=Z39.88-2004" will appear in >>all valid 1.0 OpenURLs. In other words, you can >>shuffle the order of the token delimited by "&" >>without changing the meaning of the OpenURL. >>"-2003" was a draft version of the standard. >> >> >>At 10:54 AM -0400 6/7/05, Thomas Dukleth wrote: >> >>>7 June 2005 >>> >>> >>>I guess that I misinterpreted the KEV documentation regarding the >>>difference between version 0.1 and version 1.0 OpenURLs as it relates to >>>the required form of the query string. Is the issue that the documented >>>KEV usage is not strictly required for version 1.0 OpenURLs or that even >>>the KEV documentation does not require url_ver=Z39.88-2004 to appear at >>>the beginning of the query string? I assume this is not merely a question >>>of the placement of url_ver=Z39.88-2004 as a required element somewhere in >>>the query string but that url_ver=Z39.88-2004 is not required to appear at >>>in the query string at all for version 1.0 OpenURLs. I also assume the >>>issue is not about whether -2004 appears as part of the value as I have >>>seen -2003 used in examples identified as version 1.0 OpenURLs.?? >>>My tests >>>only ever tested for the presence of url_ver=Z39.88 at the beginning of >>>the query string, ignoring any date modifier. >>> >>>Regardless of where my misinterpretation arose, is there a means to >>>reliably identify version 1.0 OpenURLs as OpenURLs from the information in >>>the query string? >>> >>> >>>Thomas Dukleth >>> >>> >>>Thomas Dukleth >>>Agogme >>>109 E 9th Street, 3D >>>New York, NY 10003 >>>USA >>>http://www.agogme.com >>> >> >> >>-- >> >>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 >> > >_______________________________________________ >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 Tue Jul 19 05:28:22 2005 From: alf at hubmed.org (Alf Eaton) Date: Tue Jul 19 05:51:08 2005 Subject: [gcs-pcs-list] Require Version 1.0 OpenURLs in Public Contexts In-Reply-To: References: <1439.165.247.47.109.1118120478.squirrel@165.247.47.109> <4610.165.247.28.221.1118156062.squirrel@165.247.28.221> Message-ID: <2C3A9D55-2AC5-4335-AAAB-FA79373C08DE@hubmed.org> On 18 Jul 2005, at 20:26, Eric Hellman wrote: > yes, but I don't think its a good idea. > > Advantages: > 1. could use class for something else. It removes a possibly unnecessary extra element. You can always add extra items to the class attribute for other uses. > Disadvantages > 1. could never use ContextObject in span@title for any other purpose. If the ContextObject is there, you should be able to use it for whatever purpose you like. What other purposes are you thinking of? > 2. restriction is another step away from OpenURL Standard, other > restrictions we impose for 0.1 compatibility could be (and probably > should be) relaxed in future. If you mean that restricting ctx_ver to being at the start of the ContextObject is a step away from the standard then fine: it can be anywhere in the string. ctx_ver=Z39.88 is still as good an identifier as class="Z39.88". I couldn't find how to do a startsWith in XPath anyway, so it probably doesn't make any difference where in the string it is. > 3. @title startsWith filter likely to be less efficient than @class > equals filter in many DOM implementations It's not @class equals, it's @class contains. There can be multiple space-separated classnames: if (span.title.indexOf('ctx_ver=Z39.88') != -1) vs class_name = ' ' + span.className + ' '; if (class_name.indexOf(' Z39.88 ') != -1) > 4. would add complexity in situations where ContextObject has > already been synthesized for other purposes, such as linking. Could you explain this a bit more - I'm not sure what this means. alf. > > > At 5:03 PM +0200 7/18/05, Alf Eaton wrote: > >> Coming back to this point, would it be possible to require in the >> specification that latent OpenURLs (in s) begin with >> 'ctx_ver='? If that was the case, then the class attribute >> wouldn't be necessary at all, which would also mean that the LOURL >> [:-)] might be easier to identify. >> >> eg >> >> can use the XPath selector >> //span[@title] >> and >> if (span_title.indexOf('ctx_ver=') == 0) >> to see if it's an OpenURL. >> >> There's no longer any possibility of breaking existing links, such >> as to ProQuest, as they wouldn't be in a in the first place. >> >> alf. From alf at hubmed.org Wed Jul 20 12:00:00 2005 From: alf at hubmed.org (Alf Eaton) Date: Wed Jul 20 12:09:45 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags Message-ID: <7925F0E0-BDD4-4241-91D1-B2AB1F09ECAE@hubmed.org> Output from running Tidy on http:// www.openly.com/openurlref/latent.html : line 90 column 121 - Warning: trimming empty line 90 column 616 - Warning: trimming empty line 112 column 1 - Warning: trimming empty alf. From ross.singer at library.gatech.edu Wed Jul 20 12:19:25 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Jul 20 12:19:36 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags In-Reply-To: <7925F0E0-BDD4-4241-91D1-B2AB1F09ECAE@hubmed.org> References: <7925F0E0-BDD4-4241-91D1-B2AB1F09ECAE@hubmed.org> Message-ID: <42DE798D.6030004@library.gatech.edu> Well that sucks. Alf Eaton wrote: > Output from running Tidy on http:// > www.openly.com/openurlref/latent.html : > > line 90 column 121 - Warning: trimming empty > line 90 column 616 - Warning: trimming empty > line 112 column 1 - Warning: trimming empty > > alf. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From eric at openly.com Wed Jul 20 11:45:28 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 20 12:39:00 2005 Subject: [gcs-pcs-list] Require Version 1.0 OpenURLs in Public Contexts In-Reply-To: <2C3A9D55-2AC5-4335-AAAB-FA79373C08DE@hubmed.org> References: <1439.165.247.47.109.1118120478.squirrel@165.247.47.109> <4610.165.247.28.221.1118156062.squirrel@165.247.28.221> <2C3A9D55-2AC5-4335-AAAB-FA79373C08DE@hubmed.org> Message-ID: We can count on bare ContextObjects containing the string "ctx_ver=Z39.88-2004". So @class(contains) makes disadvantages #2 and #4 disappear. 1. Alf's question about #1 is a deep one about semantics: what are the possible semantics of an OpenURL COinS? (what a good name, I can't help but use it) What are the semantics of an OpenURL link? To be very specific, a COinS "means" that that spot in the HTML document refers in some way to the referent of the CO. OpenURL has been almost universally implemented with these implied semantics- the anchor text/button of the OpenURL is used to label the institution or the resolver, rather than the referent. It would be a real mistake to try to do something different at the present- in other words the content of the SPAN element is available as a spot to add a link and can contain stuff for people without COi. In other words, Author, Title, Year. not Author, Title, Year. which would have different semantics. Another (never seen in the wild) use of a ContextObject would be to indicate a referred-by relationship. (use referent=this and referring entity to indicate works that refer to the present document.) We could add other values for the class attribute these accommodate these use cases, but I think that would be getting ahead of ourselves. 3. contains() is inherently more work than equals(). Moreover, a DOM builder will likely index build an index for the class attribute because of its use in css stylesheets. Eric At 11:28 AM +0200 7/19/05, Alf Eaton wrote: >On 18 Jul 2005, at 20:26, Eric Hellman wrote: > >>yes, but I don't think its a good idea. >> >>Advantages: >>1. could use class for something else. >It removes a possibly unnecessary extra element. You can always add >extra items to the class attribute for other uses. > >>Disadvantages >>1. could never use ContextObject in span@title for any other purpose. >If the ContextObject is there, you should be able to use it for >whatever purpose you like. What other purposes are you thinking of? > >>2. restriction is another step away from OpenURL Standard, other >>restrictions we impose for 0.1 compatibility could be (and probably >>should be) relaxed in future. >If you mean that restricting ctx_ver to being at the start of the >ContextObject is a step away from the standard then fine: it can be >anywhere in the string. ctx_ver=Z39.88 is still as good an >identifier as class="Z39.88". I couldn't find how to do a startsWith >in XPath anyway, so it probably doesn't make any difference where in >the string it is. > >>3. @title startsWith filter likely to be less efficient than @class >>equals filter in many DOM implementations >It's not @class equals, it's @class contains. There can be multiple >space-separated classnames: > >if (span.title.indexOf('ctx_ver=Z39.88') != -1) > >vs > >class_name = ' ' + span.className + ' '; >if (class_name.indexOf(' Z39.88 ') != -1) > >>4. would add complexity in situations where ContextObject has >>already been synthesized for other purposes, such as linking. >Could you explain this a bit more - I'm not sure what this means. > >alf. > >> >> >>At 5:03 PM +0200 7/18/05, Alf Eaton wrote: >> >>>Coming back to this point, would it be possible to require in the >>>specification that latent OpenURLs (in s) begin with >>>'ctx_ver='? If that was the case, then the class attribute >>>wouldn't be necessary at all, which would also mean that the LOURL >>>[:-)] might be easier to identify. >>> >>>eg >>>>>title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> >>>can use the XPath selector >>>//span[@title] >>>and >>>if (span_title.indexOf('ctx_ver=') == 0) >>>to see if it's an OpenURL. >>> >>>There's no longer any possibility of breaking existing links, such >>>as to ProQuest, as they wouldn't be in a in the first place. >>> >>>alf. > >_______________________________________________ >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 daniel.chudnov at yale.edu Wed Jul 20 13:40:21 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jul 20 13:41:03 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags In-Reply-To: <7925F0E0-BDD4-4241-91D1-B2AB1F09ECAE@hubmed.org> References: <7925F0E0-BDD4-4241-91D1-B2AB1F09ECAE@hubmed.org> Message-ID: <20050720174020.GF6924@curtis.med.yale.edu> Alf Eaton wrote, on Wed, Jul 20, 2005 at 06:00:00PM +0200: > > line 90 column 121 - Warning: trimming empty Do you think the spec should say "beware, some tools like tidy might not like your empty spans"? And maybe "here's a config statement for tidy to prevent those warnings, YMMV"? Or do we need to recommend putting something inside spans? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Jul 20 13:50:16 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jul 20 14:02:35 2005 Subject: [gcs-pcs-list] not saying "replace" In-Reply-To: <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> Message-ID: <20050720175015.GG6924@curtis.med.yale.edu> Ross Singer wrote, on Fri, Jul 15, 2005 at 06:44:33PM -0400: > On my train ride home, I thought of: > COinS > > Context > Objects > in > Spans > > Pretty simple, absolutely accurate. +1. Only potential problem is pluralization. If you have many, are they COinSes? Oh, no, "Objects" is plural. Nevermind. There be only COinS. I'm not sure what to say about the simile usage of "data coins". Perhaps the proper thing to do is run it by them, maybe they won't mind anyway. Sure might sound like we're aping them, in any case, though. > coelacanth !. :) -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From Peter.Binkley at ualberta.ca Wed Jul 20 13:55:54 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Wed Jul 20 14:02:36 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags Message-ID: <908893006339C0409519E4065DF3B2491E8326@mailserver.ualibrary.ualberta.ca> A comment seems to be enough to keep Tidy from trimming the empty span. (I'm trying it within HTML-Kit rather than using Tidy natively, though). Maybe it wouldn't be a bad idea to include a comment with a link to the spec anyway, if it doesn't screw anything else up. Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Daniel Chudnov > Sent: Wednesday, July 20, 2005 11:40 AM > To: Alf Eaton > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] HTML Tidy trims empty span tags > > Alf Eaton wrote, on Wed, Jul 20, 2005 at 06:00:00PM +0200: > > > > line 90 column 121 - Warning: trimming empty > > Do you think the spec should say "beware, some tools like > tidy might not like your empty spans"? And maybe "here's a > config statement for tidy to prevent those warnings, YMMV"? > > Or do we need to recommend putting something inside spans? > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Wed Jul 20 15:56:00 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Jul 20 15:54:24 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags In-Reply-To: <908893006339C0409519E4065DF3B2491E8326@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B2491E8326@mailserver.ualibrary.ualberta.ca> Message-ID: <42DEAC50.2090501@library.gatech.edu> Well, problem solved! Thanks, Peter. Binkley, Peter wrote: >A comment seems to be enough to keep Tidy from trimming the empty span. >(I'm trying it within HTML-Kit rather than using Tidy natively, though). >Maybe it wouldn't be a bad idea to include a comment with a link to the >spec anyway, if it doesn't screw anything else up. > >Peter > > > >>-----Original Message----- >>From: gcs-pcs-list-bounces@cipolo.med.yale.edu >>[mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf >>Of Daniel Chudnov >>Sent: Wednesday, July 20, 2005 11:40 AM >>To: Alf Eaton >>Cc: GCS-PCS list >>Subject: Re: [gcs-pcs-list] HTML Tidy trims empty span tags >> >>Alf Eaton wrote, on Wed, Jul 20, 2005 at 06:00:00PM +0200: >> >> >>>line 90 column 121 - Warning: trimming empty >>> >>> >>Do you think the spec should say "beware, some tools like >>tidy might not like your empty spans"? And maybe "here's a >>config statement for tidy to prevent those warnings, YMMV"? >> >>Or do we need to recommend putting something inside spans? >> >> -Dan >> >> >>-- >>Daniel Chudnov >>Yale Center for Medical Informatics >>(203) 737-5789 >>_______________________________________________ >>gcs-pcs-list mailing list >>gcs-pcs-list@cipolo.med.yale.edu >>http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> >> >> >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20050720/c08b2791/attachment.htm From alf at hubmed.org Thu Jul 21 11:20:58 2005 From: alf at hubmed.org (Alf Eaton) Date: Thu Jul 21 11:21:23 2005 Subject: [gcs-pcs-list] HTML Tidy trims empty span tags In-Reply-To: <42DEAC50.2090501@library.gatech.edu> References: <908893006339C0409519E4065DF3B2491E8326@mailserver.ualibrary.ualberta.ca> <42DEAC50.2090501@library.gatech.edu> Message-ID: BTW, I originally noticed this problem when it was mentioned on the Typo mailing list. The newest Typo code stores the date in the title attribute of an empty , eg then the browser processes that with Javascript to generate dates like '3 days ago', which get displayed in the span. The Javascript is currently function show_date_as_local_time() { var spans = document.getElementsByTagName('span'); for (var i=0; i Well, problem solved! Thanks, Peter. > > Binkley, Peter wrote: > > >> A comment seems to be enough to keep Tidy from trimming the empty >> span. >> (I'm trying it within HTML-Kit rather than using Tidy natively, >> though). >> Maybe it wouldn't be a bad idea to include a comment with a link >> to the >> spec anyway, if it doesn't screw anything else up. >> Peter >> >> >> >>> -----Original Message----- >>> From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs- >>> list-bounces@cipolo.med.yale.edu] On Behalf Of Daniel Chudnov >>> Sent: Wednesday, July 20, 2005 11:40 AM >>> To: Alf Eaton >>> Cc: GCS-PCS list >>> Subject: Re: [gcs-pcs-list] HTML Tidy trims empty span tags >>> >>> Alf Eaton wrote, on Wed, Jul 20, 2005 at 06:00:00PM +0200: >>> >>> >>>> line 90 column 121 - Warning: trimming empty >>>> >>>> >>> Do you think the spec should say "beware, some tools like tidy >>> might not like your empty spans"? And maybe "here's a config >>> statement for tidy to prevent those warnings, YMMV"? >>> >>> Or do we need to recommend putting something inside spans? >>> >>> -Dan >>> >>> >>> -- >>> Daniel Chudnov >>> Yale Center for Medical Informatics >>> (203) 737-5789 >>> _______________________________________________ >>> gcs-pcs-list mailing list >>> gcs-pcs-list@cipolo.med.yale.edu >>> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >>> >>> >>> >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> >> >> > _______________________________________________ > 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 Jul 21 13:57:20 2005 From: eric at openly.com (Eric Hellman) Date: Thu Jul 21 14:02:07 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: <20050720175015.GG6924@curtis.med.yale.edu> References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> Message-ID: I've attempted to incorporate as many comments and suggestions into a version of the spec marked "stable version 1.0", and rebranded with the COinS name. http://www.openly.com/coins/ Among other things, I've moved the discussion of the latent openurl application into a separate page, used dan's wording almost verbatim for the discussion of processing, added a comment on the validation of empty span and I've marked it with a creative commons license. The discussion of the last two weeks has been extremely helpful; I hope everyone is comfortable with the result, and I hope I can soon add lots of names to the list of implementing sites/applications 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 ross.singer at library.gatech.edu Thu Jul 21 14:26:25 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Jul 21 14:29:55 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> Message-ID: <42DFE8D1.5000704@library.gatech.edu> So, I'm thinking it might be useful to have a webservice that makes it easier to generate valid z39.88 OpenURLs. I think this would lower the duplication of coding to take a bibliographic input form and actually turn that into an actual COinS (oh my, the grammar!). This service should be able to spit out either KEVs or xml documents, I'd think. I realize that many link resolvers already do this, but there are a couple of disadvantages to this: 1) This becomes a local dependency for development. 2) I'm not sure I want to beat the hell out my local SFX server for this functionality. Does anybody else see any value in this? -Ross. Eric Hellman wrote: > I've attempted to incorporate as many comments and suggestions into a > version of the spec marked "stable version 1.0", and rebranded with > the COinS name. > > http://www.openly.com/coins/ > > Among other things, I've moved the discussion of the latent openurl > application into a separate page, used dan's wording almost verbatim > for the discussion of processing, added a comment on the validation of > empty span and I've marked it with a creative commons license. > > The discussion of the last two weeks has been extremely helpful; I > hope everyone is comfortable with the result, and I hope I can soon > add lots of names to the list of implementing sites/applications > > Eric From Peter.Binkley at ualberta.ca Thu Jul 21 16:39:37 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Thu Jul 21 16:45:06 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 Message-ID: <908893006339C0409519E4065DF3B2491E8330@mailserver.ualibrary.ualberta.ca> Sounds good to me. I've just updated the little Wordpress plugin I wrote. Probably the recently released OCLC code would be easy to adapt: http://www.oclc.org/research/software/openurl/default.htm - I haven't tried it, but it currently echoes the OpenURL in HTML, so it should be the work of moment to make it spit out COinS or XML or KEV. Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Ross Singer > Sent: Thursday, July 21, 2005 12:26 PM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] COinS stable version 1.0 > > So, I'm thinking it might be useful to have a webservice that > makes it easier to generate valid z39.88 OpenURLs. I think > this would lower the duplication of coding to take a > bibliographic input form and actually turn that into an > actual COinS (oh my, the grammar!). > > This service should be able to spit out either KEVs or xml > documents, I'd think. I realize that many link resolvers > already do this, but there are a couple of disadvantages to this: > > 1) This becomes a local dependency for development. > 2) I'm not sure I want to beat the hell out my local SFX > server for this functionality. > > Does anybody else see any value in this? > > -Ross. > > Eric Hellman wrote: > > > I've attempted to incorporate as many comments and > suggestions into a > > version of the spec marked "stable version 1.0", and rebranded with > > the COinS name. > > > > http://www.openly.com/coins/ > > > > Among other things, I've moved the discussion of the latent openurl > > application into a separate page, used dan's wording almost > verbatim > > for the discussion of processing, added a comment on the > validation of > > empty span and I've marked it with a creative commons license. > > > > The discussion of the last two weeks has been extremely helpful; I > > hope everyone is comfortable with the result, and I hope I can soon > > add lots of names to the list of implementing sites/applications > > > > Eric > > _______________________________________________ > 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 Thu Jul 21 19:29:12 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Jul 21 19:49:16 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> Message-ID: <875B7A43-43A8-4ACE-BA41-256411BCEC07@yale.edu> On Jul 21, 2005, at 1:57 PM, Eric Hellman wrote: > I've attempted to incorporate as many comments and suggestions into > a version of the spec marked "stable version 1.0", and rebranded > with the COinS name. Cool! But... - It says "for each selected SPAN replace, extract the value of the TITLE attribute." ITYM "for each selected SPAN, extract the value..." - The title got LONGER! How'd that happen? Shorter better! To help grease the wheels I've written a quick blog thing. http://curtis.med.yale.edu/dchud/log/project/groupware/introducing- coins I'll update the "resolvable" page and the pyblosxom plugin soon. I'm leaving for two weeks' vacation (will be waaay offline) saturday, though, so it might not happen until after that. Jeremy F. is also an admin of this list, and can deal with administrivia. Eric: thanks for driving this train. -Dan From alf at hubmed.org Thu Jul 21 20:06:06 2005 From: alf at hubmed.org (Alf Eaton) Date: Thu Jul 21 20:06:14 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> Message-ID: Is this format intended just for HTML, or for XHTML as well? Either way, it would be nice to have the elements and attributes in lowercase in the examples, seeing as they're likely to be copy-pasted elsewhere. alf. On 21 Jul 2005, at 19:57, Eric Hellman wrote: > I've attempted to incorporate as many comments and suggestions into > a version of the spec marked "stable version 1.0", and rebranded > with the COinS name. > > http://www.openly.com/coins/ > > Among other things, I've moved the discussion of the latent openurl > application into a separate page, used dan's wording almost > verbatim for the discussion of processing, added a comment on the > validation of empty span and I've marked it with a creative commons > license. > > The discussion of the last two weeks has been extremely helpful; I > hope everyone is comfortable with the result, and I hope I can soon > add lots of names to the list of implementing sites/applications > > 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 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Thu Jul 21 21:21:19 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Jul 21 21:27:29 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> Message-ID: <49567.WlxAAVUBUAA=.1121995279.squirrel@mail.library.gatech.edu> I wondered about this too. In WAG the Dog, the span and attributes are lowercase. -Ross. On Thu, July 21, 2005 8:06 pm, Alf Eaton wrote: > Is this format intended just for HTML, or for XHTML as well? > > Either way, it would be nice to have the elements and attributes > in > lowercase in the examples, seeing as they're likely to be > copy-pasted > elsewhere. > > alf. > > On 21 Jul 2005, at 19:57, Eric Hellman wrote: > >> I've attempted to incorporate as many comments and suggestions >> into >> a version of the spec marked "stable version 1.0", and rebranded >> with the COinS name. >> >> http://www.openly.com/coins/ >> >> Among other things, I've moved the discussion of the latent >> openurl >> application into a separate page, used dan's wording almost >> verbatim for the discussion of processing, added a comment on >> the >> validation of empty span and I've marked it with a creative >> commons >> license. >> >> The discussion of the last two weeks has been extremely helpful; >> I >> hope everyone is comfortable with the result, and I hope I can >> soon >> add lots of names to the list of implementing sites/applications >> >> 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 >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > ---------------------------------------------------------------------- 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 Fri Jul 22 13:26:37 2005 From: eric at openly.com (Eric Hellman) Date: Fri Jul 22 13:40:38 2005 Subject: [gcs-pcs-list] COinS stable version 1.0 In-Reply-To: <875B7A43-43A8-4ACE-BA41-256411BCEC07@yale.edu> References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> <875B7A43-43A8-4ACE-BA41-256411BCEC07@yale.edu> Message-ID: At 7:29 PM -0400 7/21/05, Daniel Chudnov wrote: >- It says "for each selected SPAN replace, extract the value of the >TITLE attribute." > ITYM "for each selected SPAN, extract the value..." fixed > >- The title got LONGER! How'd that happen? Shorter better! shortened At 2:06 AM +0200 7/22/05, Alf Eaton wrote: >Is this format intended just for HTML, or for XHTML as well? > >Either way, it would be nice to have the elements and attributes in >lowercase in the examples, seeing as they're likely to be >copy-pasted elsewhere. changed to lower case, note added about xhtml. 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 Fri Jul 22 17:10:51 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Jul 22 17:16:03 2005 Subject: [gcs-pcs-list] (half) updated tools Message-ID: This simple pyblosxom plugin now renders COinS: http://curtis.med.yale.edu/dchud/log/project/groupware/coins ...but it can and will be made much simpler. Also tweaked the original bookmarklet page: http://curtis.med.yale.edu/dchud/resolvable/index2.cgi ...and its newer COinSish bookmarklets work on fx on linux and osx but not safari. Peter B.: I think the bookmarklet would work on your blog entry if you change the span's class attribute to be "Z3988", not "Z39.88" Beyond just a dumb plugin for publishing (dumb in that it makes the user be smart about formatting most of a CO), it would be nice to have a drop-in web UI widget (in the vein of kupu or similar... there are several I think) that would provide a friendly way to enter these CO thingies. Like SFX's OpenURL generator form, or Peter B.'s wp plugin, but with a little pulldown for a handful of oft-used format types and appropriate boxes and such that would pop up depending on the type. And javascripty so it would work nice and cleanly and compactly, and leave a COinS in its wake. Oh... and be re-editable from an existing COinS. But... vacation beckons. :P -dc From eric at openly.com Fri Jul 22 18:39:26 2005 From: eric at openly.com (Eric Hellman) Date: Fri Jul 22 18:54:08 2005 Subject: [gcs-pcs-list] oCOinS.info In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> <875B7A43-43A8-4ACE-BA41-256411BCEC07@yale.edu> Message-ID: there's now a dedicated domain for COinS- http://oCOinS.info/ so the URL can be propagated without Openly Informatics branding. 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 eric at openly.com Wed Jul 27 01:55:04 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 27 01:55:14 2005 Subject: [gcs-pcs-list] more oCOinS.info In-Reply-To: References: <20050715214349.GD23382@curtis.med.yale.edu> <1485.68.223.17.213.1121467473.squirrel@mail.library.gatech.edu> <20050720175015.GG6924@curtis.med.yale.edu> <875B7A43-43A8-4ACE-BA41-256411BCEC07@yale.edu> Message-ID: Assorted cleanup, prettifying and grammar checking has been done on the spec. http://www.ocoins.info (as opposed to http://ocoins.info ) no longer goes to openly web page It's time to start spreading the word. If you participate in an email list (other than this one), now is the time to post. If you blog, now is the time to blog it. on the way- example pages and a generator application. -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From ehs at pobox.com Wed Jul 27 16:03:35 2005 From: ehs at pobox.com (Edward Summers) Date: Wed Jul 27 16:04:58 2005 Subject: [gcs-pcs-list] microformats Message-ID: <9CA3F183-E365-4E52-BBBA-89F409C2CE48@pobox.com> Thom Hickey's blog [1] reminded me today to ask if anyone has thought about positioning COinS as a microformat [2]. I think doing this could very well generate some usage outside our cloistered library world. //Ed [1] http://outgoing.typepad.com/outgoing/2005/07/microformats_an.html [2] http://www.microformats.org/ From eric at openly.com Wed Jul 27 17:03:38 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 27 17:03:54 2005 Subject: [gcs-pcs-list] microformats In-Reply-To: <9CA3F183-E365-4E52-BBBA-89F409C2CE48@pobox.com> References: <9CA3F183-E365-4E52-BBBA-89F409C2CE48@pobox.com> Message-ID: An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20050727/530c2f27/attachment.htm From ehs at pobox.com Wed Jul 27 17:15:11 2005 From: ehs at pobox.com (Edward Summers) Date: Wed Jul 27 17:14:55 2005 Subject: [gcs-pcs-list] microformats In-Reply-To: References: <9CA3F183-E365-4E52-BBBA-89F409C2CE48@pobox.com> Message-ID: <9D67F15E-CA4D-4C53-A6C5-412426ACBB0F@pobox.com> > The long answer is that someone- (you?) Heh, I really set myself up for that one eh? I've made a note to look into it, and will report back if I get any bites. //Ed From ehs at pobox.com Wed Jul 27 18:03:02 2005 From: ehs at pobox.com (Edward Summers) Date: Wed Jul 27 18:02:44 2005 Subject: [gcs-pcs-list] #microformats Message-ID: I popped over into #microformats on freenode and got Dan Connolly's [1] ear for a bit. He seemed interested, and suggested posting to the microformats-dev list. He did note that the & in should be encoded: //Ed [1] http://www.w3.org/People/Connolly/ [2] http://microformats.org/mailman/listinfo/microformats-dev/ From eric at openly.com Wed Jul 27 18:33:18 2005 From: eric at openly.com (Eric Hellman) Date: Wed Jul 27 18:33:30 2005 Subject: [gcs-pcs-list] #microformats In-Reply-To: References: Message-ID: there's a note about this in the fine print at the bottom of the page. do people think it's clearer this way or should we ad the html escaping? At 5:03 PM -0500 7/27/05, Edward Summers wrote: >I popped over into #microformats on freenode and got Dan Connolly's >[1] ear for a bit. He seemed interested, and suggested posting to >the microformats-dev list. He did note that the & in > >title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> > >should be encoded: > >title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> > >//Ed > >[1] http://www.w3.org/People/Connolly/ >[2] http://microformats.org/mailman/listinfo/microformats-dev/ >_______________________________________________ >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 ross.singer at library.gatech.edu Wed Jul 27 18:39:09 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Jul 27 18:39:22 2005 Subject: [gcs-pcs-list] #microformats In-Reply-To: References: Message-ID: <53125.WlxAAVUBUAA=.1122503949.squirrel@mail.library.gatech.edu> I think html escaping makes perfect sense in this case. -Ross. On Wed, July 27, 2005 6:33 pm, Eric Hellman wrote: > there's a note about this in the fine print at the bottom of the > page. do people think it's clearer this way or should we ad the > html > escaping? > > > At 5:03 PM -0500 7/27/05, Edward Summers wrote: >>I popped over into #microformats on freenode and got Dan >> Connolly's >>[1] ear for a bit. He seemed interested, and suggested posting to >>the microformats-dev list. He did note that the & in >> >>>title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> >> >>should be encoded: >> >>>title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"> >> >>//Ed >> >>[1] http://www.w3.org/People/Connolly/ >>[2] http://microformats.org/mailman/listinfo/microformats-dev/ >>_______________________________________________ >>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 > > ---------------------------------------------------------------------- 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 stoub at yahoo.com Thu Jul 28 22:59:09 2005 From: stoub at yahoo.com (Steve Toub) Date: Thu Jul 28 22:59:16 2005 Subject: [gcs-pcs-list] Improving marketing copy on http://ocoins.info/ Message-ID: <42E99B7D.4070700@yahoo.com> Hi COinS fans-- Someone in senior management at my organization saw the announcement of the stable spec to liblicense-l and forwarded it to other senior managers who forwarded to the team that guides our OpenURL resolution service. When I chimed in and said "This is A Good Thing; what can we do to pressure vendors to support it or embed COinS in our own services?" the project manager asked why it was a good thing. The value wasn't apparent to her from the announcement or the http://ocoins.info/ site. I gave an explanation (included below) which pointed her to the announcement on Dan's work log and the Ariadne article and she "got it" by looking at those documents. She thought the screenshots in the Ariadne article were particularly effective in communicating the value of the spec. I'm wondering if http://ocoins.info/ could excerpt, paraphrase or link into those two documents in the Introduction? --SET This page does a better job at marketing: http://curtis.med.yale.edu/dchud/log/project/groupware/introducing-coins In a nutshell, the OpenURL COinS meme (the separation of the base URL from the context object) is a good thing because it provides richer, easier functionality for end-users with very minimal cost to vendors. * it provides a low-barrier way for less sophicated vendors to include OpenURLs (inserting one line of HTML with information that is already on the page) while avoiding costs of a dynamic customization system for inserting base URLs for each customer. * it reduces friction involved with reusing citations/items for user-defined purposes that are go beyond what we control in the UC-eLinks service menu (e.g., post to my blog; publish to my course web page). The loose coupling opens doors--empowers users--to a wide variety of grassroots uses by toolmakers (those who write bookmarklets, browser extensions, GreaseMonkey scripts, etc.). Those tools aren't widely adopted now, but having the COinS in place is a precondition for wider adoption. For a fuller description and screenshots of how value is added, see: http://www.ariadne.ac.uk/issue43/chudnov/ From T.Hammond at nature.com Fri Jul 29 06:25:57 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Fri Jul 29 06:26:03 2005 Subject: [gcs-pcs-list] FW: Connotea Does OpenURL Message-ID: <125F7834E11A5741A7D79412EE3504F91D08C866@UK1APPS2.mpl.root-domain.org> Hi Guys: Forwarding this here just in case any of you missed it on the OpenURL list. And one error in the message below - should have been rfr_id = info:sid/connotea.org:Connotea of course. (Herbert doesn't hang out here does he? Oh the shame. ;) Cheers, Tony -----Original Message----- From: Hammond, Tony Sent: 29 July 2005 10:01 To: 'openurl@caltech.edu' Subject: Connotea Does OpenURL Hi All: I just wanted to announce that Nature Publishing Group's social bookmarking tool Connotea (a kind of scientific del.icio.us) now supports outbound OpenURL links. See the news release here http://www.connotea.org/news#2005-07-27 OpenURL Links for Your Articles And Books When a link is bookmarked Connotea seeks to query authority sources for metadata for both journal articles and also books (on Amazon links). Users can register an OpenURL resolver with Connotea (and optional display label for that resolver) and Connotea will build OpenURL links whenever it has the requisite metadata. This link is presented along with any other links, e.g. PMID, DOI. The OpenURL links are hybrid (1.0/0.1) links - see below - so should work with most OpenURL resolvers. We have tested this against a number of public link resolvers but would very much appreciate any feedback on this functionality - especially any problems that may be encountered. Note, you do have to open up a user account in order to register an OpenURL resolver and so be able to see OpenURL links. One feature (and agin feedback is welcome) that we have added to our OpenURL links is to include the requester ID by using the Connotea user name, e.g. req_id = http://www.connotea.org/user/tony The service ID is (as expected) rfr_id = connotea.org:Connotea Cheers, Tony Tony Hammond New Technology, Nature Publishing Group 4 Crinan Street, London N1 9XW, UK tel:+44-20-7843-4659 mailto:t.hammond@nature.com ### Recognition of commensal microflora by toll-like receptors is required for intestinal homeostasis. (info) Seth Rakoff-Nahoum et al. Cell 118 (2), 229-41 (22 Jul 2004) OhioLINK Resolver | PMID: 15260992 | doi:10.1016/j.cell.2004.07.002 Role of TLR's in maintaining commensal organisms in gut Posted by NinaS to gut flora TLR on Fri Jul 29 2005 at 03:06 UTC http://olinks.ohiolink.edu/olinks.php?ctx_ver=Z39.88-2004&ctx_enc=info%3Aofi %2Fenc%3AUTF-8&url_ver=Z39.88-2004&url_ctx_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx% 3Actx&rfr_id=info%3Asid%2Fconnotea.org%3AConnotea&req_id=http%3A%2F%2Fwww.co nnotea.org%2Fuser%2Ftony&rft_id=info%3Apmid%2F15260992&rft_id=info%3Adoi%2F1 0.1016%2Fj.cell.2004.07.002&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajourn al&rft.volume=118&rft.atitle=Recognition+of+commensal+microflora+by+toll-lik e+receptors+is+required+for+intestinal+homeostasis.&rft.date=2004-07-22&rft. aulast=Rakoff-Nahoum&rft.auinit=S&rft.epage=241&rft.spage=229&rft.issn=0092- 8674&rft.jtitle=Cell&rft.genre=article&rft.issue=2&sid=connotea.org%3AConnot ea&id=info%3Apmid%2F15260992&volume=118&aulast=Rakoff-Nahoum&date=2004-07-22 &atitle=Recognition+of+commensal+microflora+by+toll-like+receptors+is+requir ed+for+intestinal+homeostasis.&issn=0092-8674&spage=229&issue=2&genre=articl e&auinit=S&title=Cell&epage=241 ******************************************************************************** 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 Jul 29 19:34:45 2005 From: alf at hubmed.org (Alf Eaton) Date: Fri Jul 29 19:34:52 2005 Subject: [gcs-pcs-list] new Greasemonkey script Message-ID: <03BCB1DC-D955-471A-86CD-40D6CCD2AEC8@hubmed.org> Here's a new Greasemonkey script for processing COinS: http://alf.hubmed.org/openurlcoins.user.js It's very simple and doesn't try to convert from 1.0 to 0.1, but it seems to be working ok on , Wikipedia Booksources pages and abstract pages in HubMed. As a default setting, it links to the SFX demo server to resolve the OpenURLs. alf. From eric at openly.com Sun Jul 31 00:07:34 2005 From: eric at openly.com (Eric Hellman) Date: Sun Jul 31 00:07:41 2005 Subject: [gcs-pcs-list] ocoins.info updates In-Reply-To: References: <9CA3F183-E365-4E52-BBBA-89F409C2CE48@pobox.com> Message-ID: If you haven't seen it, the biggest news is CiteBase has added COinS support. Also Alf obliquely mentioned it in his post, but HubMed is another COinS enabled site. I've had a lot of great suggestions for the ocoins.info web site, and I've had a chance to update it. 1. Clarified motivation for span, and syntax for class 2. made capitalized Z a MUST 3. Fixed other nits noted by Alf Eaton 4. added links, including citebase, hubmed, and Alf Eaton's Greasemonky script 5. Lifted abstract from Dan Chudnov's introducing coins page 6. Added index 7. re-linked to brief CO guides. -- 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