From daniel.chudnov at yale.edu Mon Jan 2 18:11:37 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Jan 2 18:12:47 2006 Subject: [gcs-pcs-list] Fwd: [Structuredblogging-discuss] first cut at template for journal articles with COinS References: Message-ID: Fyi. More fun with COinS and weblogs. The "structured blogging" plugin works in both wordpress and moveable type; the article template is backend-agnostic thanks to their template model. Oh, *#@ $!, forgot to attach the template... -------------- next part -------------- A non-text attachment was scrubbed... Name: review-article.xml Type: text/xml Size: 2560 bytes Desc: not available Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060102/c3e1d741/review-article.xml -------------- next part -------------- Happy new year, -Dan Begin forwarded message: > From: Daniel Chudnov > Date: January 2, 2006 6:05:41 PM EST > To: structuredblogging-discuss@structuredblogging.org > Subject: [Structuredblogging-discuss] first cut at template for > journal articles with COinS > > Following Phillip's advice I've marked up a template for journal > article reviews. This would ostensibly be for "academic" articles > of the researchy type, but could be for anything else published in > a serial format with a registered ISSN. An example using wordpress > 2.0 is here: > > http://futility.mine.nu/back/2006/01/02/183/ > > This template supports the COinS spec [1] and can be used to > generate valid OpenURL 1.0 links when combined with an appropriate > COinS activating bookmarklet/userscript [2]. Or (in English :) if > you write about an article in your weblog your readers can possibly > find the article online using their local library's subscriptions, > or request it via interlibrary loan, or do a cited reference > search, etc., much like the COinS link bit added last month to book > reviews using ISBN. [3] > > Some quick questions/notes: > > - is there a simple way to tell the template display block renderer > to url-encode a field value? This would be useful for embedding > titles in the COinS link, for instance. So, in addition to: > > http://sfx.galib.uga.edu/sfx_git1? > ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/ > fmt:kev:mtx:journal&rft.issn=0003-4932&rft.volume=241&rft.issue=4&rft. > pages=614-21&rft.date=2005 > > ...you might also have: > > http://sfx.galib.uga.edu/sfx_git1? > ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/ > fmt:kev:mtx:journal&rft.issn=0003-4932&rft.volume=241&rft.issue=4&rft. > pages=614-21&rft.date=2005 > &rft.title=Some+Article+Title+With+Encoded+Whitespace > > This is particularly useful in applications which process OpenURL/ > COinS, as title information is helpful and reassuring to display at > the other end of the transaction. > > - I broke/stripped out some of the review-related bits; it isn't > clear to me whether "star reviews" are appropriate for posts about > articles. Maybe they are, or maybe it should just be there for > authors to choose for themselves... in any case, the review > elements and microformat bits would need to be fixed/added back in > to get what you want from this template. > > - if i had any gimp chops I'd do up a background icon for journals. > Instead, I left the css class pointing at books. :( > > - it should be easily modified to incorporate a not-yet-written > microformat for openurl/articles. > > > One last thought... ideally we could push this a little further so > that a bookmarklet like the wordpress "press it" one could notice a > COinS on other pages elsewhere and optionally use it to pre- > populate the article review template in the posting interface. Is > there a hook already built in to the sb plugin code (or > wordpress2.0) that might simplify redirecting such a link into a > partially-filled-out structured blogging form using a bookmarklet > or userscript? > > Many thanks again for these plugins... they're fun to work with! > And, happy 2006. :) > > -Dan > > > [1] http://ocoins.info/ > [2] http://curtis.med.yale.edu/dchud/resolvable > [3] http://mail.pubsub.com/pipermail/structuredblogging-discuss/ > 2005-December/000023.html > _______________________________________________ > Structuredblogging-discuss mailing list > Structuredblogging-discuss@structuredblogging.org > http://mail.pubsub.com/mailman/listinfo/structuredblogging-discuss > From daniel.chudnov at yale.edu Tue Jan 3 17:05:43 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 3 17:05:46 2006 Subject: [gcs-pcs-list] Code4LibCon 2006 proposal deadline extended Message-ID: <20060103220543.GE1244@sildin.med.yale.edu> We have extended the deadline for prepared talk proposals for Code4lib 2006. [1] The new proposal deadline is January 9, 2006, 5pm EST and proposers will be notified by Midnight EST January 9, 2006. Code4lib 2006 is a loosely structured conference for library technologists to commune, gather/create/share ideas and software, be inspired, and forge collaborations. It is also an outgrowth of the Access HackFest, wrapped into a conference-ish format. It is the event for technologists building digital libraries and digital information systems, tools, and software. At least eight time slots will be available for prepared talks. We will choose from among the proposals based on diversity of topics, usefulness, wow factor, and potential impact. Proposals of 75 words or less are being accepted for review now. Please send your name, email address, and proposal to code4libcon. [2] We cannot accept every prepared talk proposal, but multiple lightning talk sessions will provide everyone who wishes to present with ample opportunity to show off. Prepared Talk Information Prepared talks are 20 minutes, and must center on ?tools? (some cool new software, software library or integration platform), ?specs? (how to get the most out of some protocols, or proposals for new ones), or ?challenges? (one or more big problems we should collectively address). We will evaluate proposals on criteria of usefulness, newness, geekiness, and diversity of topics. [1] http://www.code4lib.org/2006 [2] https://lists.gatech.edu/sympa/info/code4libcon Again, proposals should be sent to [2]. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Jan 10 10:15:10 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 10 10:16:21 2006 Subject: [gcs-pcs-list] Fwd: [Structuredblogging-discuss] Structured Blogging plugins v1.0pre12 to be available soon References: <43C37263.1090504@myelin.co.nz> Message-ID: Fyi. Goin' mainstream... both the book and journal article types support COinS, if in only a limited way (via book ISBN, and via journal ISSN). Phillip has been very welcoming of patches so far, so please try these out if you can (especially if you're providing campus blogging services, say :). Fyi2, in parallel someone's working on a "structured" template for postings about fine art, and is using the VRA Core as inspiration. -Dan Begin forwarded message: > From: Phillip Pearson > Date: January 10, 2006 3:37:55 AM EST > To: structuredblogging-discuss@structuredblogging.org > Subject: [Structuredblogging-discuss] Structured Blogging plugins > v1.0pre12 to be available soon > > Hi all, > > I've sent v1.0pre12 of the plugins in to be put up on the > structuredblogging.org site - they should be up in the morning. > > The big news is that now all the functions of the Wordpress plugin > should work properly with Wordpress 2.0. Specifically, the > following issues are now fixed: > > - Wordpress hangs or pages time out after installing or activating > the plugin > > - Heaps of SQL errors appear when submitting the SB option page on > Wordpress 2.0 > > It also includes Daniel Chudnov's journal article review type > (you'll see it on the 'Write' menu, under 'Review') and the COinS > stuff for book reviews. > > For people interested in the internals, a lot of stuff has been > moved out of sb-post-common.php and into structuredblogging.php, as > part of the ongoing work to make the Wordpress plugin's internals > cleaner. Right now you can't use the wysiwyg editor or any of the > new WP 2.0 features when editing SB microcontent, but we'll get > there eventually... > > Cheers, > Phil > > > _______________________________________________ > Structuredblogging-discuss mailing list > Structuredblogging-discuss@structuredblogging.org > http://mail.pubsub.com/mailman/listinfo/structuredblogging-discuss > -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Tue Jan 10 11:41:08 2006 From: ehs at pobox.com (Ed Summers) Date: Tue Jan 10 11:42:22 2006 Subject: [gcs-pcs-list] Fwd: [Structuredblogging-discuss] Structured Blogging plugins v1.0pre12 to be available soon In-Reply-To: References: <43C37263.1090504@myelin.co.nz> Message-ID: On 1/10/06, Daniel Chudnov wrote: > Fyi. Goin' mainstream... both the book and journal article types > support COinS, if in only a limited way (via book ISBN, and via > journal ISSN). Phillip has been very welcoming of patches so far, so > please try these out if you can (especially if you're providing > campus blogging services, say :). Fyi2, in parallel someone's > working on a "structured" template for postings about fine art, and > is using the VRA Core as inspiration. -Dan Wow, nice work Dan! Just out of curiosity are you hacking the MoveableType distribution as well? Also, is there any talk of sb becoming part of the WordPress and MoveableType cores? Not that it's important, I'm just curious, and only recently signed onto the structured blogging list. //Ed From daniel.chudnov at yale.edu Tue Jan 10 12:18:57 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 10 12:20:05 2006 Subject: [gcs-pcs-list] Fwd: [Structuredblogging-discuss] Structured Blogging plugins v1.0pre12 to be available soon In-Reply-To: References: <43C37263.1090504@myelin.co.nz> Message-ID: <9F3B0CC1-90F6-4FB2-A1E1-60A9C4A32A4C@yale.edu> On Jan 10, 2006, at 11:41 AM, Ed Summers wrote: > > Wow, nice work Dan! Just out of curiosity are you hacking the > MoveableType distribution as well? Also, is there any talk of sb > becoming part of the WordPress and MoveableType cores? Not that it's > important, I'm just curious, and only recently signed onto the > structured blogging list. Well, they made it pretty easy. :) The stuff I worked on only lives inside the (or as an additional) xml microcontent templates their plugin code utilizes. Technically I didn't touch any of the php/perl plugin code itself. I don't know what the state of the plugins w/r/to the core projects is. If I'm not mistaken, it's not without some controversy... I saw the word "fork" in a wordpress-related blog post somewhere. But, you'd have to imagine that will get smoothed over one way or another if these plugins gain traction. In the meantime, as Yogi said, when you come to a fork in the road, take it. :P -Dan From daniel.chudnov at yale.edu Fri Jan 13 11:33:03 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Jan 13 11:34:12 2006 Subject: [gcs-pcs-list] unAPI revision 0 (draft) Message-ID: <732810B2-925C-4327-85E8-401BBE68C6F8@yale.edu> There's an unAPI draft which I'd like to publish today. As an experiment I'm using basecamp to manage the process... milestone dates, to-do-lists, writeboards for the specs, etc., which are simple to use. It also means that it's simple to add people to the group to see and help with things in-process. So: if you want to help review this draft before the end of the day, im/phone/email me so i can set you up with an account (will need a full name, email, username, and pass). If you want to just see it later today, we'll be posting it to code4lib. I'm trying again with the ROGUE 05 process for this. Dates are already set: version 0 - today revision 1 - 16 Feb (during code4lib conference) revision 2 - 16 March revision 3 (ballot spec) - 20 April version 1 - 18 May Fyi, the first two paragraphs of the current draft are below. -Dan Background unAPI is a simple website API convention. There are many wonderful APIs and protocols for syndicating, searching, and harvesting content from diverse services on the web. But, they?re all different. They?re all great, but they?re all different, and they?re all already widely used. We want one API for the most basic operations necessary to perform simple clipboard-copy functions across all sites. We also want this API to be able to be easily layered on top of other well- known APIs. Objective The objective of unAPI is to enable web sites containing HTML interfaces to information-rich objects to simultaneously publish richly structured metadata for those objects, or those objects themselves, in a predictable and consistent way for machine processing. From daniel.chudnov at yale.edu Sat Jan 14 23:20:33 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sat Jan 14 23:21:38 2006 Subject: [gcs-pcs-list] unAPI version 0 Message-ID: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> The first version of unAPI is available here: http://code4lib.org/specs/unapi/version-0 Revision one is due on February 16, the second day of the code4lib conference in Oregon. There was an astounding amount of discussion of this spec on #code4lib yesterday, too much to handle reasonably. I *think* the major issues raised on-channel have been captured as open issues in the document itself. Please use this list for questions or comments, and tell us if you're implementing it. It's a requirement of the ROGUE05 process that the spec be developed on a public list; as such I won't be able to respond to substantive feedback off-list. We are tracking the *process* of developing the spec (to-dos, milestone dates, reference notes, etc.) in a private basecamp group, but all are welcome to participate in that. Contact me privately if you'd like access. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Sun Jan 15 21:36:04 2006 From: lists at hubmed.org (Alf Eaton) Date: Sun Jan 15 21:39:25 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> Message-ID: <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> On 14 Jan 2006, at 23:20, Daniel Chudnov wrote: > The first version of unAPI is available here: > > http://code4lib.org/specs/unapi/version-0 I've been thinking about this problem too, and came to slightly different conclusions than Dan. Here's my version of the description: http://alf.hubmed.org/unapi/unapi_version_0x.html The reason for writing a separate document was so that arguments could be made for doing things one way rather than the other. The main differences are a) I don't see any need for JSON, as anything handling the data is unlikely to have cross-domain security restrictions and b) the use of form parameters rather than paths, because they're easier to handle (especially when dealing with multiple URIs at once). Despite the differences, the main function remains the same: metadata for objects defined by URIs can be discovered and exported in the format requested. alf. From daniel.chudnov at yale.edu Mon Jan 16 13:14:46 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Jan 16 13:15:57 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> Message-ID: <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> On Jan 15, 2006, at 9:36 PM, Alf Eaton wrote: > > The reason for writing a separate document was so that arguments > could be made for doing things one way rather than the other. My concern with having a separate document is that if everybody with a different set of opinions on the open issues were to write a separate document, we'd never get anything done, and nobody would know what version anybody else is referencing. It would be much easier to tease apart the open issues (your rewrite/ post addresses about five of them, and introduces new ones :) and to discuss them here in turn, and to then reflect changes arrived by consensus back into the core, single document. I hope that seems reasonable to you. -Dan From ksclarke at gmail.com Mon Jan 16 16:18:01 2006 From: ksclarke at gmail.com (Kevin S. Clarke) Date: Mon Jan 16 16:19:04 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> Message-ID: <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> I actually like the second document, given the short timeframe in which unapi is to be developed. With a very short development cycle, I worry alternate ways of doing things might be lost in the single document approach. I think there were some quick decisions made in order to get something out quickly (nothing wrong with this, I get this is the spirit of the spec), but adding to that first document makes those initial decisions seem more authoritative (more like the real foundation of future decisions) rather than options of equal consideration (which is what I understood them to be based on the irc discussions). Having a second document, I think, makes the interplay b/t the two possibilities more explicit (and avoids assumptions of a single starting point). That said, I found myself wanting to do a diff on the two to tease out all the differences. Seeing them in one document definitely makes that easier. Kevin On 1/16/06, Daniel Chudnov wrote: > On Jan 15, 2006, at 9:36 PM, Alf Eaton wrote: > > > > The reason for writing a separate document was so that arguments > > could be made for doing things one way rather than the other. > > My concern with having a separate document is that if everybody with > a different set of opinions on the open issues were to write a > separate document, we'd never get anything done, and nobody would > know what version anybody else is referencing. > > It would be much easier to tease apart the open issues (your rewrite/ > post addresses about five of them, and introduces new ones :) and to > discuss them here in turn, and to then reflect changes arrived by > consensus back into the core, single document. > > I hope that seems reasonable to you. > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ehs at pobox.com Mon Jan 16 17:06:58 2006 From: ehs at pobox.com (Ed Summers) Date: Mon Jan 16 17:08:00 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> Message-ID: On 1/16/06, Kevin S. Clarke wrote: > That said, I found myself wanting to do a diff on the two to tease out > all the differences. Seeing them in one document definitely makes > that easier. Yes, I would honestly like to see the original with annotations, which would eventually get folded into a new revision (or removed). It's unfortunate also that the IRC medium is so conducive to debate since list members probably don't get see the context for much of the discussion. But perhaps this is a good thing eh? At least in my case it is :-) At first blush I really like the way this is headed. I particularly like how microformats, rest and identifiers are being fused. Since I don't have a publicly available data silo to liberate I'm looking forward to spending some time hacking together some GreaseMonkey scripts that use it in Oregon next month. //Ed From stoub at yahoo.com Mon Jan 16 17:56:23 2006 From: stoub at yahoo.com (Steve Toub) Date: Mon Jan 16 17:57:40 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> Message-ID: <43CC2497.2000908@yahoo.com> > It's unfortunate also that the IRC medium is so conducive to debate > since list members probably don't get see the context for much of the > discussion. > But perhaps this is a good thing eh? At least in my case it is :-) I've never been on the IRC channel and also feel like I more or less understand what's going on. As far as I know. ;) The only thing I feel like I don't really understand is why Dan's first draft had it's own scheme for responses. I guess I'm assuming a regular HTTP response with XML (or JSON or whatever) in the payload is fine. > At first blush I really like the way this is headed. Me too. Random feedback from an outsider: * At first blush, I liked the params better than the fixed paths, since I gives more flexibility and avoids fixing the path order. But then I wondered if it's as easy (technically) to rewrite URIs from paths to params as it is from params to paths. * I like the idea of single (introspect/explain) verb that lists all available API calls implemented on the server. And the ability to apply that verb to a single identifier. * Wondering how well the syntax scales for servers that have the ability to assembled different descriptive metadata schemes inside different containers (e.g., MODS in DIDL, MODS in METS, MODS in IMS-CP) and expressed in different notation: XML, RDF, etc. * Syntax seems to assume just a access service (get/view) rather than the full range of verbs (ingest, manage, etc.) and seems assume "resources" rather than other data types (tags, people, etc.). Ok for these to be shortcuts, but wondering how it scales when the API includes a fuller range of methods and data types. --SET From ehs at pobox.com Mon Jan 16 18:26:59 2006 From: ehs at pobox.com (Ed Summers) Date: Mon Jan 16 18:28:02 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <43CC2497.2000908@yahoo.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: On 1/16/06, Steve Toub wrote: > I've never been on the IRC channel and also feel like I more or less > understand what's going on. As far as I know. ;) Good, I'm glad to hear it. The nice thing about this list is it offers a rare distillation of conversations going on in other places. > * Syntax seems to assume just a access service (get/view) rather than > the full range of verbs (ingest, manage, etc.) and seems assume > "resources" rather than other data types (tags, people, etc.). Ok for > these to be shortcuts, but wondering how it scales when the API > includes a fuller range of methods and data types. Yes, I am interested in this too. Dan if you are targeting this as a copy/paste sort of api how does one paste? >From my somewhat uninformed perspective it seems to me that if unAPI were to have full RESTful powers it would be getting very close to the atom publishing protocol [1]. //Ed [1] http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-07.html From mrylander at gmail.com Mon Jan 16 20:37:23 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Jan 16 20:38:27 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <43CC2497.2000908@yahoo.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: On 1/16/06, Steve Toub wrote: [snip] > > The only thing I feel like I don't really understand is why Dan's first > draft had it's own scheme for responses. I guess I'm assuming a regular > HTTP response with XML (or JSON or whatever) in the payload is fine. > There is two (IMHO killer) applications that make the response format as proposed very attractive: 1) A batch processor for unAPI links that harvests data from a static local copy of the web pages. This would be useful for propagating changes between systems that don't need real time updates. 2) Non-HTTP transports. I'm thinking of XMPP/jabber specifically, but any transport (think FTP, or even (gasp!) email) should be possible. -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From ross.singer at library.gatech.edu Mon Jan 16 21:22:52 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Jan 16 21:23:56 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <43CC2497.2000908@yahoo.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> On Jan 16, 2006, at 5:56 PM, Steve Toub wrote: > > * At first blush, I liked the params better than the fixed paths, > since I gives more flexibility and avoids fixing the path order. But > then I wondered if it's as easy (technically) to rewrite URIs from > paths to params as it is from params to paths. > One thing I really dislike about the paths vs. params is that I think paths inherently assume the implementor has some sort of admin access over their server or have a framework that can deal with this. I think it eliminates the "Dear Campus Computing, may I please run this CGI (ASP, PHP, CF, etc.) on the campus server to make our data available?" crowd. It's easy for us nerds to "assume root", but I don't know how widely prevalent it really is. -Ross. From lists at hubmed.org Mon Jan 16 21:35:14 2006 From: lists at hubmed.org (Alf Eaton) Date: Mon Jan 16 21:38:36 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: <064EA657-7104-4908-998D-316D63DC25D1@hubmed.org> On 16 Jan 2006, at 18:26, Ed Summers wrote: >> From my somewhat uninformed perspective it seems to me that if unAPI > were to have full RESTful powers it would be getting very close to the > atom publishing protocol [1]. I think the main differences here are that a) an Atom server will have access to the full documents, whereas here we're just talking about metadata and b) Atom commands work only on one URI at a time (ie GET to fetch a document, POST to update it, DELETE to delete it, etc), rather than requesting metadata for a string of URIs at once - but maybe you'd want unAPI to work that way too using a series of requests for multiple URIs... alf. From mrylander at gmail.com Mon Jan 16 21:48:18 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Jan 16 21:49:22 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> Message-ID: On 1/17/06, Ross Singer wrote: > On Jan 16, 2006, at 5:56 PM, Steve Toub wrote: > > > > * At first blush, I liked the params better than the fixed paths, > > since I gives more flexibility and avoids fixing the path order. But > > then I wondered if it's as easy (technically) to rewrite URIs from > > paths to params as it is from params to paths. > > > > One thing I really dislike about the paths vs. params is that I think > paths inherently assume the implementor has some sort of admin access > over their server or have a framework that can deal with this. I think > it eliminates the "Dear Campus Computing, may I please run this CGI > (ASP, PHP, CF, etc.) on the campus server to make our data available?" > crowd. It's easy for us nerds to "assume root", but I don't know how > widely prevalent it really is. > This is a very good point, and I think we can take a page from the OpenSearch guys on this one. The replaceable param scheme they use allows for either path or param, and it's trivial to do either with a simple regex. { ... thinks ... } What if a request to the base unAPI url returned a set of href templates, one for each "service" supported (such as 'go' and 'search')? It might look something like: { "status": 200, "formats": "http://example.com/unapi/formats", "go": "http://example.com/unapi/go/{URI}/{FORMAT}", "search": "http://example.com/unapi/?action=search&terms={TERMS}&format={FORMAT}"} That could actually be implemented as an index file, which wouldn't require any more admin access then the actual unAPI CGI (or whatever it is), and could even point off to another area on the same server, giving the option of moving the actual unAPI backend stuff without breaking any existing static content. > -Ross. > > _______________________________________________ > 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 lists at hubmed.org Mon Jan 16 22:02:16 2006 From: lists at hubmed.org (Alf Eaton) Date: Mon Jan 16 22:02:26 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> Message-ID: <2120B3DD-2782-42BD-B1BB-1C5EF38BE426@hubmed.org> On 16 Jan 2006, at 16:18, Kevin S. Clarke wrote: > That said, I found myself wanting to do a diff on the two to tease out > all the differences. Seeing them in one document definitely makes > that easier. I can't annotate the original, but here are the differences: 1) Made unAPI only about metadata (as a core function), not about providing the objects themselves (but see the resolve verb for that as an option). 2) Made the autodiscovery link optional, so you can put URI microformats in a page even if you don't have a unAPI service. 3) Removed the requirement for a visible URI in the page, made title="URI" mandatory instead. I have pages where a URI microformat is useful but don't want to display the identifier (and even if I did, it would look like "PMID: 12345678" rather than "info:pmid/ 12345678"). 4) Allowed the element to be anywhere within the element to which it refers. In fact this could be loosened further to be anywhere on the page - I haven't found an easy way to link identifiers with their identified objects that works. 5) No type on the autodiscovery link (as the response type could vary depending on the request). This depends on the final formats anyway. 6) Use HTTP status codes for responses. 7) Got rid of the */formats verb. The default response would be in the default format and would contain links to the other available formats. 8) Used params instead of path. Debatable, this one, but is http:// www.example.com/unapi/info%3Apmid%2F12345678/info%3Apmid%2F12345679/ info%3Apmid%2F12345680/rdf the best way to retrieve metadata for multiple URIs? 9) Allowed the use of Accept headers to determine the response format (if provided by the server and can be overridden by adding a format parameter). This is something that I find useful - can it cause problems? 10) Added optional verbs (I'm sure there are more): a) 'resolve' as a more descriptive alternative to 'go' - this redirects to the object itself, if available, not an HTML representation and b) 'search', which is a simplified version of OpenSearch. Ideally, unAPI service/format descriptions, Atom introspection documents (which seems to have gone a bit wayward, from what I can tell), RSD files and OpenSearch description files could all be rolled into one unAPI description document (which is what you'd get from calling /unapi). Maybe that's just asking for trouble though. alf. From azaroth at liverpool.ac.uk Tue Jan 17 12:18:29 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Jan 17 12:21:43 2006 Subject: [gcs-pcs-list] Re: unapi 0 Message-ID: When there's an issue with specifications, I try to boil down what it is that is wanted from the spec first, then figure out how to best enable it. In this case, we have the following uses (in my understanding): * Fetch an object. Allow the server to determine the format for the object, so that it can return a web page as html, a pdf as pdf, an image as the native format, etc. Allows the user to interact with the object in the format most suited to representing the object. * Fetch an object in a specified format. Request the object in a format suitable for the user to interact with in a way that they want. Eg, as a jpg, xml, raw text, or html. * Get list of all formats available. * Get list of all formats available for a specified object. Service description operation that allows the server to publish the formats that the object is available in, and all of the formats that it knows about. To me that looks like the following functions: fetch(identifier, ?format) => object format(?identifier) => list of formats with some metadata Obvious 'missing' functionality is a method to discover known identifiers. That is taken care of in v0 by a microformat in HTML. First of all let's compare to OAI. GetRecord returns the object in some sort of XML, with a bunch of XML wrapping around it and requires the format to be supplied. Unapi wants to be able to fetch 'default' formats and non xml formats. ListMetadataFormats is identical in functionality and parameters to the formats of unapi, however unapi wants the response to be easier to use than the output of ListMetadataFormats. In particular it proposes JSON. So... What is actually necessary? Minimalist: If we can offload the discovery of identifiers to a microformat, we can offload the discovery of formats to the same means. The global list of formats is then meaningless and can be done away with as you always know the possibilities for retrieving a particular object. The assumption here is that if you know an identifer a priori, you can also know the formats for it in the same way. As we don't need the formats descriptive function, we only have retrieval, so only need a URL construction rule. Parameters are generally easier to construct than a path, especially when one parameter might contain characters needing to be escaped. unapi/get?identifier=IDENTIFIER[&format=FORMAT] Then in the HTML, something like: identifier Not So Minimalist: All that we need to know for formats (either for object or global) is an identifier for the format. It would be nice to know the mime type of the response, a name for it, and a description. There's no need to go to XML or JSON. There's a perfectly function format called plain text. Simply return a text file of the format: identifier [tab] mime type [newline] If the name and description URL are wanted, just stick them on the end separated by tabs. Then the application has only to split each line by \t and it has all of the information required. No need for XML parsers, JSON parsers or any other sort of serialisation/deserialisation. To request it: unapi/format[?identifier=IDENTIFIER] Any less minimalist than this and you might as well use OAI :) Rob Sanderson From lists at hubmed.org Tue Jan 17 12:53:31 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Jan 17 12:56:50 2006 Subject: [gcs-pcs-list] Re: unapi 0 In-Reply-To: References: Message-ID: On 17 Jan 2006, at 12:18, Robert Sanderson wrote: > > When there's an issue with specifications, I try to boil down what > it is > that is wanted from the spec first, then figure out how to best enable > it. > > In this case, we have the following uses (in my understanding): > > > * Fetch an object. > Allow the server to determine the format for the object, so > that it can return a web page as html, a pdf as pdf, an image as > the native format, etc. > Allows the user to interact with the object in the format most > suited to representing the object. > > * Fetch an object in a specified format. > Request the object in a format suitable for the user to interact > with in a way that they want. > Eg, as a jpg, xml, raw text, or html. > While the rest of your reasoning makes sense, I disagree with fetching objects as the purpose of unAPI. If objects are retrievable, they already have their own URLs - unAPI should be about fetching metadata for identified objects (and perhaps pointing to the object's URL if available - a lot of the time the objects won't have URLs, ie they're not digital). Here's my use case (where I'm already using this, in a minimal form): In HubMed's pages, there is next to each search result (the results are scientific papers). HubMed doesn't have access to the full text of these papers (the object), but it does have the metadata for each one. Now I have a Greasemonkey script which identifies each uri span and inserts a 'post to CiteULike' link. When the user sends this link to CiteULike, a CiteULike plugin calls HubMed's unAPI service and retrieves the metadata for that identifier in the appropriate format (in this case it's BibTeX). At the moment the URL for requesting that metadata is hardcoded (the equivalent of ), but this would eventually be autodiscoverable by calling the base unAPI service (linked from the head of each HTML page) to find the available formats and the request parameters. Hopefully that can illuminate the process a bit. alf. From azaroth at liverpool.ac.uk Tue Jan 17 13:19:33 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Tue Jan 17 13:22:46 2006 Subject: [gcs-pcs-list] Re: unapi 0 In-Reply-To: References: Message-ID: On Tue, 17 Jan 2006, Alf Eaton wrote: >On 17 Jan 2006, at 12:18, Robert Sanderson wrote: >> In this case, we have the following uses (in my understanding): >> * Fetch an object. >> * Fetch an object in a specified format. >While the rest of your reasoning makes sense, I disagree with fetching >objects as the purpose of unAPI. If objects are retrievable, they >already have their own URLs [...] Not necessarily. They could be only available as items in a search. For example, you can't get directly to a book in the LoC by a URL, you need to use an SRU identifier search to find it. >In HubMed's pages, there is next to each search result (the results are >scientific papers). HubMed doesn't have access to the full text of >these papers (the object) Absolutely. That's because this isn't the right level for the identifier to be sent to you. Instead you should be sent an identifier for one of your records. instead of "info:pmid/123456" you should be getting something like "metadata(info:pmid/123456)" to retrieve the description of the article. In turn one might send "metadata(metadata(info:pmid/123456))" to retrieve the metadata about your description of the article (eg the size of the metadata, rather than the size of the article). Like with OAI and SRU, there's no reason why you shouldn't use it for any arbitrary metadata level available. Yes, metadata() is not a real function anywhere, but is a convenient notation. Rob From daniel.chudnov at yale.edu Tue Jan 17 14:11:41 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 14:11:43 2006 Subject: [gcs-pcs-list] before there was unAPI... Message-ID: <20060117191138.GA20256@sildin.med.yale.edu> I'm *really* excited that so many folks I admire and respect and, well, okay, I'll just say it, have little professional crushes on, are interested enough to get involved in developing unAPI so quickly. There must be something worthwhile in there, then, even if we don't quite know what it will end up looking like. I must have failed in setting the stage, however, and having done a lot of blind groping at elephants in a past life (don't ask) it seems best to just call a distressed leather fire hose a distressed leather fire hose (or, maybe, a trunk?) and step back to non-spec objectives to be sure we're starting from the same page. The only reason this list exists is that a group of people working on "personal collection systems", a.k.a. gather/create/share tools, met at a fancy meeting in Baltimore a year and a half ago to compare notes and ended up agreeing we should keep comparing notes on a list. A core requirement unearthed in the discussion we had way back when is that there isn't any single obvious way to build personal collection systems - by which we mean "personal library software" or anything remotely like it, many examples of which are now in vogue - that interoperate in obvious, simple ways. Sure, there are RSS, WebDAV, OAI, SCORM, METS, DIDLs, OpenURL, SPARQL, Atom, a few dozen sexy incompatible popular-webapp-APIs, and the still-coming-any-day Shibboleth, but, um, well, there, you see, that's the point. We have all this stuff, in all these systems, and people are building new ones every day with their own takes on the above or wholly new ones. But who wants sexy incompatible APIs? I don't. Sure, they're titillating to query, dress in something flashy, and maybe connect with nightly in a cronjob for a while, but ultimately they're incompatible. They won't last. Your engine gets upgraded, or the API spec gets bloated with new revisions, and after a while the excitement wears off, the windshield cracks, somebody keys your car in the supermarket lot, and you're driving around a six-year-old rustbucket with no trade-in value. Do you see what I mean? You started thinking I meant sex, but you ended up wondering whether I should get on a waitlist for that new hybrid sedan, didn't you. Incompatible APIs are such a scourge that I can't even keep a probably-too-risque-for-a-professional-list extended metaphor compatible with itself. I want compatible APIs, even if they're not sexy. *Especially* if they're not sexy. I want a simple, five-minutes-to-implement way to get something that interests me that I see over here into that other thing over there which is where I put stuff. You're in sakai, you're on a journal fulltext site, you're tagging photos, you're streaming podcasts, you're telling me about it in a syndication feed, and once in a while something you do catches my fancy and I want to take it from where you put it and keep a copy for myself in my own little hideaway or sakai course site or music sharing social tagging whatever. And then I want to put copies in other places later on when the context of what's interesting about that thing changes or becomes relevant again or it's just been so long that now it seems kitschy (as in ha-hah, remember when "library 2.0" was going to change the world? how charming.). The actual act of copying something from one place to another is fraught with landmines. A sketch of a masterpiece painting... a picture of a not-yet-released concept car... 58,000 ripped-and-burnt copies of the new Britnecca CD, a printed pdf of an obscure journal article. Nobody here needs that explained, nor an explanation of how the digital-copying piece is "easier", whatever that means, because we all know it's not. "Save a copy as..." my ass. I want stuff that simply knows how to move itself over from site A to service B when I ask it to, or for A and B to figure it out for themselves, whatever, but I don't want to have to think about it. (Er, I mean, the hypothetical "i", not the me-that-is-trying-to-write a spec-that-does-that, but the future-me-that-just-does-it-happily). As far as I can tell, the only efficient way toward such a future is if every site in the world supported a simple clipboard-copy function. Just like on desktops... copy from here, then do something else with it. That's why the spec says: "We want one API for the most basic operations necessary to perform simple clipboard-copy functions across all sites." Boil the oceans a degree, a little magic happens, and we can copy stuff around. But, you may ask: "What of OAI-PMH? ATOM? The succinctly-named Z39.88?" Good question. They're all great specs. They're all widely used. They could all be made to do this, in theory. The problem is this: they're all different. It is impossible to convince the *whole* non-library world to implement OAI or OpenURL. It is likewise impossible to convince the library world to put everything under Atom. Why? Because none of them are simple. Sure, compared to what came before, they are simple in some ways... any competent programmer should be able to build a working implementation of any of 'em in a few hours. Or a fairly-robust implementation in a few days. That that is true and possible is a major accomplishment of each of these specifications. The problem with that is that most competent programmers are already getting paid doing other things. We need something that incompetent programmers can implement. And forget this "few hours, few days" nonsense... we want something that incompetent programmers can implement in a few minutes. That's right, I said it: a few minutes. Seriously, that's what I'm after. A universal clipboard-copy API that incompetent programmers can implement in a few minutes. Anything less and the ocean doesn't boil. No magic happens. I keep butchering metaphors, and possibly escalate to more thorough offenses. Nobody wants that. OpenURL is great because it provides a convention to pass info that identifies objects of interest and allows their movement between applications or across service layers of a single app. That's why we worked on COinS, and that's why unAPI has a URI microfauxmat component. OAI is great because it gives you direct access to disseminations of objects in arbitrary formats. That's why unAPI has a "formats" function and something equivalent to GetRecord. Atom is great because it's going to be nearly everywhere and it has an in-html autodiscovery pattern that has already succeeded massively, and because it gives you a synopsis of objects and a way to get back to host services' for-human-rendering of those objects. That's part of why unAPI has a "go" function. The other reason unAPI has a "go" function is that it would save everybody a lot of time if service resolver knowledgebases didn't have to track changing and incompatible linking syntaxeses. The other great thing about OAI, Atom, and OpenURL is that because there are so many implementations, it's likely that your own content-owning applications already speak at least one of them. That's why the unAPI spec says: "We also want this API to be able to be easily layered on top of other well-known APIs." So if you already do Atom, OAI, SRU, OpenSearch, or whatever, an incompetent programmer can layer unAPI over one or more of those in a few minutes. And everybody gets to copy stuff around. And then we can start to talk about pasting, but I don't think we can reasonably do that yet until we get past the copying part, since the one will drive demand for the other, but without the copy-function providing supply, there is no demand for standard paste. Or, maybe Atom's API will be good enough for paste. I don't know, because for 1.5 years I've been beating my head against copy, and I'm tired of it and want to move on. That's the goal of unAPI. Or, at least, that's what I see as the goal of unAPI. Does that help at all? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jeremy.frumkin at oregonstate.edu Tue Jan 17 17:52:43 2006 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Tue Jan 17 17:53:48 2006 Subject: [gcs-pcs-list] before there was unAPI... In-Reply-To: <20060117191138.GA20256@sildin.med.yale.edu> Message-ID: descending down from lurker altitude.... So, one of the areas of ambiguity may reside in the current spec?s objective statement. It currently reads: ?The objective of unAPI is to enable web sites with HTML interfaces to information-rich objects to simultaneously publish richly structured metadata for those objects, or those objects themselves, in a predictable and consistent way for machine processing.? Instead, it might be better to state: ?The objective of unAPI is to enable web sites which provide HTML interfaces to their information-rich objects to simultaneously publish richly structured metadata for those objects, and publish this metadata in a predictable and consistent way which easily enables machine processing?. The goal is still to get to the copy function Dan describes, and the mechanism is through unAPI via the standardization of metadata publishing and functional calls. On a side note, one of the presentations at code4lib will be by a project which seeks to solve both the ?copy? and ?paste? issues (Robby Robson). That should be an interesting talk, considering. :-) -- jaf On 1/17/06 11:11 AM, "Daniel Chudnov" wrote: > I'm *really* excited that so many folks I admire and respect and, > well, okay, I'll just say it, have little professional crushes on, > are interested enough to get involved in developing unAPI so quickly. > There must be something worthwhile in there, then, even if we don't > quite know what it will end up looking like. > > I must have failed in setting the stage, however, and having done a lot > of blind groping at elephants in a past life (don't ask) it seems best to > just call a distressed leather fire hose a distressed leather fire hose > (or, maybe, a trunk?) and step back to non-spec objectives to be sure > we're starting from the same page. > > The only reason this list exists is that a group of people working on > "personal collection systems", a.k.a. gather/create/share tools, met > at a fancy meeting in Baltimore a year and a half ago to compare notes > and ended up agreeing we should keep comparing notes on a list. > > A core requirement unearthed in the discussion we had way back when is > that there isn't any single obvious way to build personal collection > systems - by which we mean "personal library software" or anything > remotely like it, many examples of which are now in vogue - that > interoperate in obvious, simple ways. Sure, there are RSS, WebDAV, OAI, > SCORM, METS, DIDLs, OpenURL, SPARQL, Atom, a few dozen sexy incompatible > popular-webapp-APIs, and the still-coming-any-day Shibboleth, but, > um, well, there, you see, that's the point. We have all this stuff, > in all these systems, and people are building new ones every day with > their own takes on the above or wholly new ones. > > But who wants sexy incompatible APIs? I don't. Sure, they're titillating > to query, dress in something flashy, and maybe connect with nightly in > a cronjob for a while, but ultimately they're incompatible. They won't > last. Your engine gets upgraded, or the API spec gets bloated with new > revisions, and after a while the excitement wears off, the windshield > cracks, somebody keys your car in the supermarket lot, and you're driving > around a six-year-old rustbucket with no trade-in value. > > Do you see what I mean? You started thinking I meant sex, but you > ended up wondering whether I should get on a waitlist for that new > hybrid sedan, didn't you. Incompatible APIs are such a scourge that I > can't even keep a probably-too-risque-for-a-professional-list extended > metaphor compatible with itself. > > I want compatible APIs, even if they're not sexy. *Especially* if > they're not sexy. I want a simple, five-minutes-to-implement way to > get something that interests me that I see over here into that other > thing over there which is where I put stuff. You're in sakai, you're > on a journal fulltext site, you're tagging photos, you're streaming > podcasts, you're telling me about it in a syndication feed, and once > in a while something you do catches my fancy and I want to take it from > where you put it and keep a copy for myself in my own little hideaway or > sakai course site or music sharing social tagging whatever. And then I > want to put copies in other places later on when the context of what's > interesting about that thing changes or becomes relevant again or it's > just been so long that now it seems kitschy (as in ha-hah, remember when > "library 2.0" was going to change the world? how charming.). > > The actual act of copying something from one place to another is fraught > with landmines. A sketch of a masterpiece painting... a picture of a > not-yet-released concept car... 58,000 ripped-and-burnt copies of the new > Britnecca CD, a printed pdf of an obscure journal article. Nobody here > needs that explained, nor an explanation of how the digital-copying > piece is "easier", whatever that means, because we all know it's not. > "Save a copy as..." my ass. I want stuff that simply knows how to move > itself over from site A to service B when I ask it to, or for A and B > to figure it out for themselves, whatever, but I don't want to have to > think about it. > > (Er, I mean, the hypothetical "i", not the me-that-is-trying-to-write > a spec-that-does-that, but the future-me-that-just-does-it-happily). > > As far as I can tell, the only efficient way toward such a future is > if every site in the world supported a simple clipboard-copy function. > Just like on desktops... copy from here, then do something else with > it. That's why the spec says: > > "We want one API for the most basic operations necessary to perform > simple clipboard-copy functions across all sites." > > Boil the oceans a degree, a little magic happens, and we can copy stuff > around. > > But, you may ask: "What of OAI-PMH? ATOM? The succinctly-named Z39.88?" > > Good question. They're all great specs. They're all widely used. > They could all be made to do this, in theory. > > The problem is this: they're all different. It is impossible to convince > the *whole* non-library world to implement OAI or OpenURL. It is likewise > impossible to convince the library world to put everything under Atom. > > Why? Because none of them are simple. Sure, compared to what came > before, they are simple in some ways... any competent programmer should > be able to build a working implementation of any of 'em in a few hours. > Or a fairly-robust implementation in a few days. That that is true and > possible is a major accomplishment of each of these specifications. > > The problem with that is that most competent programmers are already > getting paid doing other things. We need something that incompetent > programmers can implement. And forget this "few hours, few days" > nonsense... we want something that incompetent programmers can implement > in a few minutes. That's right, I said it: a few minutes. > > Seriously, that's what I'm after. A universal clipboard-copy API that > incompetent programmers can implement in a few minutes. Anything less and > the ocean doesn't boil. No magic happens. I keep butchering metaphors, > and possibly escalate to more thorough offenses. > > Nobody wants that. > > OpenURL is great because it provides a convention to pass info that > identifies objects of interest and allows their movement between > applications or across service layers of a single app. That's why we > worked on COinS, and that's why unAPI has a URI microfauxmat component. > > OAI is great because it gives you direct access to disseminations of > objects in arbitrary formats. That's why unAPI has a "formats" > function and something equivalent to GetRecord. > > Atom is great because it's going to be nearly everywhere and it has an > in-html autodiscovery pattern that has already succeeded massively, and > because it gives you a synopsis of objects and a way to get back to host > services' for-human-rendering of those objects. That's part of why unAPI > has a "go" function. The other reason unAPI has a "go" function is that > it would save everybody a lot of time if service resolver knowledgebases > didn't have to track changing and incompatible linking syntaxeses. > > The other great thing about OAI, Atom, and OpenURL is that because > there are so many implementations, it's likely that your own content-owning > applications already speak at least one of them. That's why the > unAPI spec says: > > "We also want this API to be able to be easily layered on top of other > well-known APIs." > > So if you already do Atom, OAI, SRU, OpenSearch, or whatever, an > incompetent programmer can layer unAPI over one or more of those in a > few minutes. And everybody gets to copy stuff around. And then we > can start to talk about pasting, but I don't think we can reasonably > do that yet until we get past the copying part, since the one will > drive demand for the other, but without the copy-function providing > supply, there is no demand for standard paste. Or, maybe Atom's API > will be good enough for paste. I don't know, because for 1.5 years > I've been beating my head against copy, and I'm tired of it and want > to move on. > > That's the goal of unAPI. Or, at least, that's what I see as the goal > of unAPI. > > Does that help at all? > > -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 > =============================================== Jeremy Frumkin The Gray Chair for Innovative Library Services 121 The Valley Library, Oregon State University Corvallis OR 97331-4501 Jeremy.Frumkin@oregonstate.edu 541.737.9928 541.737.3453 (Fax) 541.230.4483 (Cell) =============================================== " Without ambition one starts nothing. Without work one finishes nothing. " - Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060117/6de1289e/attachment-0001.htm From daniel.chudnov at yale.edu Tue Jan 17 22:18:34 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 22:18:35 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <43CC2497.2000908@yahoo.com> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: <20060118031833.GD20256@sildin.med.yale.edu> Steve Toub wrote, on Mon, Jan 16, 2006 at 02:56:23PM -0800: > > The only thing I feel like I don't really understand is why Dan's first > draft had it's own scheme for responses. I guess I'm assuming a regular > HTTP response with XML (or JSON or whatever) in the payload is fine. I didn't mean it to sound like the specified JSON responses were anything but an HTTP response with a JSON payload. It should be possible to receive an 200 Ok response from the http server (your query worked) that nonetheless returns nothing because a URI isn't found (404 Not found). Or, maybe that's perverse. In any case, on apps I'm working on separately, I pass a little status code through JSON response payloads to verify that AJAXy calls worked. In these cases, it's helpful to have this application-layer response code so I know how to stack callbacks and such. Like i said, maybe it's perverse, and if a URI is not found, the server should return 404, higher application layer be damned. > * At first blush, I liked the params better than the fixed paths, since > I gives more flexibility and avoids fixing the path order. But then I > wondered if it's as easy (technically) to rewrite URIs from paths to > params as it is from params to paths. I thought so. There seems to be a lot of sentiment against that, which hasn't been backed up by a lot of code. Alf and Ross said it was a problem in their code. This as a trivial change... if params are easier, let's do params. > * I like the idea of single (introspect/explain) verb that lists all > available API calls implemented on the server. And the ability to apply > that verb to a single identifier. Do you imagine that the available API calls on the server might vary per object? This seems easier to imagine for object formats than API services. > * Wondering how well the syntax scales for servers that have the ability > to assembled different descriptive metadata schemes inside different > containers (e.g., MODS in DIDL, MODS in METS, MODS in IMS-CP) and > expressed in different notation: XML, RDF, etc. Good point... a difficult issue. But, this is a hard case to solve and I'd rather focus on getting the simple bits right first. > * Syntax seems to assume just a access service (get/view) rather than > the full range of verbs (ingest, manage, etc.) and seems assume > "resources" rather than other data types (tags, people, etc.). Ok for > these to be shortcuts, but wondering how it scales when the API includes > a fuller range of methods and data types. See my earlier msg today about other methods... I don't think we should work on them yet. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Jan 17 22:21:13 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 22:21:15 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: <20060118032113.GE20256@sildin.med.yale.edu> Ed Summers wrote, on Mon, Jan 16, 2006 at 05:26:59PM -0600: > > Yes, I am interested in this too. Dan if you are targeting this as a > copy/paste sort of api how does one paste? > > >From my somewhat uninformed perspective it seems to me that if unAPI > were to have full RESTful powers it would be getting very close to the > atom publishing protocol [1]. Like I said, I don't think we should work on this yet. Atom might do everything we need, but it's not done. And the publishing protocol is not simple. I need to be able to work on both ends of clipboard apps today, and I don't think all the complexity of Atom is necessary to do this stuff. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Jan 17 22:22:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 22:22:55 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <064EA657-7104-4908-998D-316D63DC25D1@hubmed.org> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <064EA657-7104-4908-998D-316D63DC25D1@hubmed.org> Message-ID: <20060118032254.GF20256@sildin.med.yale.edu> Alf Eaton wrote, on Mon, Jan 16, 2006 at 09:35:14PM -0500: > > about metadata and b) Atom commands work only on one URI at a time > (ie GET to fetch a document, POST to update it, DELETE to delete it, > etc), rather than requesting metadata for a string of URIs at once - > but maybe you'd want unAPI to work that way too using a series of > requests for multiple URIs... The draft I published didn't say anything about operating on multiple URIs at one time. I think we can avoid dealing with that entirely for now. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Jan 17 22:27:08 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 22:27:11 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> Message-ID: <20060118032708.GG20256@sildin.med.yale.edu> Mike Rylander wrote, on Tue, Jan 17, 2006 at 02:48:18AM +0000: > > What if a request to the base unAPI url returned a set of href > templates, one for each "service" supported (such as 'go' and > 'search')? It might look something like: > > { "status": > 200, > "formats": > "http://example.com/unapi/formats", > "go": > "http://example.com/unapi/go/{URI}/{FORMAT}", > "search": > "http://example.com/unapi/?action=search&terms={TERMS}&format={FORMAT}"} I like this a lot. I'm not sure we should repeat OpenSearch's description syntax, vs. just pointing to the description file, but why not. :) Module that it conflates the "go" function -- give me *your* webapp's default html representation of this object -- with what Rob aptly called "fetch" -- give me this object in *this specific* format / representation. They're two different things... one's not a default for the other. One way to think of it is that the "go" function gives you "something for humans to read about this object" and "fetch" gives you something humans or machines might want, depending. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Tue Jan 17 22:40:43 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Jan 17 22:44:20 2006 Subject: [gcs-pcs-list] Re: unapi 0 In-Reply-To: References: Message-ID: <3FBD77B4-DC12-4600-8AE6-7864DF917DA5@hubmed.org> On 17 Jan 2006, at 13:19, Robert Sanderson wrote: > > On Tue, 17 Jan 2006, Alf Eaton wrote: >> On 17 Jan 2006, at 12:18, Robert Sanderson wrote: > >>> In this case, we have the following uses (in my understanding): >>> * Fetch an object. >>> * Fetch an object in a specified format. > >> While the rest of your reasoning makes sense, I disagree with >> fetching >> objects as the purpose of unAPI. If objects are retrievable, they >> already have their own URLs [...] > > Not necessarily. They could be only available as items in a search. > For example, you can't get directly to a book in the LoC by a URL, you > need to use an SRU identifier search to find it. > >> In HubMed's pages, there is next to each search result (the results are >> scientific papers). HubMed doesn't have access to the full text of >> these papers (the object) > > Absolutely. > > That's because this isn't the right level for the identifier to be > sent > to you. Instead you should be sent an identifier for one of your > records. > > instead of "info:pmid/123456" you should be getting something like > "metadata(info:pmid/123456)" to retrieve the description of the > article. > > In turn one might send "metadata(metadata(info:pmid/123456))" to > retrieve the metadata about your description of the article (eg the > size > of the metadata, rather than the size of the article). > > Like with OAI and SRU, there's no reason why you shouldn't use it for > any arbitrary metadata level available. > > Yes, metadata() is not a real function anywhere, but is a convenient > notation. OK, I've come round to the way of thinking now where the object identified by the URI and its metadata are (for these purposes) one and the same thing. This means that requesting /unapi? uri=URI&format=FORMAT would give you as much of the object itself and it's accompanying metadata as a) is available to the server and b) fits into the requested format. This would mean that if you requested some music as in MP3 format, you'd get the work itself plus metadata as ID3 tags. If you requested it in RIS format, you'd only get the metadata. If you requested a weblog post in Atom format, you'd get the post plus its metadata as Atom markup; if you requested the post in RDF you'd also get both the content and its metadata; if you requested it in BibTeX, you'd probably only get the metadata, plus perhaps an abstract. I think this is simpler than requiring a specific 'metadata' verb. alf. From lists at hubmed.org Tue Jan 17 22:43:46 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Jan 17 22:47:04 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118032708.GG20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> <20060118032708.GG20256@sildin.med.yale.edu> Message-ID: <27D91E92-CEB5-4514-83E0-3FCAAD05718B@hubmed.org> On 17 Jan 2006, at 22:27, Daniel Chudnov wrote: > One way to think of it is that the "go" function gives you "something > for humans to read about this object" and "fetch" gives you something > humans or machines might want, depending. What's the difference between /unapi/go/URI and /unapi/URI/html ? It seems like they would both end up at a HTML representation of the object. alf. From lists at hubmed.org Tue Jan 17 22:48:31 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Jan 17 22:48:40 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> Message-ID: <7F21AA67-81D9-47BA-A384-DE68A5AFA393@hubmed.org> On 16 Jan 2006, at 18:26, Ed Summers wrote: >> * Syntax seems to assume just a access service (get/view) rather than >> the full range of verbs (ingest, manage, etc.) and seems assume >> "resources" rather than other data types (tags, people, etc.). Ok for >> these to be shortcuts, but wondering how it scales when the API >> includes a fuller range of methods and data types. > > Yes, I am interested in this too. Dan if you are targeting this as a > copy/paste sort of api how does one paste? In (abstracted) theory, it should be as simple as telling the service you're pasting to to fetch the resource from the other server's unAPI. The problem arrives when that resource is under authentication control (a journal article PDF, say). I've been trying for ages to figure out how to make a Firefox extension that could store a file like that locally (say in Firefox's profile folder, or in /tmp) then automatically upload it to another server - if anyone has any ideas I'd be very pleased to hear them. alf. From daniel.chudnov at yale.edu Tue Jan 17 23:02:17 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 17 23:02:20 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <27D91E92-CEB5-4514-83E0-3FCAAD05718B@hubmed.org> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> <20060118032708.GG20256@sildin.med.yale.edu> <27D91E92-CEB5-4514-83E0-3FCAAD05718B@hubmed.org> Message-ID: <20060118040217.GI20256@sildin.med.yale.edu> Alf Eaton wrote, on Tue, Jan 17, 2006 at 10:43:46PM -0500: > On 17 Jan 2006, at 22:27, Daniel Chudnov wrote: > > >One way to think of it is that the "go" function gives you "something > >for humans to read about this object" and "fetch" gives you something > >humans or machines might want, depending. > > What's the difference between /unapi/go/URI and /unapi/URI/html ? It > seems like they would both end up at a HTML representation of the > object. Take the use case of a somewhat lengthy poem, say, 200 stanzas, long enough that you have to click to go from one page to the next. A lot of digital library apps implement "pageturners" which make this process smoother. So does amazon's "see inside the book", google books, etc. UNAPI/go/URI takes you to the starting point of that pageturning app. It's the webapp's native notion of "where people should start" w/r/to that object. A human interface. UNAPI/URI/html might take you instead to a lengthy bare-html rendering of the content of the whole poem itself. No nice page template header or footer, no page turner, nothing... just the html-marked-up poem. Same thing might apply to a tech artcile at onlamp.com. UNAPI/go/URI takes you to the human lead-in page with "next page page 2 page 3 page 4" links at the bottom. UNAPI/URI/html might take you to the more-bare "print this page" view. Again, Rob's suggestion of a "fetch" function to keep the url pattern consisten, e.g. UNAPI/fetch/URI/html, seems compelling. In the case of an audio recording, UNAPI/go/URI takes you to the track list. UNAPI/fetch/URI/mp3 takes you to the raw data. I think the main reason you can't merge the two is that you can't rightly make assumptions about what the object-hosting webapp's native idea of a human interface to the object is going to be. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Tue Jan 17 23:50:34 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Jan 17 23:51:37 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118031833.GD20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <20060118031833.GD20256@sildin.med.yale.edu> Message-ID: On 1/18/06, Daniel Chudnov wrote: > Steve Toub wrote, on Mon, Jan 16, 2006 at 02:56:23PM -0800: > > > > The only thing I feel like I don't really understand is why Dan's first > > draft had it's own scheme for responses. I guess I'm assuming a regular > > HTTP response with XML (or JSON or whatever) in the payload is fine. > > I didn't mean it to sound like the specified JSON responses were anything > but an HTTP response with a JSON payload. > > It should be possible to receive an 200 Ok response from the http server > (your query worked) that nonetheless returns nothing because a URI isn't > found (404 Not found). Or, maybe that's perverse. Not perverse. We do exactly that in OpenILS/Evergreen. We consider an apache or gateway module different (at a lower layer) than an OpenSRF (backend) 404 or 500 message. We modeled our backend status codes after HTTP's, but they operate at different layers in the stack and are handled/recovered from by different bits of code. > > In any case, on apps I'm working on separately, I pass a little status > code through JSON response payloads to verify that AJAXy calls worked. > In these cases, it's helpful to have this application-layer response > code so I know how to stack callbacks and such. > > Like i said, maybe it's perverse, and if a URI is not found, the > server should return 404, higher application layer be damned. > > > > * At first blush, I liked the params better than the fixed paths, since > > I gives more flexibility and avoids fixing the path order. But then I > > wondered if it's as easy (technically) to rewrite URIs from paths to > > params as it is from params to paths. > > I thought so. There seems to be a lot of sentiment against that, which > hasn't been backed up by a lot of code. Alf and Ross said it was a > problem in their code. This as a trivial change... if params are easier, > let's do params. > For simple things (go and formats), mod_rewrite should be trivial. For more complex urls it gets ... tricky. I think an introspection document is the easiest way to handle it, personally. > > > * I like the idea of single (introspect/explain) verb that lists all > > available API calls implemented on the server. And the ability to apply > > that verb to a single identifier. > > Do you imagine that the available API calls on the server might vary > per object? This seems easier to imagine for object formats than API > services. > > > > * Wondering how well the syntax scales for servers that have the ability > > to assembled different descriptive metadata schemes inside different > > containers (e.g., MODS in DIDL, MODS in METS, MODS in IMS-CP) and > > expressed in different notation: XML, RDF, etc. > > Good point... a difficult issue. But, this is a hard case to solve > and I'd rather focus on getting the simple bits right first. > I'm not clear on this, I think. Steve, were you thinking of pointing at collections of objecs with one URI? If not, and you were thinking of creating collections by requesting multiple URIs at once, then there's a message down-thread discarding that notion (for the time being, anyway). > > > * Syntax seems to assume just a access service (get/view) rather than > > the full range of verbs (ingest, manage, etc.) and seems assume > > "resources" rather than other data types (tags, people, etc.). Ok for > > these to be shortcuts, but wondering how it scales when the API includes > > a fuller range of methods and data types. > > See my earlier msg today about other methods... I don't think we should > work on them yet. > > -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 mrylander at gmail.com Tue Jan 17 23:58:45 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Jan 17 23:59:48 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118032708.GG20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> <20060118032708.GG20256@sildin.med.yale.edu> Message-ID: On 1/18/06, Daniel Chudnov wrote: > Mike Rylander wrote, on Tue, Jan 17, 2006 at 02:48:18AM +0000: > > > > What if a request to the base unAPI url returned a set of href > > templates, one for each "service" supported (such as 'go' and > > 'search')? It might look something like: > > > > { "status": > > 200, > > "formats": > > "http://example.com/unapi/formats", > > "go": > > "http://example.com/unapi/go/{URI}/{FORMAT}", > > "search": > > "http://example.com/unapi/?action=search&terms={TERMS}&format={FORMAT}"} > > I like this a lot. I'm not sure we should repeat OpenSearch's description > syntax, vs. just pointing to the description file, but why not. :) > I was mentioning OpenSearch in a more hand-wavy, conceptual sense, but I'm glad the point came across OK. :) There should be some more structure to the introspection doc than what I used as an example, I think, but I wanted to get the idea out there. > Module that it conflates the "go" function -- give me *your* webapp's > default html representation of this object -- with what Rob aptly > called "fetch" -- give me this object in *this specific* format / > representation. > > They're two different things... one's not a default for the other. You lost me for a sec there, but now I see what you mean. Right. The example there isn't to spec (heh). I was more just trying to get the idea of mixing param-based and path-base unAPI template URLs on one server shouldn't be a problem if we decouple the actual URLs from the verbs by creating the introspection mechanism. We could even add a "default URL scheme" to the spec so that the introspection doc isn't strictly required. -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From stoub at yahoo.com Wed Jan 18 01:56:21 2006 From: stoub at yahoo.com (Steve Toub) Date: Wed Jan 18 01:57:34 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118031833.GD20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <20060118031833.GD20256@sildin.med.yale.edu> Message-ID: <43CDE695.8050905@yahoo.com> >> * I like the idea of single (introspect/explain) verb that lists all >> available API calls implemented on the server. And the ability to apply >> that verb to a single identifier. > > Do you imagine that the available API calls on the server might vary > per object? This seems easier to imagine for object formats than API > services. I was assuming a single call/syntax would self-document both the fetch service (and its ?format options) as well any other hypothetical service (and their options) that might emerge. I can foresee scenarios where services available to an object might vary per collection of objects or based on roles/permissions but I wrote this was back when I assumed the scope was far more expansive. More than ok to ignore those cases in the interest of simplicity. A tangential and probably destructive aside: my distressed leather fire hose is hung up on the "un" part of the "unAPI" (for some reason I had it in my head this stood for "universal"...). Some possibilities for acronyms that communicate what I now understand to be the intended scope: Clipi [Clipboard Interface] UnC [Universal Copy] --SET From azaroth at liverpool.ac.uk Wed Jan 18 05:24:55 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed Jan 18 05:28:10 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118040217.GI20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <8c92201a19605c11ddc15d262954f3db@library.gatech.edu> <20060118032708.GG20256@sildin.med.yale.edu> <27D91E92-CEB5-4514-83E0-3FCAAD05718B@hubmed.org> <20060118040217.GI20256@sildin.med.yale.edu> Message-ID: On Tue, 17 Jan 2006, Daniel Chudnov wrote: >Alf Eaton wrote, on Tue, Jan 17, 2006 at 10:43:46PM -0500: >> >One way to think of it is that the "go" function gives you "something >> >for humans to read about this object" and "fetch" gives you something >> >humans or machines might want, depending. >> >> What's the difference between /unapi/go/URI and /unapi/URI/html ? It >> seems like they would both end up at a HTML representation of the >> object. > >Take the use case of a somewhat lengthy poem, say, 200 stanzas, long >enough that you have to click to go from one page to the next. >UNAPI/go/URI takes you to the starting point of that pageturning app. >UNAPI/URI/html might take you instead to a lengthy bare-html rendering >I think the main reason you can't merge the two is that you can't rightly >make assumptions about what the object-hosting webapp's native idea of >a human interface to the object is going to be. I don't see why you need to make assumptions about the web-apps native human interface? Fetch returns the object in a client specified format. (id, fmt) Go returns the object in a format not specified by the client. It might be specified by the unapi interface, or unapi might simply pass the request along to another server which determines it. (id) Both can be implemented with the same function using an optional fmt parameter. The only way that you couldn't implement them with the same function(/verb/operation/whatever) is if the response type was different -- for example if go returned the object and fetch returned the object wrapped in metadata structures. You could equally have a format called 'native' which returned the object in its native environment. What you might not be able to have, and this might be what you were implying, was an entry in formats for the mime type [{name: native, mimetype: ???}]. However it seems that you've defined go to always return a web page? Or can it return other formats? On that front, if the native interface is xml+xslt (eg an xslt client to SRU), then it won't return HTML, it'll return xml with a stylesheet... I'm not sure that fits your definition of native. Equally if my objects are PDF, and my native view of those objects is simply to return them as PDF, it won't be any sort of html. It will be identical to what you'd expect from unapi/fetch/id/pdf Overall, I think once you tidy up the definitions, you'll find that go and fetch can be rolled into one. Rob From azaroth at liverpool.ac.uk Wed Jan 18 05:34:25 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed Jan 18 05:34:28 2006 Subject: [gcs-pcs-list] unAPI version 0 In-Reply-To: <20060118031833.GD20256@sildin.med.yale.edu> References: <316E4AC7-8BE1-4575-8EB6-E74E4E0A3E1D@yale.edu> <114F78ED-0FB2-4191-9827-41DC20DBE585@hubmed.org> <29680C67-CBFF-49D8-B20E-CA0C02BC75A4@yale.edu> <3557b8d0601161318j6f877e84t4c266016b004ba7b@mail.gmail.com> <43CC2497.2000908@yahoo.com> <20060118031833.GD20256@sildin.med.yale.edu> Message-ID: >Like i said, maybe it's perverse, and if a URI is not found, the >server should return 404, higher application layer be damned. Easiest, and I believe that's the mot-du-jour, would be to not have a header in the response. >> * At first blush, I liked the params better than the fixed paths, since >I thought so. There seems to be a lot of sentiment against that, which >hasn't been backed up by a lot of code. Alf and Ross said it was a In my implementation I wrote it first against path, but ran into the changing format of the path. If fetch/uri/format is approved, it makes no difference to me, but I can see that other implementation methods would still find it easier with params. >> * I like the idea of single (introspect/explain) verb that lists all >> available API calls implemented on the server. And the ability to apply >> that verb to a single identifier. > >Do you imagine that the available API calls on the server might vary >per object? This seems easier to imagine for object formats than API >services. Do you imagine that unapi will ever have more than go/fetch and formats? If not, why do you need this? If the calls are out of scope, then so is the method to discover them. If yes, then versioning, introspection/service description and a raft of other issues come into focus. >> * Wondering how well the syntax scales for servers that have the ability >> to assembled different descriptive metadata schemes inside different >> containers (e.g., MODS in DIDL, MODS in METS, MODS in IMS-CP) and >> expressed in different notation: XML, RDF, etc. > >Good point... a difficult issue. But, this is a hard case to solve >and I'd rather focus on getting the simple bits right first. Easy issue: unapi/fetch/URI/mods+mets+xml unapi/fetch/URI/mods+didl+rdf etc. Just leave it up to the server to determine the names, there is no problem, move along. >> * Syntax seems to assume just a access service (get/view) rather than >> the full range of verbs (ingest, manage, etc.) and seems assume >> "resources" rather than other data types (tags, people, etc.). Ok for >> these to be shortcuts, but wondering how it scales when the API includes >> a fuller range of methods and data types. >See my earlier msg today about other methods... I don't think we should >work on them yet. I don't think that fits within the definition of the project. CRUD and annotate aren't necessary for a copy/paste protocol. Do you want something that's easy to implement or has a lot of functionality? Pick one, stick to it. Rob From daniel.chudnov at yale.edu Thu Jan 19 10:35:51 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Jan 19 10:35:53 2006 Subject: [gcs-pcs-list] what would atom responses look like? Message-ID: <20060119153551.GA23757@sildin.med.yale.edu> Alf, or anyone, could you provide examples of what atom responses might look like? I'd like to see how such would look as hAtom-style xhtml, too. -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Jan 19 11:45:27 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Jan 19 11:49:18 2006 Subject: [gcs-pcs-list] what would atom responses look like? In-Reply-To: <20060119153551.GA23757@sildin.med.yale.edu> References: <20060119153551.GA23757@sildin.med.yale.edu> Message-ID: <0B04DDFA-DAFB-4B4F-832F-A806D8638414@hubmed.org> On 19 Jan 2006, at 10:35, Daniel Chudnov wrote: > Alf, or anyone, could you provide examples of what atom responses > might > look like? > > I'd like to see how such would look as hAtom-style xhtml, too. > > -dc I'm having trouble pinning down exactly what an Atom introspection document is supposed to look like - there are a lot of different proposed versions floating around, some of which would be useful for our purposes and some of which wouldn't. So it's probably best to say, in generic XML, that it would be as simple as a root node containing a bunch of , plus a linked XSL file that would turn those into human-readable links (in XHTML). I can't decide whether it would be useful to put basic metadata (object title, creator, creation data, etc) in there as well or not. alf. From lists at hubmed.org Thu Jan 19 12:43:40 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Jan 19 12:43:49 2006 Subject: [gcs-pcs-list] what would atom responses look like? In-Reply-To: <20060119153551.GA23757@sildin.med.yale.edu> References: <20060119153551.GA23757@sildin.med.yale.edu> Message-ID: Alternatively, ignoring Atom for now (it makes things too complicated), here's the minimum response I can imagine working: For a request to http://www.example.com/unapi (showing formats that are available for all URIs): and for a request to http://www.example.com/unapi/info%3Apmid% 2F12345678/audio%2Fmpeg (ie a format for which the item can't be returned): This would assume that all requests have to be in the form BASE_URL/ URI/FORMAT where FORMAT is a MIME type If there's no FORMAT, the item is returned in its default format (as an openurl resolver would do, for example). Does that make any sense? alf. From daniel.chudnov at yale.edu Tue Jan 24 19:17:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Jan 24 19:17:59 2006 Subject: [gcs-pcs-list] unAPI: 10 day recap Message-ID: <20060125001753.GD24802@sildin.med.yale.edu> unAPI version 0 has been around for about 10 days. Here's where it seems to stand today: - It doesn't explain what it's for well enough that everybody gets it right away - Its verb patterns are mixed up and inconsistent - There's some confusion over how many verbs there should be and what they should mean - There's been some disagreement about relationships between "objects", "object disseminations", "human views", and FRBRy issues like work vs. manifestation - Its default response format is "invisible data", i.e. not human- readable, and in a syntax (JSON) that people don't know well yet - It doesn't answer the obvious questions "why not Foo?" where {foo in (Atom, OAI, SRU, ...)} - It's not short enough - It's only led to two or three implementations so far All of which is just fine for a first draft. :) That said: - Lots of people are interested. - It has drawn numerous smart folks into the discussion - It is certain that we have enough smart and interested folks to revise it well and fix the problems above within the timeline originally set out, even if each revision only "solves" a few issues at a time. Maybe we could proceed a little more step-wise. Perhaps we can take the problems above one at a time and try to reach little mini-consensuseses, from the simplest problem (probably the verb pattern part first) on up. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Jan 25 12:07:21 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jan 25 12:08:29 2006 Subject: [gcs-pcs-list] issue summary: paths vs. params Message-ID: <2BCA2C83-D155-4AFF-B502-1339EBAEBD5A@yale.edu> Here's a summary of what's been said so far about paths vs. params. Note: it's *just* about paths vs. params. Not about what the verbs should be or what they mean, *just* paths and params. I'll follow with another msg suggesting a revision. -dc unAPI version 0 requires fixed paths. Alf suggested a single path with only params: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000290.html e.g. UNAPI?uri=URI&format=FORMAT Ross said he votes for params over paths for configuration flexibility: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000290.html Mike suggested an OpenSearch-like specify-the-url pattern in the introspection document (ignoring response type for now!): http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000299.html e.g. "go": "http://example.com/unapi/go/{URI}/{FORMAT}" "search": "http://example.com/unapi/?action=search&terms={TERMS}&format= {FORMAT}" Mike later added: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000314.html "For simple things (go and formats), mod_rewrite should be trivial. For more complex urls it gets ... tricky. I think an introspection document is the easiest way to handle it, personally." Rob said: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000318.html "If fetch/uri/format is approved, it makes no difference to me, but I can see that other implementation methods would still find it easier with params." Alf later said that params are better for multiple URIs (though unAPI version 0 does not support multiple URIs in one call (sorry, Alf, it's just easier to revise against the original doc :)). http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000300.html -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Jan 25 12:30:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jan 25 12:32:00 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params Message-ID: <7928FD6E-F218-4120-BE54-65D57E9F5518@yale.edu> (Note: I've reordered the "Open questions for revision 1" basecamp to-do list into easiest-to-hardest order. This topic covers the first two items: #unAPI developers: Are GET params better than a fixed path? #unAPI developers: Can the path order be made more consistent? ...fyi, we are using basecamp to manage the "paperwork" part of developing this spec, and all participants are welcome to have access to basecamp project. That said, there is nothing "hidden" in the basecamp project site that will not be usefully communicated here. So you don't *have* to have access... you won't miss much! :) So, some thoughts on revising unAPI paths-vs-params: The argument from Ross and Alf for needing configuration flexibility (esp. in the case where http server rewrites are not an option) is compelling. So we should not *force* a fixed path pattern. Mike's argument for an OpenSearch-like introspect-on-url-patterns argument is compelling. It works for OpenSearch, and an introspection doc can indeed be hand-coded. I *personally* still like the idea of a standard path order, as the frameworks I use make this easy to implement and they make sense in the broader context of path patterns in my applications. All that said, I think we should follow Mike's suggestion of adopting an OpenSearch-like specify-the-patterns introspection solution. And, we should use the same param-substitution regex syntax that OpenSearch uses. Positives for this solution: - it addresses Ross's and Alf's concerns - OpenSearch did this successfully - the introspection doc can be hand-coded - it's easy to implement around the introspection pattern, especially if we're already asking people to introspect (which raises implementation barrier some, but not really that much) - our verb/param options are limited by design, so the patterns should stay simple - i still get to implement the pattern I want :P Negatives: - it doesn't specify a default. might be better to just say "do it this way!" - implementation barrier is raised a little, but not much, and not into a whole 'nother complexity level, as noted above - we're going to have to think hard about the introspection response format... but we knew that anyway! Since this solution addresses everybody's needs, and doesn't raise complexity *that* much, it seems like the best answer. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Wed Jan 25 13:08:06 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Jan 25 13:07:31 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <7928FD6E-F218-4120-BE54-65D57E9F5518@yale.edu> References: <7928FD6E-F218-4120-BE54-65D57E9F5518@yale.edu> Message-ID: <43D7BE86.4080607@library.gatech.edu> Would it not be possible to have an introspection document /and/ a default behavior? Like explain in the context of SRW/U, if you have an introspection document, the client can use it and possibly get "non-default" behavior (for example -- if we decide the default is path, not params, it can be determined here that only params are accepted). Clients wouldn't have to read or parse the document, but that could also restrict them from full access to the resource. -Ross. Daniel Chudnov wrote: > (Note: I've reordered the "Open questions for revision 1" basecamp > to-do list into easiest-to-hardest order. This topic covers the > first two items: > > #unAPI developers: Are GET params better than a fixed path? > #unAPI developers: Can the path order be made more consistent? > > ...fyi, we are using basecamp to manage the "paperwork" part of > developing this spec, and all participants are welcome to have access > to basecamp project. That said, there is nothing "hidden" in the > basecamp project site that will not be usefully communicated here. > So you don't *have* to have access... you won't miss much! :) > > > So, some thoughts on revising unAPI paths-vs-params: > > The argument from Ross and Alf for needing configuration flexibility > (esp. in the case where http server rewrites are not an option) is > compelling. So we should not *force* a fixed path pattern. > > Mike's argument for an OpenSearch-like introspect-on-url-patterns > argument is compelling. It works for OpenSearch, and an > introspection doc can indeed be hand-coded. > > I *personally* still like the idea of a standard path order, as the > frameworks I use make this easy to implement and they make sense in > the broader context of path patterns in my applications. > > > All that said, I think we should follow Mike's suggestion of adopting > an OpenSearch-like specify-the-patterns introspection solution. And, > we should use the same param-substitution regex syntax that > OpenSearch uses. > > Positives for this solution: > > - it addresses Ross's and Alf's concerns > - OpenSearch did this successfully > - the introspection doc can be hand-coded > - it's easy to implement around the introspection pattern, > especially if we're > already asking people to introspect (which raises implementation > barrier some, > but not really that much) > - our verb/param options are limited by design, so the patterns > should stay simple > - i still get to implement the pattern I want :P > > Negatives: > > - it doesn't specify a default. might be better to just say "do it > this way!" > - implementation barrier is raised a little, but not much, and not > into a whole > 'nother complexity level, as noted above > - we're going to have to think hard about the introspection > response format... > but we knew that anyway! > > > Since this solution addresses everybody's needs, and doesn't raise > complexity *that* much, it seems like the best answer. > > -Dan > > From azaroth at liverpool.ac.uk Wed Jan 25 13:13:54 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Jan 25 13:17:57 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <7928FD6E-F218-4120-BE54-65D57E9F5518@yale.edu> References: <7928FD6E-F218-4120-BE54-65D57E9F5518@yale.edu> Message-ID: <1138212834.30776.41.camel@helmsdeep> On Wed, 2006-01-25 at 12:30 -0500, Daniel Chudnov wrote: > So, some thoughts on revising unAPI paths-vs-params: > > The argument from Ross and Alf for needing configuration flexibility > (esp. in the case where http server rewrites are not an option) is > compelling. So we should not *force* a fixed path pattern. > > Mike's argument for an OpenSearch-like introspect-on-url-patterns > argument is compelling. It works for OpenSearch, and an > introspection doc can indeed be hand-coded. I don't like introspection, probably due to building Explain documents for Z39.50 and constantly explaining Why ZeeRex? for SRW. And I maintain ZeeRex, and wrote the spec for Z39.92... Here are my arguments against introspection in this case. 1. It's more work for no benefit. In order to interact you have to do the introspection. Requiring more backwards and forwardsing just to get access to one lousy document for cut/paste. Stay on Target Red Leader! What is wanted is a simple way to access digital objects from a web page that refers to them. We don't need 'flexibility', we need simple, we need standard. Make it easy for the server writer and trivial for the client. My counter to the counter-argument of 'people don't want to be told what to call their parameters': They even more don't want to be told how to describe their parameters! If someone whines about wanting to call it 'id' instead of 'identifier' or 'search' instead of 'go'... they'll whine about having to write up some crazy Explain document in a weird format they don't really understand. This isn't the same as OpenSearch, given my very incomplete understanding of it. There was a large body of completely non-standard ways to do things. Most importantly, there was a large number of implementations that could be brought together with very little work by the developers rather than by the end user. OpenSearch just quantified it a little. Here, if you buy unapi, then you'll buy the easy parameter names. If you don't buy the easy parameter names, you certainly won't buy having to hand build the introspection document. 2. It's a single point of failure. If your introspection document isn't exactly correct, no one will be able to use the server at all. If an SRW explain document isn't there, then people will simply try dc.title searches and other indexes until they get what they want. Yes, Explain is useful. No it's not absolutely essential because the syntax of the request is formalised. 3. What Ross Said :) Use introspection for non default behaviour. If you want to change the param names from the defaults, then fine, but you have to explain what you're doing. If you're sticking to the defaults, then no introspection document, no problem. Then you have two classes of client, just like in SRW. Those that can understand Explain and those that blindly search dc.title. Those that can understand unapiIntrospectionFormat and those that fail on non default servers. Rob -- Dr Robert Sanderson Dept of Computer Science, University of Liverpool Home: http://www.csc.liv.ac.uk/~azaroth/ Cheshire: http://www.cheshire3.org/ From Peter.Binkley at ualberta.ca Wed Jan 25 13:38:47 2006 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Wed Jan 25 13:46:19 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params Message-ID: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> I follow Rob's line of argument, and jump off at the point where we allow overrides and explains. What is the gain? Given that we want unapi to be really really simple, and we want it to be implemented in the blogosphere (so it has to really really easy to implement Wordpress plugins etc. that can run in a simple php environment), I don't see that the added complexity gets us anything valuable enough to justify its inclusion. Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Rob Sanderson > Sent: Wednesday, January 25, 2006 11:14 AM > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] suggested revision: paths vs. params > > On Wed, 2006-01-25 at 12:30 -0500, Daniel Chudnov wrote: > > > So, some thoughts on revising unAPI paths-vs-params: > > > > The argument from Ross and Alf for needing configuration > flexibility > > (esp. in the case where http server rewrites are not an option) is > > compelling. So we should not *force* a fixed path pattern. > > > > Mike's argument for an OpenSearch-like introspect-on-url-patterns > > argument is compelling. It works for OpenSearch, and an > introspection > > doc can indeed be hand-coded. > > I don't like introspection, probably due to building Explain > documents for Z39.50 and constantly explaining Why ZeeRex? > for SRW. And I maintain ZeeRex, and wrote the spec for Z39.92... > > Here are my arguments against introspection in this case. > > 1. It's more work for no benefit. > > In order to interact you have to do the introspection. > Requiring more backwards and forwardsing just to get access > to one lousy document for cut/paste. > > Stay on Target Red Leader! What is wanted is a simple way to > access digital objects from a web page that refers to them. > We don't need 'flexibility', we need simple, we need > standard. Make it easy for the server writer and trivial for > the client. > > My counter to the counter-argument of 'people don't want to > be told what to call their parameters': They even more don't > want to be told how to describe their parameters! If someone > whines about wanting to call it 'id' instead of 'identifier' > or 'search' instead of 'go'... they'll whine about having to > write up some crazy Explain document in a weird format they > don't really understand. > > This isn't the same as OpenSearch, given my very incomplete > understanding of it. There was a large body of completely > non-standard ways to do things. Most importantly, there was a > large number of implementations that could be brought > together with very little work by the developers rather than > by the end user. > > OpenSearch just quantified it a little. > Here, if you buy unapi, then you'll buy the easy parameter > names. If you don't buy the easy parameter names, you > certainly won't buy having to hand build the introspection document. > > > 2. It's a single point of failure. > > If your introspection document isn't exactly correct, no one > will be able to use the server at all. > If an SRW explain document isn't there, then people will > simply try dc.title searches and other indexes until they get > what they want. > Yes, Explain is useful. No it's not absolutely essential > because the syntax of the request is formalised. > > > 3. What Ross Said :) > > Use introspection for non default behaviour. If you want to > change the param names from the defaults, then fine, but you > have to explain what you're doing. If you're sticking to the > defaults, then no introspection document, no problem. > > Then you have two classes of client, just like in SRW. Those > that can understand Explain and those that blindly search > dc.title. Those that can understand unapiIntrospectionFormat > and those that fail on non default servers. > > > Rob > > -- > Dr Robert Sanderson > Dept of Computer Science, University of Liverpool > Home: http://www.csc.liv.ac.uk/~azaroth/ > Cheshire: http://www.cheshire3.org/ > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From ross.singer at library.gatech.edu Wed Jan 25 14:21:20 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Wed Jan 25 14:25:03 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> Message-ID: <43D7CFB0.1090003@library.gatech.edu> Binkley, Peter wrote: >I follow Rob's line of argument, and jump off at the point where we >allow overrides and explains. What is the gain? Given that we want unapi >to be really really simple, and we want it to be implemented in the >blogosphere (so it has to really really easy to implement Wordpress >plugins etc. that can run in a simple php environment), I don't see that >the added complexity gets us anything valuable enough to justify its >inclusion. > > +1 -Ross. From daniel.chudnov at yale.edu Wed Jan 25 18:03:39 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Jan 25 18:03:39 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> Message-ID: <20060125230338.GF29143@sildin.med.yale.edu> Binkley, Peter wrote, on Wed, Jan 25, 2006 at 11:38:47AM -0700: > I follow Rob's line of argument, and jump off at the point where we > allow overrides and explains. What is the gain? Given that we want unapi > to be really really simple, and we want it to be implemented in the > blogosphere (so it has to really really easy to implement Wordpress > plugins etc. that can run in a simple php environment), I don't see that > the added complexity gets us anything valuable enough to justify its > inclusion. Okay, so, that's three voices for no url pattern introspection required. :) Whether or not unAPI does introspection at all is a separate issue; it is explicitly about introspection w/r/to formats available, and (possibly) w/r/to other services, if we decide to do that (which is a decision further down on the to-do list). That said, you're right, simple is better, and simple is the goal. So, here's a new revised plan: unAPI requires a single base URL that responds to queries with verbs, identifiers, and format names specified as URL param key/value pairs. And let's just drop being-able-to-specify-other-URL-patterns off the table completely for now. If it comes back during the formats/services list part of the discussion (part of which comes up next), we can reexamine. How's that? I'll wait a 36-hour news/email cycle and, upon hearing no -1s, will note changes in the revision 1 writeboard in basecamp. If you haven't weight in yet, please send a +1/0/-1. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Wed Jan 25 21:45:33 2006 From: ehs at pobox.com (Edward Summers) Date: Wed Jan 25 21:46:08 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <20060125230338.GF29143@sildin.med.yale.edu> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> <20060125230338.GF29143@sildin.med.yale.edu> Message-ID: On Jan 25, 2006, at 5:03 PM, Daniel Chudnov wrote: > And let's just drop being-able-to-specify-other-URL-patterns off > the table > completely for now. If it comes back during the formats/services list > part of the discussion (part of which comes up next), we can > reexamine. > > How's that? +1 I like the name/value pair approach since it is familiar to most web developers--and it mirrors the simplicity of oai-pmh. //Ed From mrylander at gmail.com Wed Jan 25 22:38:31 2006 From: mrylander at gmail.com (Mike Rylander) Date: Wed Jan 25 22:39:35 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <20060125230338.GF29143@sildin.med.yale.edu> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> <20060125230338.GF29143@sildin.med.yale.edu> Message-ID: On 1/25/06, Daniel Chudnov wrote: [snip] > So, here's a new revised plan: unAPI requires a single base URL that > responds to queries with verbs, identifiers, and format names specified > as URL param key/value pairs. > > And let's just drop being-able-to-specify-other-URL-patterns off the table > completely for now. If it comes back during the formats/services list > part of the discussion (part of which comes up next), we can reexamine. > > How's that? Provisionally -1, but I will abstain in the face of all yeas. :) -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From pp at myelin.co.nz Wed Jan 25 22:45:23 2006 From: pp at myelin.co.nz (Phillip Pearson) Date: Wed Jan 25 22:45:54 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> Message-ID: <43D845D3.9000008@myelin.co.nz> Binkley, Peter wrote: >I follow Rob's line of argument, and jump off at the point where we >allow overrides and explains. What is the gain? Given that we want unapi >to be really really simple, and we want it to be implemented in the >blogosphere (so it has to really really easy to implement Wordpress >plugins etc. that can run in a simple php environment), I don't see that >the added complexity gets us anything valuable enough to justify its >inclusion. > If you want it to be implemented in the blogosphere, it's got to be *really* simple. Even unAPI revision 0 is way more complicated than it could be. It seems that currently you have to have: info:foobar/some-identifier which gets looked up by calling an API function off a URL specified in the header: i.e. the above URI would be looked up by retrieving: http://foobar.com/unapi/formats/info:foobar/some-identifier In that case, why not drop the and change the to an tag: human-readable version of info:foobar/some-identifier ? That makes it linkable and usable by people without any unapi-specific software installed (as long as UNAPI/formats/URI is specified to return HTML). Then the unapi software can look for tags with class="unapi" (or perhaps it should be rel="unapi", or rel="alternative" type="application/x-unapi"), rip the URI out of the link by splitting on /formats/, and make other calls. Cheers, Phil From lists at hubmed.org Thu Jan 26 08:29:27 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Jan 26 08:32:42 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <20060125230338.GF29143@sildin.med.yale.edu> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> <20060125230338.GF29143@sildin.med.yale.edu> Message-ID: On 25 Jan 2006, at 18:03, Daniel Chudnov wrote: > Binkley, Peter wrote, on Wed, Jan 25, 2006 at 11:38:47AM -0700: >> I follow Rob's line of argument, and jump off at the point where we >> allow overrides and explains. What is the gain? Given that we want >> unapi >> to be really really simple, and we want it to be implemented in the >> blogosphere (so it has to really really easy to implement Wordpress >> plugins etc. that can run in a simple php environment), I don't >> see that >> the added complexity gets us anything valuable enough to justify its >> inclusion. > > Okay, so, that's three voices for no url pattern introspection > required. :) > > Whether or not unAPI does introspection at all is a separate issue; > it is explicitly about introspection w/r/to formats available, and > (possibly) w/r/to other services, if we decide to do that (which is > a decision further down on the to-do list). +1 for both points. alf. From lists at hubmed.org Thu Jan 26 08:30:11 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Jan 26 08:33:22 2006 Subject: [gcs-pcs-list] suggested revision: paths vs. params In-Reply-To: <43D845D3.9000008@myelin.co.nz> References: <908893006339C0409519E4065DF3B24901570F9F@mailserver.ualibrary.ualberta.ca> <43D845D3.9000008@myelin.co.nz> Message-ID: <00A60148-0275-4CD7-B74B-3B13AB0468A4@hubmed.org> On 25 Jan 2006, at 22:45, Phillip Pearson wrote: > > In that case, why not drop the and change the to an > tag: > > human-readable version of info:foobar/ > some-identifier > > ? > > That makes it linkable and usable by people without any unapi- > specific software installed (as long as UNAPI/formats/URI is > specified to return HTML). Then the unapi software can look for > tags with class="unapi" (or perhaps it should be rel="unapi", > or rel="alternative" type="application/x-unapi"), rip the URI out > of the link by splitting on /formats/, and make other calls. I guess that makes sense, but the nice thing about class="uri" with a uri in the title (or href, if it's an invisible anchor) is that it can be used for other purposes that bypass unAPI completely. alf.