From lists at hubmed.org Sat Apr 1 21:52:54 2006 From: lists at hubmed.org (Alf Eaton) Date: Sat Apr 1 21:56:15 2006 Subject: [gcs-pcs-list] unAPI gauntlet thrown down: why extensibility. In-Reply-To: <4DE7C025-D93F-444F-AAAE-4FD1BF879726@hubmed.org> References: <4EA412B0-364E-47DF-B9D8-9AF22DC84D12@yale.edu> <20060330002353.GH13803@sildin.med.yale.edu> <4DE7C025-D93F-444F-AAAE-4FD1BF879726@hubmed.org> Message-ID: <9A1AF2CF-5428-4EF9-9ECF-0A2CB6642B1B@hubmed.org> Here's a possible use for namespaced XML: you could put a unAPI service description into the head of an XHTML page... I can imagine that could be quite useful, but I don't know if would really be any easier than calling the unapi service in the background to get the same information. alf. From ehs at POBOX.COM Tue Apr 4 17:43:27 2006 From: ehs at POBOX.COM (Edward Summers) Date: Tue Apr 4 17:44:03 2006 Subject: [gcs-pcs-list] citation microformat irc meeting Message-ID: who: anyone interested in citation data on the web what: Citation Microformat IRC Meetup when: April 9th, 19:00 GMT where: #microformats on freenode.net why: Off and on for the past year there has been discussion in the microformats.org community about establishing a microformat for citations. The effort is similar to ocoins [1] in that both are embedding citation data in HTML so that it can be easily repurposed. The microformats community has a broad base, and includes influential members that have had a significant amount of experience with organizations like the w3c. In fact even Bill Gates and Tim O'Reilly were caught recently talking about microformats in a public forum [2]. Unfortunately here has been very little involvement from people inside the library technology community...people who have had significant experience working with citation data. A few of us on gcs-pcs have lobbied pretty hard for a microformat that draws upon the OpenURL standard...which hasn't been ruled out--but we haven't been successful in pushing it completely through. A draft is likely to be written in the coming months which is being spearheaded by a guy named Brian Suda. Brian is organizing a meeting of the minds in IRC and anyone who has any interest is more than welcome to drop in. Just thought I should let people know on here given the background of everyone on the list. //Ed [1] http://microformats.org/blog/2006/03/20/bill-gates-at-mix06-we- need-microformats/ [2] http://microformats.org/wiki/citation From nhoebel at stanford.edu Tue Apr 4 18:23:07 2006 From: nhoebel at stanford.edu (Nancy Hoebelheinrich) Date: Tue Apr 4 18:23:32 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: Message-ID: <200604042223.k34MN7mw017839@smtp-roam.Stanford.EDU> Those interested in the topic of citation data on the web might find it helpful to look at the IMS Global specification for Resource List Interoperability which specifies an information model, best practice & interoperability guide, conformance requirements and xml binding for resource or "reading" lists including citations based on OpenURL. See http://www.imsglobal.org/rli/index.html . While this spec hasn't yet been tested much, it might prove helpful for the discussions at least. And, if it works for those trying to establish some sort of specification, that would be wonderful! Feedback on the spec itself is also greatly appreciated by IMS and can be directed to this url: http://www.imsglobal.org/problemtracking/index.cfm. Nancy Nancy J. Hoebelheinrich Metadata Coordinator Digital Library Systems and Services Stanford University Libraries / Academic InfoResources Stanford, CA 94305-8408 nhoebel@stanford.edu voice: 650-725-6843 fax: 650-725-0547 -----Original Message----- From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf Of Edward Summers Sent: Tuesday, April 04, 2006 2:43 PM To: gcs-pcs-list@cipolo.med.yale.edu Subject: [gcs-pcs-list] citation microformat irc meeting who: anyone interested in citation data on the web what: Citation Microformat IRC Meetup when: April 9th, 19:00 GMT where: #microformats on freenode.net why: Off and on for the past year there has been discussion in the microformats.org community about establishing a microformat for citations. The effort is similar to ocoins [1] in that both are embedding citation data in HTML so that it can be easily repurposed. The microformats community has a broad base, and includes influential members that have had a significant amount of experience with organizations like the w3c. In fact even Bill Gates and Tim O'Reilly were caught recently talking about microformats in a public forum [2]. Unfortunately here has been very little involvement from people inside the library technology community...people who have had significant experience working with citation data. A few of us on gcs-pcs have lobbied pretty hard for a microformat that draws upon the OpenURL standard...which hasn't been ruled out--but we haven't been successful in pushing it completely through. A draft is likely to be written in the coming months which is being spearheaded by a guy named Brian Suda. Brian is organizing a meeting of the minds in IRC and anyone who has any interest is more than welcome to drop in. Just thought I should let people know on here given the background of everyone on the list. //Ed [1] http://microformats.org/blog/2006/03/20/bill-gates-at-mix06-we- need-microformats/ [2] http://microformats.org/wiki/citation _______________________________________________ gcs-pcs-list mailing list gcs-pcs-list@cipolo.med.yale.edu http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From yee at berkeley.edu Tue Apr 4 20:53:09 2006 From: yee at berkeley.edu (Raymond Yee) Date: Tue Apr 4 20:56:26 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: References: Message-ID: <443314F5.8050307@berkeley.edu> Ed, Thanks for letting us know about the irc meeting. Ed, will you be on the irc? Too bad that the meeting is on a weekend.... Are there some specific issues that we should be thinking about as folks in the library technology community if we participate in this discussion? Do you think that we should continue to push hard for an OpenURL-based microformat? If you had your druthers, what do you think should be the microformat standard for citations? Anything we can do to support people who will be attending? -Raymond Edward Summers wrote: > who: anyone interested in citation data on the web > what: Citation Microformat IRC Meetup > > when: April 9th, 19:00 GMT > where: #microformats on freenode.net > why: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060404/9089a21f/smime.bin From bdarcus.lists at gmail.com Tue Apr 4 21:24:10 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Tue Apr 4 21:25:13 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: <443314F5.8050307@berkeley.edu> References: <443314F5.8050307@berkeley.edu> Message-ID: On 4/4/06, Raymond Yee wrote: > Are there some specific issues that we should be thinking about as folks > in the library technology community if we participate in this > discussion? Do you think that we should continue to push hard for an > OpenURL-based microformat? If you had your druthers, what do you think > should be the microformat standard for citations? FWIW, I think this strawman is likely to be a basis for discussion, not because it's perfect, but because it's OK, and it's concrete: Without repeating the argument about this on the microformat list, I remain unconvinced of why we'd want to model a microformat on OpenURL (or for that matter, the IMS stuff). Bruce From daniel.chudnov at yale.edu Wed Apr 5 03:01:39 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 5 03:01:41 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt Message-ID: <20060405070139.GA14541@sildin.med.yale.edu> I've attempted to rewrite the unAPI spec: http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html It's been a struggle to make sense of the last several threads. I don't know that I have at all, and I'm sorry if my attitude has made the process more difficult. That said, this rewrite attempts to accomplish several things: - it is substantially shorter (the spec itself is actually just 1.5 pages now) - it tightens up language (no more confusion about "metadata" vs. "objects"... it's objects all the way down :) - it simplifies the formats list to just two elements with attributes for uri, name, and type, and doesn't repeat the definition - it provides a corresponding informative rng schema - it elides extraneous words (maybe some remain :) - it renames the informative section to "Notes" and expands it to newly include: - a complete example, with links, using unapi.info/news and Peter's wordpress unAPI plugin - the rng schema - a document history section - updated contributor list (thanks Graham (not the newborn)!) The more I read and reread the recent threads, the more likely it seemed to me that Brutal Simplicity (tm) is the best way to encourage unAPI implementations. In this rewrite, there is no namespace, no extensibility model, no placeholder for future expansion. There are only two elements in the formats list schema (as suggested, more or less, by Bruce and Alf). The informative schema only says that these two elements and their attributes are required... somebody could add stuff to this if they wanted; the spec doesn't say that, but it also doesn't say not to. If you want to search, use opensearch or sru. If you want to harvest, use oai. If you want feeds, use rss/atom. If you want to compose context-sensitive services, use openurl. If you want to give descriptions of diverse services on the server, use zeerex. If you want to co-publish discretely identified objects in both HTML pages and disparate bare objects formats, use unAPI. I know that by proposing this rewrite I'm not exactly following the voting process but -- to be honest -- the process feels a little played out just now, right when we're almost done. I take full responsibility for that. Hopefully this rewrite will hit a sweetspot of sorts that feels emergent from recent discussion (or, at least, here it is, 3am EST and I'm telling myself it's emergent!) and get us revved up to resolve the niggling smaller issues, finish this thing, and call it a spec. Maybe someday some group of unAPI implementors will want to grow the thing with introspection and a snazzy extensibility model. Let's not guess at how to do that now... at least we won't do it incorrectly. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From bdarcus.lists at gmail.com Wed Apr 5 08:14:20 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Wed Apr 5 08:15:22 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: <20060405070139.GA14541@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: On 4/5/06, Daniel Chudnov wrote: > ... There are only > two elements in the formats list schema (as suggested, more or less, by > Bruce and Alf). The informative schema only says that these two elements > and their attributes are required... Question: Do you mean to say that one must include one-or-more (+) format elements in the response? Right now the schema says zero-or-more (*), which woud suggest this would be valid: Bruce From daniel.chudnov at yale.edu Wed Apr 5 08:55:17 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 5 08:55:19 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: <20060405125516.GA15351@sildin.med.yale.edu> Bruce D'Arcus wrote, on Wed, Apr 05, 2006 at 08:14:20AM -0400: > On 4/5/06, Daniel Chudnov wrote: > > > ... There are only > > two elements in the formats list schema (as suggested, more or less, by > > Bruce and Alf). The informative schema only says that these two elements > > and their attributes are required... > > Do you mean to say that one must include one-or-more (+) format > elements in the response? Right now the schema says zero-or-more (*), > which woud suggest this would be valid: > > Yes. I don't know if it's right, but I wouldn't know why not: http://opa.onebiglibrary.net/ We have a issue remaining on the meaning of UNAPI lists. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Wed Apr 5 09:16:30 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Apr 5 09:19:54 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: <20060405070139.GA14541@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: On 05 Apr 2006, at 03:01, Daniel Chudnov wrote: > I've attempted to rewrite the unAPI spec: > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html Here are my three thoughts/attempts at simplification: To be consistent with other microformats, the should be an . This means that a parser will read whatever's in the title attribute and ignore the visible text, which is how the spec works now. Ideally it would be , but as we said at the start, that's going to make some unclickable links show up if there's text in the anchor tag. Using class="unapi-uri" seems to make the markup less re-usable. Perhaps either "uri unapi", so anything else looking for class="uri" can use it, or drop the "unapi" altogether. If all that's going to be in the responses is a list of formats, and only one URI is going to be requested at a time--which is where the spec stands now--it would be a lot easier just to use a tab-separated plain text response. I can't see anything that wouldn't fit in that, particularly if you leave the URI out of the resposne (as it doesn't seem particularly useful - the client will already know which URI it asked for). alf. From bdarcus.lists at gmail.com Wed Apr 5 09:42:24 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Wed Apr 5 09:43:31 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: On 4/5/06, Alf Eaton wrote: > Here are my three thoughts/attempts at simplification: I agree with the first two, and am agnostic about the third. I say the class attribute should drop the openuri altogether. A uri is a uri, no? > To be consistent with other microformats, the should be an > . This means that a parser will read whatever's in the title > attribute and ignore the visible text, which is how the spec works > now. Ideally it would be , but as we said at the start, > that's going to make some unclickable links show up if there's text > in the anchor tag. > > Using class="unapi-uri" seems to make the markup less re-usable. > Perhaps either "uri unapi", so anything else looking for class="uri" > can use it, or drop the "unapi" altogether. > > If all that's going to be in the responses is a list of formats, and > only one URI is going to be requested at a time--which is where the > spec stands now--it would be a lot easier just to use a tab-separated > plain text response. I can't see anything that wouldn't fit in that, > particularly if you leave the URI out of the resposne (as it doesn't > seem particularly useful - the client will already know which URI it > asked for). > > alf. > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From yee at berkeley.edu Wed Apr 5 10:08:10 2006 From: yee at berkeley.edu (Raymond Yee) Date: Wed Apr 5 10:11:28 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: References: <443314F5.8050307@berkeley.edu> Message-ID: <4433CF4A.1070409@berkeley.edu> Thanks, Bruce, for the link. Is http://microformats.org/discuss/mail/microformats-discuss/2006-March/thread.html#3472 the main discussion on the microformat list to which you refer? -Raymond Bruce D'Arcus wrote: > On 4/4/06, Raymond Yee wrote: > > >> Are there some specific issues that we should be thinking about as folks >> in the library technology community if we participate in this >> discussion? Do you think that we should continue to push hard for an >> OpenURL-based microformat? If you had your druthers, what do you think >> should be the microformat standard for citations? >> > > FWIW, I think this strawman is likely to be a basis for discussion, > not because it's perfect, but because it's OK, and it's concrete: > > > > Without repeating the argument about this on the microformat list, I > remain unconvinced of why we'd want to model a microformat on OpenURL > (or for that matter, the IMS stuff). > > Bruce > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060405/b437b7e1/smime.bin From bdarcus.lists at gmail.com Wed Apr 5 10:14:13 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Wed Apr 5 10:15:16 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: <4433CF4A.1070409@berkeley.edu> References: <443314F5.8050307@berkeley.edu> <4433CF4A.1070409@berkeley.edu> Message-ID: On 4/5/06, Raymond Yee wrote: > Thanks, Bruce, for the link. Is > http://microformats.org/discuss/mail/microformats-discuss/2006-March/thread.html#3472 > the main discussion on the microformat list to which you refer? Yes. Bruce From daniel.chudnov at yale.edu Wed Apr 5 15:56:28 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 5 15:56:30 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: <20060405195628.GF15372@sildin.med.yale.edu> Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: > > To be consistent with other microformats, the should be an > . This means that a parser will read whatever's in the title > attribute and ignore the visible text, which is how the spec works > now. This seems a trivial change to make. If i'm reading the HTML specs correctly, you can do anything inside an abbr that you can do inside a span, right? If somebody who understands the spec better could verify that this is true, I can go along with switching. How is the behavior you describe any different from span-driven behavior? > Using class="unapi-uri" seems to make the markup less re-usable. > Perhaps either "uri unapi", so anything else looking for class="uri" > can use it, or drop the "unapi" altogether. I can live with any of these. An "endorsed" microformat for class="uri" would be ideal, as we could simply remove it from unAPI (and it would really be a one-page spec!) but last I checked, the folks on uf-discuss are not interested. > If all that's going to be in the responses is a list of formats, and > only one URI is going to be requested at a time--which is where the > spec stands now--it would be a lot easier just to use a tab-separated > plain text response. As I tried to indicate (my apologies for perhaps not making sense so late at night), by not formally specifying the schema, we leave the door open a bit for people to put other information into unAPI responses. Having the extra structure in place to support that seems a worthy reason to use xml or json, and people here preferred xml. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Apr 5 15:57:57 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 5 15:57:59 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> Message-ID: <20060405195757.GG15372@sildin.med.yale.edu> Bruce D'Arcus wrote, on Wed, Apr 05, 2006 at 09:42:24AM -0400: > > I agree with the first two, and am agnostic about the third. I say the > class attribute should drop the openuri altogether. A uri is a uri, > no? I don't understand what you mean. What "openuri"? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From fawcett at uwindsor.ca Wed Apr 5 16:34:04 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Wed Apr 5 16:34:26 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: <20060405195628.GF15372@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> Message-ID: <443429BC.4040405@uwindsor.ca> On 4/5/2006 3:56 PM, Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: > >> To be consistent with other microformats, the should be an >> . This means that a parser will read whatever's in the title >> attribute and ignore the visible text, which is how the spec works >> now. >> > This seems a trivial change to make. If i'm reading the HTML specs > correctly, you can do anything inside an abbr that you can do inside a > span, right? If somebody who understands the spec better could verify > that this is true, I can go along with switching. > You're right there, Dan -- the HTML grammars present ABBR and SPAN as very similar structures. But Google tells me that this is a microformat best-practice: "Finally, if the format of the data according to the original schema is too long and/or not human-friendly, use || instead of a generic structural element, and place the literal data into the 'title' attribute (where abbr expansions go), and the more brief and human readable equivalent into the element itself. " -- http://microformats.org/wiki/hatom#Semantic_XHTML_Design_Principles Graham From lists at hubmed.org Wed Apr 5 16:35:35 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Apr 5 16:38:52 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: <20060405195628.GF15372@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> Message-ID: On 05 Apr 2006, at 15:56, Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: >> >> To be consistent with other microformats, the should be an >> . This means that a parser will read whatever's in the title >> attribute and ignore the visible text, which is how the spec works >> now. > > This seems a trivial change to make. If i'm reading the HTML specs > correctly, you can do anything inside an abbr that you can do inside a > span, right? If somebody who understands the spec better could verify > that this is true, I can go along with switching. > > How is the behavior you describe any different from span-driven > behavior? With the standard microformats, data means that the value of x is "data", whereas data means that the value of x is "actual data". >> Using class="unapi-uri" seems to make the markup less re-usable. >> Perhaps either "uri unapi", so anything else looking for class="uri" >> can use it, or drop the "unapi" altogether. > > I can live with any of these. An "endorsed" microformat for > class="uri" > would be ideal, as we could simply remove it from unAPI (and it would > really be a one-page spec!) but last I checked, the folks on uf- > discuss > are not interested. The endorsed microformat for URI would presumably be the same as for URL, which is . The problem is still that of non- clickable URIs, so it might be worth trying again... I'll send a post to the list. alf. From ehs at POBOX.COM Wed Apr 5 17:19:47 2006 From: ehs at POBOX.COM (Edward Summers) Date: Wed Apr 5 17:20:19 2006 Subject: [gcs-pcs-list] citation microformat irc meeting In-Reply-To: <4432FFB6.9030509@berkeley.edu> References: <4432FFB6.9030509@berkeley.edu> Message-ID: On Apr 4, 2006, at 6:22 PM, Raymond Yee wrote: > Ed, will you be on the irc? Yes, I should be there unless something else comes up at the last minute. I hope you can make it...it is unfortunate that it's on the weekend...I guess this was the only time slot people had in common. > Are there some specific issues that we should be thinking about as > folks in the library technology community if we participate in this > discussion? Do you think that we should continue to push hard for > an OpenURL-based microformat? If you had your druthers, what do > you think should be the microformat standard for citations? > Anything we can do to support people who will be attending? Once upon a time I thought simple usage of the OpenURL KEVs would be a nice place to start. I still like the idea as it could operate like a more readable CSS friendly ocoins. What's more the KEVs would fare pretty well under the 80/20 rule that microformats people are so fond of 'citing'. However there is also a motivation to have a citation microformat reuse existing microformats as necessary. There are already microformats which could be used to encode portions of a citation: hCard for marking up people, companies and organizations; hCal for dates; rel-tag for subject keywords; hAtom for bundling up lists of citations. Simply transcribing openurl KEVs into class names wouldn't really address reuse and that's one down side to the 'just use openurl' approach. So I'm looking forward to a good talk about how to move forward, and I hope some of you can make it. Don't feel like any of what I just wrote needs to make sense for you to join in. There will be a fairly wide array of skill sets present, and really all you need to know to help out is the basics of HTML markup. It would help to review what microformats are if you aren't already familiar with them, and the philosophy/zen behind the movement. //Ed From daniel.chudnov at yale.edu Wed Apr 5 17:39:25 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 5 17:39:27 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> Message-ID: <20060405213925.GJ15372@sildin.med.yale.edu> Alf Eaton wrote, on Wed, Apr 05, 2006 at 04:35:35PM -0400: > On 05 Apr 2006, at 15:56, Daniel Chudnov wrote: > > > >How is the behavior you describe any different from span-driven > >behavior? > > With the standard microformats, data means > that the value of x is "data", whereas data means that the value of x is "actual data". Ah... you meant "microformat parsers". Good point. > The endorsed microformat for URI would presumably be the same as for > URL, which is . The problem is still that of non- > clickable URIs, so it might be worth trying again... I'll send a post > to the list. Sounds good about checking with them again. But, we're on a tight schedule. Ideas can languish or die on uf-discuss, and we're nearly done already. Imho, best to adopt their suggested practice and move on whether they're down for it just now or not. In any case, are you really sure you want s? http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2.4 "A reference to an unavailable or unidentifiable resource is an error." SPAN or ABBR should work and is not an error for our crazy corner-case non-click-resolvable URIs. They say use ABBR... it doesn't brake our implied in-browser processing model or limit our options for publishing additional markup within the ABBR. Good enough for me. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Apr 6 12:38:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Apr 6 12:38:04 2006 Subject: [gcs-pcs-list] quick rewrite vote Message-ID: <20060406163802.GD6305@sildin.med.yale.edu> I was hoping the rewrite would solicit more comments, e.g. "rewrite good" or "rewrite bad", independent of individual issues it addresses. Since it hasn't really done that, here's a recasting of the rewrite in the form of a list of the open issues it attempts to address and the choices it makes about them. This is about half of the open issues; the other half are fairly simple yes/no votes. Please take a moment to review the rewrite in light of the issues as described below, and indicate whether you approve or not. We can get back to issue votes immediately thereafter. The url again was: http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html Thanks, -Dan - Should the root node of the formats response be "unapi" instead of "formats"? No. - Rewrite intro to address what it's for, must be insanely clear and concise I think this is better. - How can we more fully explain what a "format" name/token is used for when it's first mentioned? Make the spec shorter to decrease the time from introduction to explanation. - Do we need a schema for the formats response? An informative schema is helpful, but it's not the formal spec. - Should we allow "bare" identifiers, i.e., without fully-specified uri context prefix No. - Consider removing namespace_uri and schema_location from the formats list spec Removed. - Consider refactoring the formats specification to remove redundancy in UNAPI and UNAPI?uri=URI Refactored. - Revisit possibility of introspection document No. - Simplify UNAPI formats list to just list format names No. - Add UNAPI?format=FORMAT for a descriptive document concerning that format No. - Close reading for precise wording, phrasing, etc. Done once, I think this is better. - Do we need a namespace? No. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Thu Apr 6 14:20:57 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Apr 6 14:22:06 2006 Subject: [gcs-pcs-list] quick rewrite vote In-Reply-To: <20060406163802.GD6305@sildin.med.yale.edu> References: <20060406163802.GD6305@sildin.med.yale.edu> Message-ID: On 4/6/06, Daniel Chudnov wrote: > Please take a moment to review the rewrite in light of the issues as > described below, and indicate whether you approve or not. We can get > back to issue votes immediately thereafter. The url again was: > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html I'll just go ahead and give a blanket +1 on all rewrite points listed. I think the original email introducing the rewrite made a strong enough case for all points that I decided not to pick at little bits. Thanks for the dedicated and thoughtful work, Dan! -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Thu Apr 6 15:04:38 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Apr 6 15:05:47 2006 Subject: [gcs-pcs-list] quick rewrite vote In-Reply-To: <20060406163802.GD6305@sildin.med.yale.edu> References: <20060406163802.GD6305@sildin.med.yale.edu> Message-ID: rewrite looks better to me. I have two comments: The format:docs element is removed in rev3-rewrite, I wonder if it should be kept. I think it's useful if considering wider audience without knowledge of oai_dc or mods. In several example requests with a URI, the URI is not URL-encoded, such as: http://unapi.info/news/unapi.php?uri=http://unapi.info/news/archives/9&format=oai_dc either the URI is URL-encoded, or the specification should say this is done intentionally for readability. thanks for great work, xiaoming On Thu, 6 Apr 2006, Daniel Chudnov wrote: > I was hoping the rewrite would solicit more comments, e.g. "rewrite > good" or "rewrite bad", independent of individual issues it addresses. > Since it hasn't really done that, here's a recasting of the rewrite in > the form of a list of the open issues it attempts to address and the > choices it makes about them. This is about half of the open issues; > the other half are fairly simple yes/no votes. > > Please take a moment to review the rewrite in light of the issues as > described below, and indicate whether you approve or not. We can get > back to issue votes immediately thereafter. The url again was: > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > Thanks, -Dan > > > - Should the root node of the formats response be "unapi" > instead of "formats"? > > No. > > - Rewrite intro to address what it's for, must be insanely > clear and concise > > I think this is better. > > - How can we more fully explain what a "format" name/token is used > for when it's first mentioned? > > Make the spec shorter to decrease the time from introduction to > explanation. > > - Do we need a schema for the formats response? > > An informative schema is helpful, but it's not the formal spec. > > - Should we allow "bare" identifiers, i.e., without fully-specified > uri context prefix > > No. > > - Consider removing namespace_uri and schema_location from the > formats list spec > > Removed. > > - Consider refactoring the formats specification to remove > redundancy in UNAPI and UNAPI?uri=URI > > Refactored. > > - Revisit possibility of introspection document > > No. > > - Simplify UNAPI formats list to just list format names > > No. > > - Add UNAPI?format=FORMAT for a descriptive document concerning > that format > > No. > > - Close reading for precise wording, phrasing, etc. > > Done once, I think this is better. > > - Do we need a namespace? > > No. > > > > From lists at hubmed.org Fri Apr 7 10:24:45 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Apr 7 10:28:19 2006 Subject: [gcs-pcs-list] unAPI: rewrite attempt In-Reply-To: <20060405213925.GJ15372@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> Message-ID: <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> On 05 Apr 2006, at 17:39, Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Apr 05, 2006 at 04:35:35PM -0400: > >> The endorsed microformat for URI would presumably be the same as for >> URL, which is . The problem is still that of non- >> clickable URIs, so it might be worth trying again... I'll send a post >> to the list. > > Sounds good about checking with them again. The summary of this was that >> My homepage >> http://example.org >> My homepage are all acceptable, which presumably applies to "uri" as well. > In any case, are you really sure you want s? I'm not sure, it just seems more semantically correct. > http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2.4 > > "A reference to an unavailable or unidentifiable resource is an > error." It's the user agent's fault if it can't handle certain protocols for locating objects with any URIs (they do mailto:, for example). The specification for in HTML says that the href attribute is a URI, not just a URL. alf. From daniel.chudnov at yale.edu Sun Apr 9 17:10:57 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 9 17:11:01 2006 Subject: [gcs-pcs-list] update. Message-ID: <20060409211057.GB11282@sildin.med.yale.edu> Since no one has raised serious objections to the rewrite, let's consider the current state of revision to be the one I posted this past week. The new issues raised by Alf and Xiaoming regarding the rewrite are on the to-do list. It's likely I will be offline more than on during the coming few weeks. So, it's likely that I won't be able to keep pushing on unAPI as steadily as I'd promised and would prefer. I don't want to slip from the spec's original timeline, but, if we don't have sufficient time to get through all the open issues, we can put things off a week or two, as necessary. So if you're looking for something unAPIish to work on in the meantime, implement the revised spec or producing/consuming demos thereof. :) I'm sorry for slipping off pace but will catch back up soon. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Sun Apr 9 18:51:43 2006 From: ehs at pobox.com (Edward Summers) Date: Sun Apr 9 18:52:19 2006 Subject: [gcs-pcs-list] update. In-Reply-To: <20060409211057.GB11282@sildin.med.yale.edu> References: <20060409211057.GB11282@sildin.med.yale.edu> Message-ID: <3FD9A938-E2AD-418E-90E2-F9A1DDD4AD0D@pobox.com> On Apr 9, 2006, at 4:10 PM, Daniel Chudnov wrote: > I'm sorry for slipping off pace but will catch back up soon. When the spec is out on unapi.info I'll update the validator as appropriate. See you on the other side. //Ed From azaroth at liverpool.ac.uk Tue Apr 11 15:59:02 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Apr 11 16:02:35 2006 Subject: [gcs-pcs-list] Formats Message-ID: If you look at the following schema (will find out a documentation link for it from Tom after the presentation (at DLF)) http://gita.grainger.uiuc.edu/aquifertechwg/assetactions.xsd You will note that it's practically identical to the formats schema. Perhaps the spec could be made simpler by referencing the aquifer schema? Secondly, just to ensure that they're still in the queue: * URI vs Identifier * Introspection (eg Unapi vs openurl) Rob From daniel.chudnov at yale.edu Wed Apr 12 08:04:26 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 12 08:05:16 2006 Subject: [gcs-pcs-list] server maintenance Message-ID: We are getting an untoward amount of unsolicited bulk email on the machine that runs this list (welcome to the internet, eh?). Fortunately mailman is usually smart enough to not send this stuff through to lists, but it creates a lot of extra work for your friendly sysadmins. So I'm adding more mail filtering layers. Most of you should not see much or any difference, but if you do and don't like it, please let me know. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Apr 19 15:29:23 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 19 15:29:59 2006 Subject: [gcs-pcs-list] related efforts Message-ID: <20060419192923.GF21848@sildin.med.yale.edu> Hi all. I'm getting caught up with stuff and will be back on the unAPI bandwagon (or segway, more like?) shortly. In the meantime a slew of sorta-related-to-what-we-discuss-here initiatives have floated by in the past few days. I see that some of the folks involved in those diverse efforts have had at least a toe in here, too. The main reason this list was formed, following a discussion of gcs/pcs issues at the Fall 2004 DLF Forum, was to have a place to go to discuss and share information about related projects that our list's diverse membership had found their individual ways into or otherwise heard tell of. Along the way we found that we had an approxiately-right minimum subset of folks to work on particular initiatives of our own; these are natural complements, and the one doesn't replace the other. Please consider this message a polite nudzh to keep in the spirit of the original founding premise and speak up about what you're doing or what you've heard and how it might or might not relate to other things we've discussed here. Many thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Wed Apr 19 21:34:26 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Apr 19 21:35:41 2006 Subject: [gcs-pcs-list] related efforts In-Reply-To: <20060419192923.GF21848@sildin.med.yale.edu> References: <20060419192923.GF21848@sildin.med.yale.edu> Message-ID: There is a forthcoming Mellon meeting (Thursday): http://msc.mellon.org/Meetings/Interop/goals_and_topics copied from the web page: "The goals of the meeting are: * To agree on the nature and characteristics of a limited set of core, protocol-based repository interfaces (REST-full and/or SOAP-based Web services) that allow downstream applications to interact with heterogeneous repositories in an efficient and consistent manner. * To compile a concrete list of action items aimed at fully specifying, validating and implementing such repository interfaces. * To devise a timeline for the specification, validation and implementation of such repository interfaces." xiaoming On Wed, 19 Apr 2006, Daniel Chudnov wrote: > Hi all. I'm getting caught up with stuff and will be back on the unAPI > bandwagon (or segway, more like?) shortly. > > In the meantime a slew of sorta-related-to-what-we-discuss-here > initiatives have floated by in the past few days. I see that some of > the folks involved in those diverse efforts have had at least a toe in > here, too. > > The main reason this list was formed, following a discussion of gcs/pcs > issues at the Fall 2004 DLF Forum, was to have a place to go to discuss > and share information about related projects that our list's diverse > membership had found their individual ways into or otherwise heard > tell of. Along the way we found that we had an approxiately-right > minimum subset of folks to work on particular initiatives of our own; > these are natural complements, and the one doesn't replace the other. > > Please consider this message a polite nudzh to keep in the spirit of > the original founding premise and speak up about what you're doing or > what you've heard and how it might or might not relate to other things > we've discussed here. > > Many thanks, -Dan > > > From efc at umn.edu Thu Apr 20 16:01:23 2006 From: efc at umn.edu (Eric Celeste) Date: Thu Apr 20 16:05:46 2006 Subject: [gcs-pcs-list] AssetAction In-Reply-To: <20060419192923.GF21848@sildin.med.yale.edu> References: <20060419192923.GF21848@sildin.med.yale.edu> Message-ID: > Please consider this message a polite nudzh to keep in the spirit of > the original founding premise... I think Dan is calling me out of my lurker mode here to share with you some work that's been going on in the Aquifer project. This is somewhat hard to do since it is not yet baked enough to even have it's own web page describing it, but here I go. The technical committee of the DLF Aquifer project ( see http:// www.diglib.org/aquifer/ ) has been working on a concept called AssetAction. Basically AssetAction amounts to a bundle of XML that is packaged with (for instance) an OAI harvested object that describes various "actions" that can be taken on that object. For example, one could imagine a "getThumbnail" action or a "getFullSize" action related to image objects, or a "getHTML" action that is an HTML rendering of whatever the object might be to use in context on another page. When harvested, these AssetAction packages allow a system to call on the object in a wide variety of ways, making more complex interactions possible for the user. After an Aquifer presentation at the DLF Forum last week I spent some time at the back of the ballroom talking with Rob Sanderson (JISC), Muriel Foulonneau (UIUC), and John Ockerbloom (UPenn) about the differences and similarities of unAPI and AssetAction. Here are a few brief notes... Similarities: Both address the problem space of sharing pointers to functions one can perform on objects referenced by identifiers. Key difference: unAPI generates these pointers on the client side (in the browser using something like a javascript engine) while AssetAction generates these pointers at the data provider and hooks them into a web page on the server side. unAPI strength: Terse presentation, with essentially the identifier alone needing to be embedded with each item in the HTML code of the page. This id is combined with resolver info in the header of the HTML (via, for example, javascript) to create real URL's for the browser to follow for given actions (or "formats" in unAPI-speak). This leads to one of unAPI's weaknesses: it can only really accommodate a single resolver per page. In other words, all actions need to be resolved by one provider. AssetAction strength: The full URLs in each action definition allow for a very flexible resolution infrastructure, including action packages that rely on more than one institution for various functions. AssetAction is also not as closely bound to the web, as Thorny's collector demo shows. Still, this leads to its weakness, it is verbose and requires server-side harvesting and smarts to implement. Potential overlap: (1) Since both address the same problem space, one potential area of collaboration is in the naming of actions (or formats) so that programmers understand and come to some agreement on what certain functions actually produce. Why not create an unAPI "profile" that reflects the AssetAction "default action group" for example. (2) Since each method has a weakness that seems to be the strength of the other, why not leverage one with the other? For example: an Aquifer system harvesting AssetActions and using them for its own presentation could also become a single-point resolver for unAPI ids referencing all Aquifer objects. This resolution of unAPI would just become another Aquifer service. We don't yet have a proper site for AssetAction, but there are a few things you can do to gather more info. There is a demonstration system up that utilizes AssestAction to present objects... http://cicharvest.grainger.uiuc.edu/assetactions/collections.asp There is a white paper about the AssetAction there as well. ...Eric Eric Celeste / 612-624-4126 / efc@umn.edu Associate University Librarian for Information Technology University of Minnesota (Twin Cities) Libraries From daniel.chudnov at yale.edu Thu Apr 20 17:44:18 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Apr 20 17:44:51 2006 Subject: [gcs-pcs-list] back to unAPI Message-ID: <20060420214417.GF25288@sildin.med.yale.edu> Okay, since today was supposed to be the day to publish rev3, but we're not ready (guilty!), let's push back two weeks. So the new schedule would be: May 4 - rev3 / ballot spec June 1 - version 1 finished. I've updated the to-do list to reflect nearly all of the "decisions" mentioned here: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-April/000742.html ...leaving the to-do list at ~13 items, many of which should be easy group decisions. I'll kick off threads for a few in subsequent messages. Fyi, the present version of the spec lives at: http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html That's where we stand. Let's finish up... thanks for being patient with me, life just intervenes sometimes (thankfully!). -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Apr 20 17:49:51 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Apr 20 17:50:24 2006 Subject: [gcs-pcs-list] AssetAction In-Reply-To: References: <20060419192923.GF21848@sildin.med.yale.edu> Message-ID: <20060420214951.GG25288@sildin.med.yale.edu> Eric and Xiaoming, thanks for filling us in... hopefully after folks here catch up with the stuff you linked to we might begin to see if there are opportunities to help to pull things apart or push them together some. The remaining effort from which we haven't heard (and I'm not even sure where it comes from) falls (I think!) under the rubric "GET IT". Does anyone here know anything about it which they might share here? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Apr 20 17:53:31 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Apr 20 17:54:04 2006 Subject: [gcs-pcs-list] unAPI: warn about empty SPANs? Message-ID: <20060420215331.GH25288@sildin.med.yale.edu> This item raised by Eric: Should we add a warning about tidy-ers possibly stripping out empty span elements? Note that COinS does provide a warning: "The example above shows an empty span tag. In the absence of further processing, nothing will be visible to the user. The page is designed to gracefully accommodate a bit of added text or a button image to anchor an added link. Alternatively, the web page might have default text inside the span for users without access to activating agents. Some HTML checkers (such as HTML Tidy) strip out empty span elements, causing the loss of COinS data. A comment or hard space in the span will prevent this from happening." - from http://ocoins.info/#id3205609416 This might make for a good addition to the informative notes. What do you think? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Fri Apr 21 02:36:38 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Apr 21 02:38:12 2006 Subject: [gcs-pcs-list] unAPI: warn about empty SPANs? In-Reply-To: <20060420215331.GH25288@sildin.med.yale.edu> References: <20060420215331.GH25288@sildin.med.yale.edu> Message-ID: <23b83f160604202336y427abadeuce01367272e323c8@mail.gmail.com> +1. The same way I always place an   in COinS, it's probably good practice to put /something/ in a unapi-uri span. -Ross. On 4/20/06, Daniel Chudnov wrote: > This item raised by Eric: > > Should we add a warning about tidy-ers possibly stripping out empty > span elements? > > Note that COinS does provide a warning: > > "The example above shows an empty span tag. In the absence of further > processing, nothing will be visible to the user. The page is designed to > gracefully accommodate a bit of added text or a button image to anchor > an added link. Alternatively, the web page might have default text > inside the span for users without access to activating agents. Some > HTML checkers (such as HTML Tidy) strip out empty span elements, > causing the loss of COinS data. A comment or hard space in the span > will prevent this from happening." > > - from http://ocoins.info/#id3205609416 > > > This might make for a good addition to the informative notes. What do > you think? > > -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 daniel.chudnov at yale.edu Fri Apr 21 14:03:02 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Apr 21 14:03:34 2006 Subject: [gcs-pcs-list] unAPI issue: 406 vs. 415 Message-ID: <20060421180302.GA642@sildin.med.yale.edu> Early on we suggested 406 Not Acceptable for responses to unAPI requests for formats not available for an item. Then we replaced this because it says it is about "content characteristics not acceptable according to the accept headers sent in the request." http://rfc.net/rfc2616.html#s10.4.7 And switched to 415 Unsupported Media Type, which sounded more appropriate: http://rfc.net/rfc2616.html#s10.4.16 Later, Leigh suggested we really do need 406: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000565.html The latest revision still recommends (in the informative section): "415 Unsupported Media Type for requests for a URI that is available on the server in a format that is not available for that URI" http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html So, we should pick one or the other for the recommendation. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Fri Apr 21 16:36:12 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Apr 21 16:37:47 2006 Subject: [gcs-pcs-list] unAPI issue: 406 vs. 415 In-Reply-To: <20060421180302.GA642@sildin.med.yale.edu> References: <20060421180302.GA642@sildin.med.yale.edu> Message-ID: On 4/21/06, Daniel Chudnov wrote: > Early on we suggested 406 Not Acceptable for responses to unAPI > requests for formats not available for an item. Then we replaced > this because it says it is about "content characteristics not acceptable > according to the accept headers sent in the request." > > http://rfc.net/rfc2616.html#s10.4.7 > > And switched to 415 Unsupported Media Type, which sounded more > appropriate: > > http://rfc.net/rfc2616.html#s10.4.16 > > Later, Leigh suggested we really do need 406: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000565.html After re-reading the definitions of each, my vote is for 406. > > The latest revision still recommends (in the informative section): > > "415 Unsupported Media Type for requests for a URI that is available > on the server in a format that is not available for that URI" > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > > So, we should pick one or the other for the recommendation. > > -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 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Sun Apr 23 23:27:17 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Sun Apr 23 23:28:23 2006 Subject: [gcs-pcs-list] unAPI issue: 406 vs. 415 In-Reply-To: <20060421180302.GA642@sildin.med.yale.edu> References: <20060421180302.GA642@sildin.med.yale.edu> Message-ID: I think Leigh's previous analysis of 415 is right (i.e. 415 typically used for POST), 406 seems like a better choice in this case. xiaoming On Fri, 21 Apr 2006, Daniel Chudnov wrote: > Early on we suggested 406 Not Acceptable for responses to unAPI > requests for formats not available for an item. Then we replaced > this because it says it is about "content characteristics not acceptable > according to the accept headers sent in the request." > > http://rfc.net/rfc2616.html#s10.4.7 > > And switched to 415 Unsupported Media Type, which sounded more > appropriate: > > http://rfc.net/rfc2616.html#s10.4.16 > > Later, Leigh suggested we really do need 406: > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000565.html > > The latest revision still recommends (in the informative section): > > "415 Unsupported Media Type for requests for a URI that is available > on the server in a format that is not available for that URI" > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > > So, we should pick one or the other for the recommendation. > > -Dan > > > From ehs at pobox.com Mon Apr 24 10:16:34 2006 From: ehs at pobox.com (Edward Summers) Date: Mon Apr 24 10:17:41 2006 Subject: [gcs-pcs-list] a microformat for identifiers Message-ID: <316FB3E0-B55A-4947-BB47-AC1908831253@pobox.com> There has been some movement recently over on microformats.org to establish a microformat for identifiers [1]. This would provide a mechanism for embedding identifiers in HTML so that they can be discovered in a systematic way. Essentially this means that:
  • ISBN: 073571245X
    • could become:
  • ISBN: 0-7357-1245-X
    • Look familiar? The use of 'uid' is borrowed from another microformat 'module' hCard. I only mention this effort here since it ties in nicely to unAPIs use of the 'unap-uri' class name. If accepted the microformat would be a nice resource for the spec to call out to...thus shortening the spec even further :-) Please contribute to the wiki pages with examples, thoughts and ideas if you have the time. //Ed [1] http://microformats.org/wiki/uid From godmar at gmail.com Mon Apr 24 11:29:58 2006 From: godmar at gmail.com (Godmar Back) Date: Mon Apr 24 11:31:39 2006 Subject: [gcs-pcs-list] Off-topic: plug for LibX mailing list Message-ID: <719dced30604240829q1fb85fdbm9b51627ebd2a0b2b@mail.gmail.com> This is off-topic, but I believe that some subscribers of this list may be interested in it. We have had tremendous interest in LibX recently, and have built several new "live" editions and "test" editions; we revamped our libx.org website as well. If you're interested in LibX, check it out. We've added several new web localization features ("cues") to LibX and now also have the ability to support multiple catalogs simultaneously. Overall, we believe we have streamlined the process for setting up editions and testing them. There is now a mailing list set up at http://libx.mozdev.org/list.html to discuss LibX. As a reminder, LibX supports, among many other things, COinS. Its infrastructure allows services like it to be easily added. If "unAPI" - whatever that really is ;-) - ever comes to fruition and if it proves to be practical and deployable in a manner similar to COinS, its client-side support will likely be added to LibX as appropriate. - Godmar From daniel.chudnov at yale.edu Mon Apr 24 11:42:00 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Apr 24 11:43:36 2006 Subject: [gcs-pcs-list] Off-topic: plug for LibX mailing list In-Reply-To: <719dced30604240829q1fb85fdbm9b51627ebd2a0b2b@mail.gmail.com> References: <719dced30604240829q1fb85fdbm9b51627ebd2a0b2b@mail.gmail.com> Message-ID: <5B7FF715-588B-4A44-A5A3-E031E712E9EF@yale.edu> On Apr 24, 2006, at 11:29 AM, Godmar Back wrote: > This is off-topic, but I believe that some subscribers of this list > may be interested in it. I can't imagine anything more on-topic. :) > If "unAPI" - whatever that really is ;-) - Not that I don't see the smiley, but, is it not clear what unAPI is? Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Apr 25 12:11:43 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 12:12:15 2006 Subject: [gcs-pcs-list] unAPI issue: 406 vs. 415 In-Reply-To: References: <20060421180302.GA642@sildin.med.yale.edu> Message-ID: <20060425161139.GB21573@sildin.med.yale.edu> Xiaoming Liu wrote, on Sun, Apr 23, 2006 at 09:27:17PM -0600: > I think Leigh's previous analysis of 415 is right (i.e. 415 typically used > for POST), 406 seems like a better choice in this case. So, considering earlier agreement with Leigh's analysis as well, and that no one objects now, let's call this one closed: we switch to 406. -Dan > On Fri, 21 Apr 2006, Daniel Chudnov wrote: > > >Early on we suggested 406 Not Acceptable for responses to unAPI > >requests for formats not available for an item. Then we replaced > >this because it says it is about "content characteristics not acceptable > >according to the accept headers sent in the request." > > > > http://rfc.net/rfc2616.html#s10.4.7 > > > >And switched to 415 Unsupported Media Type, which sounded more > >appropriate: > > > > http://rfc.net/rfc2616.html#s10.4.16 > > > >Later, Leigh suggested we really do need 406: > > > > http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000565.html > > > >The latest revision still recommends (in the informative section): > > > > "415 Unsupported Media Type for requests for a URI that is available > > on the server in a format that is not available for that URI" > > > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > > > > >So, we should pick one or the other for the recommendation. > > > > -Dan > > > > > > > > -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Apr 25 12:12:40 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 12:12:49 2006 Subject: [gcs-pcs-list] unAPI issue: rename the spec? Message-ID: <20060425161238.GC21573@sildin.med.yale.edu> The issue is: Consider renaming "unAPI" Thoughts? Me, I still like the name, but domain names are cheap. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Apr 25 12:36:08 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 12:36:41 2006 Subject: [gcs-pcs-list] unAPI: warn about empty SPANs? In-Reply-To: <23b83f160604202336y427abadeuce01367272e323c8@mail.gmail.com> References: <20060420215331.GH25288@sildin.med.yale.edu> <23b83f160604202336y427abadeuce01367272e323c8@mail.gmail.com> Message-ID: <20060425163607.GD21573@sildin.med.yale.edu> Ross Singer wrote, on Fri, Apr 21, 2006 at 02:36:38AM -0400: > +1. > > The same way I always place an   in COinS, it's probably good > practice to put /something/ in a unapi-uri span. Any other comments? If not, some flavor rewriting the text from the COinS spec will go into the informative section of unAPI. -Dan > On 4/20/06, Daniel Chudnov wrote: > > This item raised by Eric: > > > > Should we add a warning about tidy-ers possibly stripping out empty > > span elements? > > > > Note that COinS does provide a warning: > > > > "The example above shows an empty span tag. In the absence of further > > processing, nothing will be visible to the user. The page is designed to > > gracefully accommodate a bit of added text or a button image to anchor > > an added link. Alternatively, the web page might have default text > > inside the span for users without access to activating agents. Some > > HTML checkers (such as HTML Tidy) strip out empty span elements, > > causing the loss of COinS data. A comment or hard space in the span > > will prevent this from happening." > > > > - from http://ocoins.info/#id3205609416 > > > > > > This might make for a good addition to the informative notes. What do > > you think? -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Apr 25 13:09:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 13:10:04 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI Message-ID: <20060425170932.GE21573@sildin.med.yale.edu> Two items on the issue list read: Clarify the relationship between UNAPI? and UNAPI?uri=URI Consider further specifying the meaning of the UNAPI? formats list w/r/to all formats available in the respository I don't exactly remember the nuance of why these are separate items, though they are certainly related. In the large, a primary question is "what should the format list returned by 'UNAPI?' mean"? Xiaoming pointed out that for OAI-PMH, verb=ListMetadataFormats has the following meaning w/r/to the identifier value being present or not: an optional argument that specifies the unique identifier of the item for which available metadata formats are being requested. If this argument is omitted, then the response includes all metadata formats supported by this repository. Note that the fact that a metadata format is supported by a repository does not mean that it can be disseminated from all items in the repository. (hand-waving away the difference between "metadata formats" (OAI) and "object formats" (unAPI) for obvious reasons...) At present, I manage three unAPI services (though one is still not public). One, canarydatabase.org, has a fixed list of formats available for each available record, so it the above meaning would make sense. The other two applications, OPA and unalog, are designed to proxy an arbitrary combination of objects and formats which cannot be known in advance. Thus the above meaning would not make sense -- I cannot efficiently observe enough about the potential object domains to prepare a list of all formats available. So it might make more sense for those services to have 'UNAPI?' return a list of formats that *should* be available for all objects, with the same caveat that it should not be assumed that all objects support it. This way I could solve the OPA/UNAPI? problem Xiaoming pointed out wherein previously that: http://opa.onebiglibrary.net/? ...once returned nothing, but now it can return what it actually returns, the single format "wrap", which is indeed available for every object OPA can proxy. Note that the rev3 rewrite presently reads: "Provide a list of object formats supported by the unAPI service." So I guess I'd come down on the side of revising to read: "Provide a list of object formats which should be supported for all objects available through the unAPI service." -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Tue Apr 25 17:18:47 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue Apr 25 17:19:50 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <20060425170932.GE21573@sildin.med.yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> Message-ID: On Tue, 25 Apr 2006, Daniel Chudnov wrote: > > Note that the rev3 rewrite presently reads: > > "Provide a list of object formats supported by the unAPI service." > > So I guess I'd come down on the side of revising to read: > > "Provide a list of object formats which should be supported for all > objects available through the unAPI service." > +1 I like this approach for the potential of reducing server load, e.g. given 100 identifiers in one page, there is no need to issue unAPI request for each of them to create valid links, a single request of UNAPI? might be sufficient in some cases. xiaoming From daniel.chudnov at yale.edu Tue Apr 25 17:32:39 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 17:33:12 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: References: <20060425170932.GE21573@sildin.med.yale.edu> Message-ID: <20060425213239.GG21573@sildin.med.yale.edu> Xiaoming Liu wrote, on Tue, Apr 25, 2006 at 03:18:47PM -0600: > On Tue, 25 Apr 2006, Daniel Chudnov wrote: > > > > "Provide a list of object formats which should be supported for all > > objects available through the unAPI service." > > +1 > > I like this approach for the potential of reducing server load, e.g. given > 100 identifiers in one page, there is no need to issue unAPI request for > each of them to create valid links, a single request of UNAPI? might be > sufficient in some cases. I *think* this is right. But... ...part of me wants to reneg on my earlier arguments and suggest that we should support UNAPI?uri=URI1[&uri=URI2&...], with a response like: I know, I know, I've been fighting even mentioning it. But, this would make more sense for unalog, I *think*. Many have raised this issue before and I was dismissive; I'm really sorry about this. Implementing it has changed my mind some. Still, I'd be happy to leave this unresolved for now; it would keep things simpler not to support multiple uris in one query. Or, I'd be happy to have rotten fruits thrown at me and reopen this part of the discussion should there be enough fruit to go around. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Tue Apr 25 17:58:49 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Apr 25 18:00:26 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <20060425213239.GG21573@sildin.med.yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> Message-ID: <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> -1 My fear here is twofold: 1) It seems to overlap a bit with OAI-PMH 2) the argument list presents a problem a) i think repeating uri could present problems in some implementations... the uri would be the only uri that the cgi/etc. recognizes b) if the uri arg has some sort of qualifier attached to it, I then have to check for those. If somebody can quell my concerns on this, I might come around to a +1 -Ross. On 4/25/06, Daniel Chudnov wrote: > > Xiaoming Liu wrote, on Tue, Apr 25, 2006 at 03:18:47PM -0600: > > On Tue, 25 Apr 2006, Daniel Chudnov wrote: > > > > > > "Provide a list of object formats which should be supported for all > > > objects available through the unAPI service." > > > > +1 > > > > I like this approach for the potential of reducing server load, e.g. > given > > 100 identifiers in one page, there is no need to issue unAPI request for > > each of them to create valid links, a single request of UNAPI? might be > > sufficient in some cases. > > I *think* this is right. But... > > ...part of me wants to reneg on my earlier arguments and suggest that > we should support UNAPI?uri=URI1[&uri=URI2&...], with a response like: > > > > > > > > > > > > > > I know, I know, I've been fighting even mentioning it. But, this would > make more sense for unalog, I *think*. Many have raised this issue before > and I was dismissive; I'm really sorry about this. Implementing it has > changed my mind some. > > Still, I'd be happy to leave this unresolved for now; it would keep > things simpler not to support multiple uris in one query. Or, I'd be > happy to have rotten fruits thrown at me and reopen this part of the > discussion should there be enough fruit to go around. > > -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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060425/7d83a749/attachment.htm From daniel.chudnov at yale.edu Tue Apr 25 18:06:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 18:07:06 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> Message-ID: <20060425220633.GI21573@sildin.med.yale.edu> Ross Singer wrote, on Tue, Apr 25, 2006 at 05:58:49PM -0400: > > My fear here is twofold: > > 1) It seems to overlap a bit with OAI-PMH Afaik, there's no way, in OAI-PMH, to say "give me information for this one arbitrary set of records... no, not a chunk of a set retrieved using a resumptionToken... no, not a set in its own right... yes, just a list of search results, say, or foo's items tagged with 'bar', just a list of those, thank you." Unless there's some best practice doc somewhere... is there? Though you could serialize 'em one-by-one in either OAI-PMH or unAPI as-is. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Apr 25 18:12:25 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Apr 25 18:13:24 2006 Subject: Fwd: Re: Re: [gcs-pcs-list] AssetAction] Message-ID: <20060425221223.GK21573@sildin.med.yale.edu> Forwarding with Mary's permission. Thanks, whoever wrote to her! :) ----- Forwarded message from Mary Heath ----- Date: Tue, 25 Apr 2006 14:35:28 -0700 From: Mary Heath Subject: Re: Re: [gcs-pcs-list] AssetAction] To: Daniel.Chudnov@yale.edu X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Scanned-By: MIMEDefang 2.52 on 130.132.50.9 Hello, Dan. The comment below was forwarded to me by someone on the gcs-pcs list. I don't know if John Bodfish has contacted to you yet, but somehow you seem to have heard about our GET-IT prototype. I have herewith attached the specification for the GET-IT service, which is an effort of a newly formed group called Rethinking Resource Sharing sponsored jointly by NISO and ALA RUSA STARS; the group's web site is at http://blog.aclin.org. I suspect that John will be contacting you soon, but if you have any comments on the functional spec, I would love to receive them. Mary Heath California Digital Library University of California Office of the President > The remaining effort from which we haven't heard (and I'm not even > sure where it comes from) falls (I think!) under the rubric "GET IT". > Does anyone here know anything about it which they might share here? > > -Dan ----- End forwarded message ----- -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 -------------- next part -------------- A non-text attachment was scrubbed... Name: GET-ITfunctionalspec.doc Type: application/msword Size: 759808 bytes Desc: not available Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060425/83340cc8/GET-ITfunctionalspec-0001.doc From mrylander at gmail.com Tue Apr 25 19:43:56 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Apr 25 19:45:30 2006 Subject: [gcs-pcs-list] unAPI issue: rename the spec? In-Reply-To: <20060425161238.GC21573@sildin.med.yale.edu> References: <20060425161238.GC21573@sildin.med.yale.edu> Message-ID: On 4/25/06, Daniel Chudnov wrote: > The issue is: > > Consider renaming "unAPI" > > Thoughts? Without a really compelling suggestion my vote is -1. > > Me, I still like the name, but domain names are cheap. :) > > -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 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From fawcett at uwindsor.ca Wed Apr 26 12:48:23 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Wed Apr 26 12:49:28 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> Message-ID: <444FA457.9060300@uwindsor.ca> On 4/25/2006 5:58 PM, Ross Singer wrote: > On 4/25/06, *Daniel Chudnov* > wrote: >> ...part of me wants to reneg on my earlier arguments and suggest that >> we should support UNAPI?uri=URI1[&uri=URI2&...], with a response like: > a) i think repeating uri could present problems in some > implementations... the uri would be the only uri that the cgi/etc. > recognizes But to be fair, such an implementation would be considered broken. :-) Multiple-value fields happen in the wild, and any serious CGI/Web library would account for them. As a last resort in a broken environment, the script writer should still have access to QUERY_STRING or its equivalent, and could do the parse/decode themselves. Graham -- Graham Fawcett Application Developer/Consultant Centre for Flexible Learning University of Windsor fawcett@uwindsor.ca (519) 253-3000 ext 3049 From ehs at pobox.com Wed Apr 26 12:59:25 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Apr 26 13:00:31 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <20060425220633.GI21573@sildin.med.yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <20060425220633.GI21573@sildin.med.yale.edu> Message-ID: <3E10776C-D224-4AD2-9649-7E368C095728@pobox.com> On Apr 25, 2006, at 5:06 PM, Daniel Chudnov wrote: > Afaik, there's no way, in OAI-PMH, to say "give me information for > this > one arbitrary set of records... no, not a chunk of a set retrieved > using > a resumptionToken... no, not a set in its own right... yes, just a > list > of search results, say, or foo's items tagged with 'bar', just a > list of > those, thank you." Unless there's some best practice doc somewhere... > is there? Sounds like a set :-) /me gets flashback of Rob Sanderson's talk at code4libcon //Ed From daniel.chudnov at yale.edu Wed Apr 26 13:12:16 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 26 13:13:53 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <3E10776C-D224-4AD2-9649-7E368C095728@pobox.com> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <20060425220633.GI21573@sildin.med.yale.edu> <3E10776C-D224-4AD2-9649-7E368C095728@pobox.com> Message-ID: <5FC4D355-D841-4CFB-9626-0D9FBBF8EB4E@yale.edu> On Apr 26, 2006, at 12:59 PM, Edward Summers wrote: > On Apr 25, 2006, at 5:06 PM, Daniel Chudnov wrote: >> Afaik, there's no way, in OAI-PMH, to say "give me information for >> this >> one arbitrary set of records... no, not a chunk of a set retrieved >> using >> a resumptionToken... no, not a set in its own right... yes, just a >> list >> of search results, say, or foo's items tagged with 'bar', just a >> list of >> those, thank you." Unless there's some best practice doc >> somewhere... >> is there? > > Sounds like a set :-) OAI-PMH Sets are pre-determined by the collection, no? > /me gets flashback of Rob Sanderson's talk at code4libcon We must not have been dropping the same stuff. :) Could you remind/ retell? -Dan From ross.singer at library.gatech.edu Wed Apr 26 13:23:10 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Apr 26 13:24:46 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <444FA457.9060300@uwindsor.ca> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <444FA457.9060300@uwindsor.ca> Message-ID: <23b83f160604261023x64ea8218m4225b8b657f0c036@mail.gmail.com> http://rsinger.library.gatech.edu/fawcetterator/?uri=foo&uri=bar&uri=baz&uri=foobar "); print_r($_GET); echo("
    "); echo($_SERVER['QUERY_STRING']); ?> Regardless of one's opinion on PHP, it's a 'popular and widely used' web scripting language. As I recall, the point of unAPI is to be braindead simple so that even the least sophisticated can implement it. Requiring one to forgo the usual argument plumbing to facilitate our spec seems outside the scope. That's just my opinion, though. -Ross. On 4/26/06, Graham Fawcett wrote: > > On 4/25/2006 5:58 PM, Ross Singer wrote: > > On 4/25/06, *Daniel Chudnov* > > wrote: > >> ...part of me wants to reneg on my earlier arguments and suggest that > >> we should support UNAPI?uri=URI1[&uri=URI2&...], with a response like: > > a) i think repeating uri could present problems in some > > implementations... the uri would be the only uri that the cgi/etc. > > recognizes > > But to be fair, such an implementation would be considered broken. :-) > Multiple-value fields happen in the wild, and any serious CGI/Web > library would account for them. > > As a last resort in a broken environment, the script writer should still > have access to QUERY_STRING or its equivalent, and could do the > parse/decode themselves. > > Graham > > -- > Graham Fawcett > Application Developer/Consultant > Centre for Flexible Learning > University of Windsor > fawcett@uwindsor.ca > (519) 253-3000 ext 3049 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060426/bb76cede/attachment.htm From ehs at pobox.com Wed Apr 26 13:24:49 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Apr 26 13:25:56 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <5FC4D355-D841-4CFB-9626-0D9FBBF8EB4E@yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <20060425220633.GI21573@sildin.med.yale.edu> <3E10776C-D224-4AD2-9649-7E368C095728@pobox.com> <5FC4D355-D841-4CFB-9626-0D9FBBF8EB4E@yale.edu> Message-ID: On Apr 26, 2006, at 12:12 PM, Daniel Chudnov wrote: > OAI-PMH Sets are pre-determined by the collection, no? There's nothing preventing one from making them act like queries on the server side. Although that makes Which is why Rob (a SRU/CQL architect) did a lightning talk with the title: Call to Action: Deprecate OAI Sets! [1,2] :-) //Ed [1] http://www.csc.liv.ac.uk/~azaroth/lightning.odp [2] http://www.csc.liv.ac.uk/~azaroth/lightning.ppt From liu_x at lanl.gov Wed Apr 26 13:31:51 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed Apr 26 13:32:51 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <5FC4D355-D841-4CFB-9626-0D9FBBF8EB4E@yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <20060425220633.GI21573@sildin.med.yale.edu> <3E10776C-D224-4AD2-9649-7E368C095728@pobox.com> <5FC4D355-D841-4CFB-9626-0D9FBBF8EB4E@yale.edu> Message-ID: On Wed, 26 Apr 2006, Daniel Chudnov wrote: > On Apr 26, 2006, at 12:59 PM, Edward Summers wrote: > >> On Apr 25, 2006, at 5:06 PM, Daniel Chudnov wrote: >>> Afaik, there's no way, in OAI-PMH, to say "give me information for this >>> one arbitrary set of records... no, not a chunk of a set retrieved using >>> a resumptionToken... no, not a set in its own right... yes, just a list >>> of search results, say, or foo's items tagged with 'bar', just a list of >>> those, thank you." Unless there's some best practice doc somewhere... >>> is there? >> >> Sounds like a set :-) > > OAI-PMH Sets are pre-determined by the collection, no? Once a while ago people are stuffing queries into sets (therefore sets are abused as dynamic). > > >> /me gets flashback of Rob Sanderson's talk at code4libcon > > We must not have been dropping the same stuff. :) Could you remind/retell? > Rob posted similar arguments in OAI list a while ago http://www.openarchives.org/pipermail/oai-implementers/2005-April/001465.html And I vote against multiple URIs in unAPI request. regards, xiaoming From fawcett at uwindsor.ca Wed Apr 26 14:40:31 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Wed Apr 26 14:41:32 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <23b83f160604261023x64ea8218m4225b8b657f0c036@mail.gmail.com> References: <20060425170932.GE21573@sildin.med.yale.edu> <20060425213239.GG21573@sildin.med.yale.edu> <23b83f160604251458p14bb6dfbq961ea647937e5ab3@mail.gmail.com> <444FA457.9060300@uwindsor.ca> <23b83f160604261023x64ea8218m4225b8b657f0c036@mail.gmail.com> Message-ID: <444FBE9F.9050201@uwindsor.ca> On 4/26/2006 1:23 PM, Ross Singer wrote: > [example snipped] Regardless of one's opinion on PHP, it's a 'popular > and widely used' web scripting language. Eew. I had no idea. Yes, from the docs it looks like PHP will only handle multiple values if the name of the field has brackets at the end: http://rsinger.library.gatech.edu/fawcetterator/?uri[]=foo&uri[]=bar&uri[]=baz&uri[]=foobar --> Array ( [uri] => Array ( [0] => foo [1] => bar [2] => baz [3] => foobar ) ) That's truly awful. Thanks for the rude awakening, Ross. :-) > As I recall, the point of unAPI is to be braindead simple so that even > the least sophisticated can implement it. Requiring one to forgo the > usual argument plumbing to facilitate our spec seems outside the scope. Agreed. Yet the case for batch requests does make sense. Although, for any N greater than a handful, it starts to look like it should be a POST request. Not all servers like long query strings, and "414 Request-URI Too Long" might end up being as one of the status codes you need to handle. Graham From ehs at pobox.com Wed Apr 26 15:22:40 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Apr 26 15:23:48 2006 Subject: [gcs-pcs-list] unAPI issue: rename the spec? In-Reply-To: References: <20060425161238.GC21573@sildin.med.yale.edu> Message-ID: <8B1A043D-ABD7-4BA6-8B46-6D587870226E@pobox.com> On Apr 25, 2006, at 6:43 PM, Mike Rylander wrote: > On 4/25/06, Daniel Chudnov wrote: >> The issue is: >> >> Consider renaming "unAPI" >> >> Thoughts? > > Without a really compelling suggestion my vote is -1. I have to admit, I'm not a huge fan of the name unAPI or the shocking use of study caps (for dchud). But, I think it's a good name, and since we don't have alternatives. -1 From daniel.chudnov at yale.edu Wed Apr 26 16:44:58 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 26 16:46:36 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: References: <20060425170932.GE21573@sildin.med.yale.edu> Message-ID: <01EF78B3-FBA7-404E-AD55-5C21B1E46916@yale.edu> Okay, we have -1s on multi-URIs already, and only qualified interest in adding it, so let's just drop it. Please consider and vote on the following change as-is... -Dan > On Tue, 25 Apr 2006, Daniel Chudnov wrote: >> >> Note that the rev3 rewrite presently reads: >> >> "Provide a list of object formats supported by the unAPI service." >> >> So I guess I'd come down on the side of revising to read: >> >> "Provide a list of object formats which should be supported for all >> objects available through the unAPI service." From eric at openly.com Wed Apr 26 18:00:31 2006 From: eric at openly.com (Eric Hellman) Date: Wed Apr 26 18:02:20 2006 Subject: [gcs-pcs-list] COinS WorldCat Product page In-Reply-To: <20060425221223.GK21573@sildin.med.yale.edu> References: <20060425221223.GK21573@sildin.med.yale.edu> Message-ID: Not exactly the freshest news around, but here it is, finally, on the OCLC website. http://www.oclc.org/productworks/coins.htm -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Wed Apr 26 19:10:56 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 26 19:12:33 2006 Subject: [gcs-pcs-list] unAPI issue: rename the spec? In-Reply-To: <8B1A043D-ABD7-4BA6-8B46-6D587870226E@pobox.com> References: <20060425161238.GC21573@sildin.med.yale.edu> <8B1A043D-ABD7-4BA6-8B46-6D587870226E@pobox.com> Message-ID: <00D0A9E4-AE2B-4AB2-B8DA-3D9535F019FD@yale.edu> On Apr 26, 2006, at 3:22 PM, Edward Summers wrote: > On Apr 25, 2006, at 6:43 PM, Mike Rylander wrote: >> On 4/25/06, Daniel Chudnov wrote: >>> The issue is: >>> >>> Consider renaming "unAPI" >>> >>> Thoughts? >> >> Without a really compelling suggestion my vote is -1. > > I have to admit, I'm not a huge fan of the name unAPI or the > shocking use of study caps (for dchud). But, I think it's a good > name, and since we don't have alternatives. > > -1 -2 and no positive comments or suggestions later, let's call it closed. -Dan From daniel.chudnov at yale.edu Wed Apr 26 19:23:08 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 26 19:24:45 2006 Subject: [gcs-pcs-list] unAPI: warn about empty SPANs? In-Reply-To: <20060425163607.GD21573@sildin.med.yale.edu> References: <20060420215331.GH25288@sildin.med.yale.edu> <23b83f160604202336y427abadeuce01367272e323c8@mail.gmail.com> <20060425163607.GD21573@sildin.med.yale.edu> Message-ID: <28B41C07-016C-45F0-84C0-83066F84652C@yale.edu> On Apr 25, 2006, at 12:36 PM, Daniel Chudnov wrote: > Ross Singer wrote, on Fri, Apr 21, 2006 at 02:36:38AM -0400: >> +1. >> >> The same way I always place an   in COinS, it's probably good >> practice to put /something/ in a unapi-uri span. > > Any other comments? If not, some flavor rewriting the text from the > COinS spec will go into the informative section of unAPI. Hearing none, this is closed. The following informative note is now near the bottom: "Note: handling empty SPANs The unAPI URI microformat allows for empty SPANs. Note that some HTML checkers such as Tidy may strip out empty SPANs, causing loss of the URI information. Adding a comment or hard space in the SPAN should prevent this from happening." http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html Thanks, -Dan From daniel.chudnov at yale.edu Wed Apr 26 19:33:08 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Apr 26 19:34:44 2006 Subject: [gcs-pcs-list] unAPI issue: client-side XSLT Message-ID: <68A62848-EB9A-401C-94AD-1FC5AE4A773A@yale.edu> The issue is: Consider issues related to client-side XSLT rendering. I *think* the context of this issue was Xiaoming's greasemonkey scripts; in one or more cases, remote services advertising a unAPI URL and one or more URIs were being rendered into HTML by XSLT from XML in the browser. So the typical "find the HTML SPANs with class='unapi-uri'" query sometimes wasn't finding anything (because it was looking at XML, not HTML) even though the user could see it there in the rendered HTML. (Forgive me if I've got the person or project wrong; the effect that led to the concern was at least close to this.) Is this a correct summary? Any further thoughts on this, or specific changes we might consider making? -Dan From ehs at pobox.com Wed Apr 26 21:28:17 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Apr 26 21:29:22 2006 Subject: [gcs-pcs-list] unAPI issue: rename the spec? In-Reply-To: <00D0A9E4-AE2B-4AB2-B8DA-3D9535F019FD@yale.edu> References: <20060425161238.GC21573@sildin.med.yale.edu> <8B1A043D-ABD7-4BA6-8B46-6D587870226E@pobox.com> <00D0A9E4-AE2B-4AB2-B8DA-3D9535F019FD@yale.edu> Message-ID: <449CF03F-1ECB-44C8-AA68-07C5BF7BDF65@pobox.com> >> have to admit, I'm not a huge fan of the name unAPI or the >> shocking use of study caps (for dchud). But, I think it's a good >> name, and since we don't have alternatives. just so you don't think I'm totally insane -- I meant to write studlyCaps instead of study caps //Ed From liu_x at lanl.gov Thu Apr 27 13:39:53 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Apr 27 13:40:53 2006 Subject: [gcs-pcs-list] unAPI issue: client-side XSLT In-Reply-To: <68A62848-EB9A-401C-94AD-1FC5AE4A773A@yale.edu> References: <68A62848-EB9A-401C-94AD-1FC5AE4A773A@yale.edu> Message-ID: On Wed, 26 Apr 2006, Daniel Chudnov wrote: > The issue is: > > Consider issues related to client-side XSLT rendering. > > > I *think* the context of this issue was Xiaoming's greasemonkey scripts; in > one or more cases, remote services advertising a unAPI URL and one or more > URIs were being rendered into HTML by XSLT from XML in the browser. So the > typical "find the HTML SPANs with class='unapi-uri'" query sometimes wasn't > finding anything (because it was looking at XML, not HTML) even though the > user could see it there in the rendered HTML. > > (Forgive me if I've got the person or project wrong; the effect that led to > the concern was at least close to this.) > > Is this a correct summary? Any further thoughts on this, or specific changes > we might consider making? > > I asked the question in microformats list and copied responses below. So this is not a suggested practice (per microformats). Since this is a microformats issue, I don't think we need to elaborate it in unAPI. xiaoming Date: Thu, 27 Apr 2006 12:21:24 -0500 From: brian suda Reply-To: Microformats Discuss To: Microformats Discuss Subject: Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy) Xiaoming Liu wrote: > This helps a lot, and I still have remaining issues: > > say I have an xml file "foobar" > > In order to use client-side xslt to render this xml file, and make > sure the result is Microformats-compliant, I wrote an xslt file > "microformats.xsl", and insert a link to xslt in xml file: > > > > foobar > > This file can be rendered in IE and Firefox, because they do xslt > client-side rendering, so the display is correct, but when I check > page source, it's still the raw xml file. And when writing a script to > fetch Microformats fragments, I have to do XSLT rendering first to get > HTML back. > > So I am wondering if the above scenario is a good practice, and how > well it's supported by current Microformats tools. --- Well, the above scenario isn't really supported because Microformats are in HTML as class values, not as XML Node names. You have just taken the Property Names we used in hCard, which we derived from vCard and made an XML file with corresponding node names. So this really isn't a microformat at all, and therefore not supported by our tools. The tools right now are looking for microformats within HTML, not an XML file. Now you said that you are converting the XML to HTML with microformats. Since this is done on the client-side, you are at the mercy of each client. IE and Firefox, as you have noted, are just DISPLAYING the rendered HTML, but the underlying file is still the XML. -brian _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss Date: Thu, 27 Apr 2006 12:29:15 -0500 From: Scott Reynen Reply-To: Microformats Discuss To: Microformats Discuss Subject: Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy) On Apr 27, 2006, at 12:03 PM, Xiaoming Liu wrote: > This file can be rendered in IE and Firefox, because they do xslt client-side rendering, so > the display is correct, but when I check page source, it's still the raw xml file. And when > writing a script to fetch Microformats fragments, I have to do XSLT rendering first to get > HTML back. > > So I am wondering if the above scenario is a good practice You might want to look at this site: http://w3future.com/ I vaguely recall Sjoerd tried to run his entire site as you've described and it lasted a few weeks before he ran into enough problems that he now does server-side XSLT to HTML 4 unless you click the "Try XHTML 2.0" button, which turns off the server-side XSLT. Peace, Scott From godmar at gmail.com Thu Apr 27 20:01:43 2006 From: godmar at gmail.com (Godmar Back) Date: Thu Apr 27 20:03:18 2006 Subject: [gcs-pcs-list] Off-topic: plug for LibX mailing list In-Reply-To: <5B7FF715-588B-4A44-A5A3-E031E712E9EF@yale.edu> References: <719dced30604240829q1fb85fdbm9b51627ebd2a0b2b@mail.gmail.com> <5B7FF715-588B-4A44-A5A3-E031E712E9EF@yale.edu> Message-ID: <719dced30604271701g6945be0bw71b714394557b953@mail.gmail.com> On 4/24/06, Daniel Chudnov wrote: > > > If "unAPI" - whatever that really is ;-) - > > Not that I don't see the smiley, but, is it not clear what unAPI is? > Last time I looked it was not clear at all, but unapi.info has taken shape as I see now. So suppose I find ISBN 123456789X in a web page. Presumably, you'd want me to rewrite this to something that would benefit the user. Say LibX recognizes an embedded reference in URI microformat, and so does another agent running in the same browser. Should you define or agree on a standard or best practices/conventions for how to handle this? For instance, if a user runs LibX, wants a link to point to xISBN->to her library, but also would like to know via book burro how much that book would be to purchase, how will the user agents coordinate? For COinS, for instance, I'll put an     below the . We could adopt the informal convention to a) not remove the SPAN b) not remove existing children c) insert yourself after the last child already there, if any. The other question I would have is what sites use microformat uris or auto-discovery links and whether any cool library-related services can be linked to them today. (*) - Godmar (*) The links to the .js scripts on http://lxming.blogspot.com/2006/02/pubmed-and-citeseer-also-unapi-enabled.html are broken. From godmar at gmail.com Thu Apr 27 21:14:52 2006 From: godmar at gmail.com (Godmar Back) Date: Thu Apr 27 21:16:26 2006 Subject: [gcs-pcs-list] libx vs greasemonkey Message-ID: <719dced30604271814y785e0a2au5ddf81df5191347f@mail.gmail.com> After looking some more at unAPI, I noticed that many people are using greasemonkey to test or prototype some client services. In this context, it may be helpful to compare LibX's web localization abilities to greasemonkey's when it comes to the prototyping and delivery of unAPI-type services. Both LibX & Greasemonkey provide the ability rewrite pages using JavaScript. Greasemonkey code will typically work in LibX with only slight changes. Differences include: LibX uses regular expressions, while greasemonkey does not. LibX passes the actual object returned from the match to the function, allowing for match-and-capture type scripts. (Minor, but important.) LibX uses a JavaScript object to capture the action to be taken on a page load, whereas Greasemonkey stores each function in a separate file. Greasemonkey allows its scripts to be updated by reinstalling them. LibX requires uninstallation & reinstallation of the entire extension, or automatic update with version number increase. (For local testing, of course, you can simply work in the directory where your extension is installed.) Greasemonkey code lives in a sandbox that prevents certain types of modifications to the original document, LibX lives squarely in chrome land. Therefore, LibX makes it easier to get access to the original document when needed. LibX also does not suffer from any of the usual client-side Javascript restrictions. Most importantly, LibX provides immediate access to library services to the script programmer - placing a keyword link, ISBN-link, OpenURL link, etc. to the user's locally selected library is just a function call away. Greasemonkey scripts need to be adjusted for every individual library. In LibX, this adjustment is done once when building an edition, a process we soon hope to automate. To give a brief taste for the interested javascript programmer (I apologize for posting code here which gmail's line breaking will probably horribly distort): as an example, consider this cue: http://libx.org/screencasts/googlesearchlibx.png In the LibX infrastructure, it is implemented like so: new DoForURL(/google\.com\/search.*q=/, function (doc) { var n = xpathFindSingle(doc, "//tr/td[font[@size='+1' and b[text()='Web']]]"); var searchterms = doc.gs.q.value; // google stores its search terms there for its own use n.appendChild(makeLink(doc, libxGetProperty("catsearch.label", [libraryCatalog.catalogname, searchterms])), libraryCatalog.makeKeywordSearch(searchterms))); }); where we offer convenience functions for: - xpath - registering the handler using a "DoForURL" object - direct document access & access to URL match - creating a keyword search for the catalog configured in this edition of LibX - displaying various customization attributes as configured (e.g., display the catalog name in a tooltip, etc. etc.) Rewriting amazon, another popular greasemonkey feat, can be accomplished in LibX like so: // match amazon page and capture ISBN in match var amazonAction = new DoForURL(/\.amazon\.com.*\/(\d{7,9}[\d|X])\//, function (doc, match) { match[1] now contains captured ISBN ... rest as usual, except can use xpathFindSingle convenience functions. }); I believe that LibX could be great delivery vehicle for services, possibly prototyped using greasemonkey, to a larger number of libraries, without requiring individual greasemonkey script hacking. We currently have 8 editions live, and another 10-12 libraries testing their editions. LibX is Open Source, the most up-to-date version is kept on libx.mozdev.org. There is also a mailing list. - Godmar for the LibX Team From jdunck at gmail.com Thu Apr 27 23:49:08 2006 From: jdunck at gmail.com (Jeremy Dunck) Date: Thu Apr 27 23:50:43 2006 Subject: [gcs-pcs-list] libx vs greasemonkey In-Reply-To: <719dced30604271814y785e0a2au5ddf81df5191347f@mail.gmail.com> References: <719dced30604271814y785e0a2au5ddf81df5191347f@mail.gmail.com> Message-ID: <2545a92c0604272049g403ac4e6p5bf72863a89ad7f9@mail.gmail.com> On 4/27/06, Godmar Back wrote: ...snip lots of useful domain-specific stuff > I believe that LibX could be great delivery vehicle for services, > possibly prototyped using greasemonkey, to a larger number of > libraries, without requiring individual greasemonkey script hacking. Hey, it ain't so bad, ya know. :) > We currently have 8 editions live, and another 10-12 libraries testing > their editions. I'm not sure where you're at with your "automated edition compilation", but there are two greasemonkey user script compilers which might give some ideas. http://www.letitblog.com/greasemonkey-compiler/ (original, now obsolete, but python source available) http://www.arantius.com/misc/greasemonkey/script-compiler.php (functional, php source available) I thought the "this could be your edition" page was a bit amusing. :-) I've made several abortive runs at an uber-librarylookup and am happy to see this work. Once you get the compiler working, I'd recommend letting Jon Udell know about your extension. I'm sure he'd be interested. > LibX is Open Source, the most up-to-date version is kept on > libx.mozdev.org. There is also a mailing list. I'll go there for futher discussion. I have some suggestions. ;-) From godmar at gmail.com Fri Apr 28 00:15:09 2006 From: godmar at gmail.com (Godmar Back) Date: Fri Apr 28 00:16:44 2006 Subject: [gcs-pcs-list] libx vs greasemonkey In-Reply-To: <2545a92c0604272049g403ac4e6p5bf72863a89ad7f9@mail.gmail.com> References: <719dced30604271814y785e0a2au5ddf81df5191347f@mail.gmail.com> <2545a92c0604272049g403ac4e6p5bf72863a89ad7f9@mail.gmail.com> Message-ID: <719dced30604272115w6909d3b8o3bab32370c05b067@mail.gmail.com> Jeremy, just to clarify how the LibX edition process currently works and how this compares to the compilers you mentioned in your email. LibX takes in a config file (*) that describes such attributes as a library's name, URL, catalog or catalogs, catalog type(s), OpenURL resolver URL, proxy system, how they do xISBN, and various edition creator preferences such as icons and logos. It creates an extension .xpi file for this library. This is currently done by a combination of textual replacement at edition build time via Perl, and at run time using string bundles (where possible & convenient). This part exists, is fully functional, and can be checked out from libx.mozdev.org. The future part is the web interface that will take the place of the config file that is currently used - or better, it will create the config file in an interactive dialog and create the edition automatically, similar to how the php script you referred to creates an .xpi file from a GM script. As for how to include GM scripts into LibX, the only change is to convert the URL match, and possibly make some adjustment for the different namespaces. I doubt that a compiler will be of much help here, or worth the investment, since this is likely an infrequent process only for tested GM scripts that wish to be deployed in this way. - Godmar (*) examples are at http://libx.org/editionsintesting.php From liu_x at lanl.gov Fri Apr 28 11:54:39 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Apr 28 11:55:36 2006 Subject: [gcs-pcs-list] Off-topic: plug for LibX mailing list In-Reply-To: <719dced30604271701g6945be0bw71b714394557b953@mail.gmail.com> References: <719dced30604240829q1fb85fdbm9b51627ebd2a0b2b@mail.gmail.com> <5B7FF715-588B-4A44-A5A3-E031E712E9EF@yale.edu> <719dced30604271701g6945be0bw71b714394557b953@mail.gmail.com> Message-ID: On Thu, 27 Apr 2006, Godmar Back wrote: > > (*) The links to the .js scripts on > http://lxming.blogspot.com/2006/02/pubmed-and-citeseer-also-unapi-enabled.html > are broken. fixed, thanks for pointing this out. xiaoming From daniel.chudnov at yale.edu Sun Apr 30 22:36:41 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 30 22:37:16 2006 Subject: [gcs-pcs-list] unAPI issue: client-side XSLT In-Reply-To: References: <68A62848-EB9A-401C-94AD-1FC5AE4A773A@yale.edu> Message-ID: <20060501023640.GF22732@sildin.med.yale.edu> Since Xiaoming first raised this, and doesn't wish to pursue it further, let's call it closed. -Dan Xiaoming Liu wrote, on Thu, Apr 27, 2006 at 11:39:53AM -0600: > On Wed, 26 Apr 2006, Daniel Chudnov wrote: > >The issue is: > > > >Consider issues related to client-side XSLT rendering. > > > >I *think* the context of this issue was Xiaoming's greasemonkey scripts; > >in one or more cases, remote services advertising a unAPI URL and one or > >more URIs were being rendered into HTML by XSLT from XML in the browser. > >So the typical "find the HTML SPANs with class='unapi-uri'" query > >sometimes wasn't finding anything (because it was looking at XML, not > >HTML) even though the user could see it there in the rendered HTML. > > I asked the question in microformats list and copied responses below. So > this is not a suggested practice (per microformats). > > Since this is a microformats issue, I don't think we need to elaborate it > in unAPI. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Sun Apr 30 22:58:33 2006 From: ehs at pobox.com (Edward Summers) Date: Sun Apr 30 22:59:39 2006 Subject: [gcs-pcs-list] validating unAPI URIs Message-ID: <6D40146E-2D71-4641-B10C-7C77967A0762@pobox.com> Does anyone have an opinion about whether or not the unapi-validator [1] should validate unapi-uris? For example, should it make sure XXX is a legitimate URI and throw a suitable error/warning indicating the situation if it's not? Should it be an error or a warning? //Ed [1] http://validator.unapi.info/ From daniel.chudnov at yale.edu Sun Apr 30 23:05:20 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 30 23:05:53 2006 Subject: [gcs-pcs-list] unAPI: big push to rev3 Thursday Message-ID: <20060501030520.GG22732@sildin.med.yale.edu> Hi all. It's been pointed out by several folks that dealing with these issues thread-by-thread is noisy... maybe we'd be better served by some other technique involving a wiki or something else. That said, we're nearly done with this thing, and if y'all will bear with me and a handful (five, three of which are easy) more issue threads, I promise to stop bombarding you with this stuff as of this Friday. This Thursday should be the release date of unAPI revision 3, aka the "ballot release". A quick review of what this means in ROGUE05-speak: http://www.code4lib.org/wiki/rogue Everybody will then have 30 days to try the revised version and send comments. Then, at the end of 30 days from the publication of rev3, those who have submitted implementations (at present, these are listed at http://unapi.info/examples.html) will get to vote on whether we're done or not, and if not, to make specific changes to address issues raised by comments, or choose to abandon the spec. Either way: simple, I hope. :) So, take a deep breath, or unsubscribe now -- here comes the last flood of issue threads. Please vote if you can, and thank you for staying with this so far! -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Apr 30 23:09:27 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 30 23:09:59 2006 Subject: [gcs-pcs-list] unAPI issue(s): meaning of UNAPI? vs. UNAPI?uri=URI In-Reply-To: <01EF78B3-FBA7-404E-AD55-5C21B1E46916@yale.edu> References: <20060425170932.GE21573@sildin.med.yale.edu> <01EF78B3-FBA7-404E-AD55-5C21B1E46916@yale.edu> Message-ID: <20060501030926.GH22732@sildin.med.yale.edu> Daniel Chudnov wrote, on Wed, Apr 26, 2006 at 04:44:58PM -0400: > Okay, we have -1s on multi-URIs already, and only qualified interest > in adding it, so let's just drop it. Please consider and vote on the > following change as-is... -Dan Hearing no further comment, and having two votes for this change, and none against, it passes. Updated working version available here: http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html -Dan > >On Tue, 25 Apr 2006, Daniel Chudnov wrote: > >> > >>Note that the rev3 rewrite presently reads: > >> > >> "Provide a list of object formats supported by the unAPI service." > >> > >>So I guess I'd come down on the side of revising to read: > >> > >> "Provide a list of object formats which should be supported for all > >> objects available through the unAPI service." -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Apr 30 23:21:29 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 30 23:22:02 2006 Subject: [gcs-pcs-list] unAPI issue: add back "docs" attr Message-ID: <20060501032129.GI22732@sildin.med.yale.edu> After the recent rewrite-for-terseness Xiaoming pointed out that the ability to specify a reference to documentation for an object format disappeared. http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-April/000744.html He suggested that we add it back using an attribute on the format element, e.g.: ...could become: ...changing the implied schema to also include: attribute type { docs }?, What do you think? If we re-add it, should it be required or optional? It was optional before. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Sun Apr 30 23:41:30 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Apr 30 23:42:03 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501032129.GI22732@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> Message-ID: <20060501034128.GJ22732@sildin.med.yale.edu> Daniel Chudnov wrote, on Sun, Apr 30, 2006 at 11:21:29PM -0400: > After the recent rewrite-for-terseness Xiaoming pointed out that the > ability to specify a reference to documentation for an object format > disappeared. Shoot - I should have combined this issue with this other remaining one: "Add UNAPI?format=FORMAT for a descriptive document concerning that format" They really address the same concern. Which is better? I *think* I prefer the docs attribute, as some systems (like unalog) might simply pass through objects in formats unknown to the system itself. On the other hand, I argued earlier that systems like unalog should do their best to preserve a reference to the original unAPI source server URL and format name so downstream users can attempt to fetch the source object for themselves. In that case, the same downstream users could just as easily call SOURCE_UNAPI?format=FORMAT for themselves. So, now I don't know what I prefer, but the docs attribute is probably simpler -- less for publishers to implement. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789