From daniel.chudnov at yale.edu Wed Feb 1 21:42:05 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 1 21:43:05 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 6:03 PM, Daniel Chudnov wrote: > > 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. > ... > > I'll wait a 36-hour news/email cycle and, upon hearing no -1s, will > note changes in the revision 1 writeboard in basecamp. I'm sorry the 36-hour cycle turned into a week. Back at it. I've made the slight changes to the writeboard spec reflect this change. A snapshot of the most recent revision is available here: http://curtis.med.yale.edu/dchud/unapi/ The formatting and layout of the spec itself are not ideal. At some point before releasing revision 1 we should make it look better. Next issue to resolve to follow anon. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Feb 1 22:31:32 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 1 22:32:37 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: <5B3A4CE3-346C-4B73-B8AF-756D08FC6926@yale.edu> Welcome Phillip! On Jan 25, 2006, at 10:45 PM, Phillip Pearson wrote: > > 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. We know. It was first draft intended to be revised. :) > 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. Good question. Alf's response, "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," is also a good point. Those of us coming from an OpenURL/COinS background (certainly my background, at least) are probably influenced heavily by years of struggling to wire together webapps long before it became a popular or easy thing to do, and, because of this experience, wanting to end up with something fairly service-neutral in between. It's hard to know whether more apps would want to link in through UNAPI to formats/ services or out through OpenURL resolvers or similar mechanisms, so I can't see an objectively obvious answer to the question of which direction we should optimize for. Though the microformats approach has warped my mind toward wanting to optimize for simplicity and visibility... Anyway, it's a good question, so I've added it to the list of open issues on our to-do list for revision 1. It'll come up after the next issue I raise. I hope you don't mind me sorting it down slightly... I'm hoping it'll be easier for us to discuss this issue after we've gotten down the list a little further. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Feb 1 23:19:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 1 23:20:40 2006 Subject: [gcs-pcs-list] issue summary: verbs: search? services? Message-ID: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> The next three issues on the to-do list are closely related: - Should we add a UNAPI/search function that works like UNAPI/go but for searching? - Should we add a UNAPI/services function that lists available services (as UNAPI/formats lists formats)? - What *exactly* are the core, required verbs? Please note that these do not also contain "what is the response format" - that is the issue following these. It should be easier to answer once we've gotten through this. The current unAPI revision 1 implies three specific verbs: - "go": Go immediately to the application?s standard HTML dissemination of this URI - "formats": List the metadata and object formats available, either for objects on the site in general, or for an optionally specified URI - "fetch": Returns the specified object in the specified format About these verbs, and the spec in general w/r/to these issues: Steve said: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000294.html "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." I wrote about go vs. fetch: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000309.html "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." Alf replied: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000311.html "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." I replied to Alf at length: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000313.html If I'm not mistaken, we generally agreed about the value of this distinction soon thereafter in #code4lib. I *think* this is corroborated by Alf's comment: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000310.html "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." Rob argued that go and fetch are still technically the same thing: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000317.html "Overall, I think once you tidy up the definitions, you'll find that go and fetch can be rolled into one." Alf's revision 0b included: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000300.html "Got rid of the */formats verb. The default response would be in the default format and would contain links to the other available formats." ...and also: "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." ...and: "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." Rob suggested a substantial reduction: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-January/ 000301.html ...which he and Alf debated over several follow-ups. I think that summarizes the bulk of the debate so far, if not every word or nuance. :) I think we can further slice it logically this way: - Are "go" and "fetch" really different? I *think* most of us agree that they are, but it would be good to close on this. - Should we include, in the "base" unAPI "introspection" document for the whole site, a list of non-unAPI services available? - If yes, should "formats" instead be "services", which would in turn include *all* links to *every* unAPI-specified verb/format possibility for a given URI, a list of generally available formats for the whole site, and a list of other API baseurls (e.g. OpenSearch/ SRU, Atom/RSS/etc., what-have-you)? Or should "services" be a different (fourth) verb? Should "search" be a fourth or fifth verb? Hmm... maybe it wasn't a good idea to combine these issues, but I can't untangle them completely in my brain. I'll start two threads to discuss with proposed revisions. -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Wed Feb 1 23:34:45 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Feb 1 23:38:02 2006 Subject: [gcs-pcs-list] issue summary: verbs: search? services? In-Reply-To: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> References: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> Message-ID: On 01 Feb 2006, at 23:19, Daniel Chudnov wrote: > - Are "go" and "fetch" really different? I *think* most of us > agree that they are, but it would be good to close on this. > > - Should we include, in the "base" unAPI "introspection" document > for the whole site, a list of non-unAPI services available? To simplify things even further, you could say that neither pointing to a web browser/human-readable version of an object nor linking to other local search/publishing services need to be part of a 'universal object copying function', so you could just ignore them for now and concentrate on the core functions: describing available formats & verbs and retrieving objects? alf. From daniel.chudnov at yale.edu Wed Feb 1 23:38:37 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 1 23:39:42 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different Message-ID: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> I stand by the original claim that "go" and "fetch" do different things. Rob's technical analysis is correct in a technical way, but I think there's an important and convenient human/usability distinction. Adding the "fetch" verb to the spec (Rob's suggestion, I believe) helps to clarify this distinction. Can we close on whether these are usefully kept separate? And, if so, a few more lines explaining why? Here's one approach. "go": Go immediately to the application?s HTML "default page" of this URI, intended for human consumption. This might include a site header and footer (for anything); a table of contents and simple metadata (for a book); a list of alternate formats available (for a journal article); a pageturner (for a book); a thumbnail and links to other image formats and sizes (for an image); a screenshot and list of streaming formats (for a video); a track list, album art, links to lyrics, and buy-it-now store links (for music). It is a "human start page" for an object as generally represented by a web application. It also helps to short-circuit having to track diverse and changing url linking patterns for content-heavy sites like academic journal publishers. "fetch": Return only a specific object in a specific format. This would never include a webapp's site header or footer (for anything); it might return a full pdf (for a book or journal article), a bare image file (for an image), a bare video stream (for a movie) or mp3 file (for music). It is only a specific file type with a specific well-known format, unadorned by a webapp's human-intended friendly surrounding stuff. It could happen that "fetch" retrieves a "wrapped" object, such as an MPEG21 or METS item, which comprises alternate metadata structures and representation formats, but even in that case, the "fetch" command only returns the wrapped object in the wrapper format. I can go on and on and on about this (obviously) but spent too much time thinking about the OAIS reference model to back down easily. :) Do you agree with this distinction? If so, is there an easy way to explain it without telling people to read OAIS or sending me off ranting? Enough for tonight... -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Feb 1 23:46:10 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 1 23:47:14 2006 Subject: [gcs-pcs-list] issue summary: verbs: search? services? In-Reply-To: References: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> Message-ID: On Feb 1, 2006, at 11:34 PM, Alf Eaton wrote: > To simplify things even further, you could say that neither > pointing to a web browser/human-readable version of an object nor > linking to other local search/publishing services need to be part > of a 'universal object copying function', so you could just ignore > them for now and concentrate on the core functions: describing > available formats & verbs and retrieving objects? Excellent point. I'll admit I'm selfishly tied to "go" as a useful convenience. The primary argument I can reasonably claim for keeping it in is that if we lived in a world where many apps supported copying out, and some apps supported pasting in, at some point you might want to start at the pasting apps' copies you made and go *back* to the original app you copied out from. At that moment, having a "go" function would be useful for returning to a human base page for the object, especially if the object or its available representations-by-format have changed at all in the originating/source app. I'm too tired to tell whether that's a stretch or not. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Thu Feb 2 05:46:58 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Feb 2 05:50:11 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> Message-ID: >I think there's an important and convenient human/usability >distinction. Here's where I think the distinction should be made, and I'm going to rename the verbs to emphasize it... display: Present a human oriented, [X]HTML interface that allows the object to be displayed. Does not necessarily have return the complete object (for example, a table of contents for a book) Footprint: display(identifier) fetch: Retrieve the complete object without any human oriented presentation functionality. May include machine parsable wrapping (eg METS). Footprint: fetch(identifier, ?format) If format is not supplied, the server provides a default format. Yes? Rob From azaroth at liverpool.ac.uk Thu Feb 2 06:17:22 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Feb 2 06:20:37 2006 Subject: [gcs-pcs-list] issue summary: verbs: search? services? In-Reply-To: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> References: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> Message-ID: >- Should we add a UNAPI/search function that works like UNAPI/go but >for searching? No. As soon as you get into searching, you're on the slippery slope of re-inventing SRU. OAI teeters on the edge with its undefined 'set' functionality, which has caused many many discussions. Don't go there :) >- Should we add a UNAPI/services function that lists available >services (as UNAPI/formats lists formats)? No. Here's why: All that you can describe about an extended service is the boolean value 'do I support this service' without getting into very complicated WSDL like stuff. And even that can only describe the syntax, not the semantics. So somewhere you still need a human oriented description of what the extended service does. So unless you foresee a registry of extensions and multiple implementations of them, it seems worthless compared to an implementation oriented web page. My assumption is that the formats list will be of reasonably standard types, as opposed to operations which are likely to be very implementation dependant. Rob From mrylander at gmail.com Thu Feb 2 08:09:57 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Feb 2 08:11:02 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> Message-ID: On 2/2/06, Robert Sanderson wrote: > > >I think there's an important and convenient human/usability > >distinction. > > Here's where I think the distinction should be made, and I'm going to > rename the verbs to emphasize it... > > display: Present a human oriented, [X]HTML interface that allows the > object to be displayed. Does not necessarily have return the > complete object (for example, a table of contents for a book) I think it's important that we not let this verb not get lax about the technical equivalence to fetch(id, displayable_format). It should return as much information as is practicable and displayable via [X]HTML. For instance, if target object is a bibliographic record, it should return the entire displayable portion of that record, not just part of it. If that target is an online book in PDF format, it should include whatever meta data surrounds the PDF /and/ a direct link to the PDF. Ideally, a data url containing the PDF would be included, but that might be going a little overboard. ;-) I think the proponents of the distinction (Dan, Alf, correct me if I've misinterpreted you), of which I'm one, see this as a shortcut to the human usable interface to and of the target object. It's the only required unAPI format, and it's a full-fledged format option that requires as much of the target object be embedded as the physical format ([X]HTML) allows (and that common user agents can use). > > Footprint: display(identifier) > > fetch: Retrieve the complete object without any human oriented > presentation functionality. May include machine parsable > wrapping (eg METS). > > Footprint: fetch(identifier, ?format) > > If format is not supplied, the server provides a default format. > > > Yes? > > Rob > _______________________________________________ > 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 azaroth at liverpool.ac.uk Thu Feb 2 08:20:24 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Thu Feb 2 08:23:36 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> Message-ID: >I think it's important that we not let this verb not get lax about the >technical equivalence to fetch(id, displayable_format). If there's a technical equivalence, then it should be a single verb. There's no point having aliases when the inclusion of the alias just means extra work for the implementer. Secondly, if they're portrayed as separate operations with duplicate functionality, you'll end up with: A) Everyone asking the same questions that we've asked B) People just implementing fetch(id, ?fmt) anyway if go(id) is the same as fetch(id), why complicate the protocol and the documentation trying to explain why it was deemed to be necessary to have both? As Alf suggested, go() isn't necessary *at all* in a copy/paste protocol. Don't let the feeping creatures in! Rob From ross.singer at library.gatech.edu Thu Feb 2 10:07:11 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Feb 2 10:05:49 2006 Subject: [gcs-pcs-list] issue summary: verbs: search? services? In-Reply-To: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> References: <6B21785C-419C-437B-A313-F2846855130A@yale.edu> Message-ID: <43E2201F.2020306@library.gatech.edu> Daniel Chudnov wrote: > The next three issues on the to-do list are closely related: > > - Should we add a UNAPI/search function that works like UNAPI/go but > for searching? To this, I think "no". I think it begins to miss the scope (unless I miss the scope). I had thought the purpose of unAPI was to be able to get /what you're looking at/. To search would specifically be /what you're not looking at/. I think you get into nasty search semantics quagmires and a level of complexity that will bog us down. -Ross. From ross.singer at library.gatech.edu Thu Feb 2 10:20:50 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Feb 2 10:19:29 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> Message-ID: <43E22352.2010701@library.gatech.edu> Daniel Chudnov wrote: > "go": Go immediately to the application?s HTML "default page" of > this URI, intended for human consumption. This assumes HTML is the "default" -- isn't it possible that the "default" would be PDF, TIFF, SVG, who knows what? -Ross. From daniel.chudnov at yale.edu Thu Feb 2 13:16:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 2 13:16:49 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" Message-ID: <20060202181647.GD7497@sildin.med.yale.edu> So far a handful of folks have stated a strong dislike of adding verbs for "search" or "services". As there's a to-do item for each, I'll call for a quick vote on each... ideally we can hear from 3-7 more people just to be sure there's enough of a consensus. Please vote +1/0/-1 for each of the following and I'll knock off the to-dos if we get past +5. Note that +1 == "agree, don't add it". If you disagree, vote -1, and explain why. :) - No, we will not add a "search" verb. - No, we will not add a "services" verb. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Thu Feb 2 13:22:48 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu Feb 2 13:21:26 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: <20060202181647.GD7497@sildin.med.yale.edu> References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: <43E24DF8.6050409@library.gatech.edu> Daniel Chudnov wrote: >- No, we will not add a "search" verb. > > +1 > >- No, we will not add a "services" verb. > > +1 -Ross. From mrylander at gmail.com Thu Feb 2 14:45:48 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Feb 2 14:47:00 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: <20060202181647.GD7497@sildin.med.yale.edu> References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: On 2/2/06, Daniel Chudnov wrote: > So far a handful of folks have stated a strong dislike of adding verbs for > "search" or "services". As there's a to-do item for each, I'll call for > a quick vote on each... ideally we can hear from 3-7 more people just > to be sure there's enough of a consensus. Please vote +1/0/-1 for each > of the following and I'll knock off the to-dos if we get past +5. > > Note that +1 == "agree, don't add it". If you disagree, vote -1, and > explain why. :) > > > - No, we will not add a "search" verb. > +1 > > - No, we will not add a "services" verb. > > -1 I see no reason to limit extensiblitiy, and the "services" response can be a static file provided as a reference implementation that lists the core services of the spec. > > > Thanks, -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 daniel.chudnov at yale.edu Thu Feb 2 15:10:59 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 2 15:11:01 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: <20060202201058.GH7497@sildin.med.yale.edu> Mike Rylander wrote, on Thu, Feb 02, 2006 at 07:45:48PM +0000: > > > > - No, we will not add a "services" verb. > > > -1 I see no reason to limit extensiblitiy, and the "services" > response can be a static file provided as a reference implementation > that lists the core services of the spec. At present, the specification says nothing about extensibility, and it isn't captured as an issue for the revision one to-do list. Aside from per-site supported formats being arbitrary, there is no explicit concept of extension built-in. So what does "extensibility" mean to you? How would it help a spec intended "for the most basic operations necessary to perform simple clipboard-copy functions"? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Feb 2 16:45:40 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Feb 2 16:49:00 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: <20060202181647.GD7497@sildin.med.yale.edu> References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: On 02 Feb 2006, at 13:16, Daniel Chudnov wrote: > > - No, we will not add a "search" verb. +1 > - No, we will not add a "services" verb. +1, but only because I think the services description (ie a description of the available verbs) could be in the base information document (for want of a better name) along with the available formats: for example. alf. From mrylander at gmail.com Thu Feb 2 23:55:22 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Feb 2 23:56:28 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: <20060202201058.GH7497@sildin.med.yale.edu> References: <20060202181647.GD7497@sildin.med.yale.edu> <20060202201058.GH7497@sildin.med.yale.edu> Message-ID: On 2/2/06, Daniel Chudnov wrote: > Mike Rylander wrote, on Thu, Feb 02, 2006 at 07:45:48PM +0000: > > > > > > - No, we will not add a "services" verb. > > > > > -1 I see no reason to limit extensiblitiy, and the "services" > > response can be a static file provided as a reference implementation > > that lists the core services of the spec. > > At present, the specification says nothing about extensibility, and it > isn't captured as an issue for the revision one to-do list. Aside from > per-site supported formats being arbitrary, there is no explicit concept > of extension built-in. No, but the door is opened by the possibility of a "service description document" that was floated before, and that Alf mocked up down-thread. One argument against this would be that the verbosity of a description document feels very redundant in light of a simple spec, but I don't think verbosity == redundancy where it opens doors for future extension by those other than the original spec authors. > > So what does "extensibility" mean to you? How would it help a spec > intended "for the most basic operations necessary to perform simple > clipboard-copy functions"? > It doesn't mean anything as of yet, I just don't like the idea of disallowing extensions. I'm imaging something along the lines of a set of services that are defined by the RETRIEVE unapi module (ie, what we're working through now -- go, fetch, resolve, ...) and then allowing or creating extension modules that /are/ future versions of the spec. Extension modules would define the eventual PASTE verb set, and maybe a LINK set that would allow "ln -s" to RETRIEVE's "cp" (think: requesting a permalink for an object instead of the object itself). However, if a base service description document is approved and is made to resolve and specify site supported verbs then I'm forcefully +1 on this. :) > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From stoub at yahoo.com Fri Feb 3 00:32:41 2006 From: stoub at yahoo.com (Steve Toub) Date: Fri Feb 3 00:33:55 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: <43E2EAF9.1050409@yahoo.com> On 02 Feb 2006, at 13:16, Daniel Chudnov wrote: > - No, we will not add a "search" verb. +1 >> - No, we will not add a "services" verb. +1 for now, knowing we'll need to circle back (at some point) to the concept of a "base document" as Alf and Mike suggest --SET From daniel.chudnov at yale.edu Fri Feb 3 07:32:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 3 07:33:56 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: <43E2EAF9.1050409@yahoo.com> References: <20060202181647.GD7497@sildin.med.yale.edu> <43E2EAF9.1050409@yahoo.com> Message-ID: <3013643E-37F8-4106-88F5-E67129152B97@yale.edu> On Feb 3, 2006, at 12:32 AM, Steve Toub wrote: >> - No, we will not add a "search" verb. > > +1 This brings us over +5 with no dissents. Issue closed. Spec unchanged save for removal of the equivalently noted issue at the bottom being removed. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Feb 3 08:11:17 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 3 08:12:18 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> <20060202201058.GH7497@sildin.med.yale.edu> Message-ID: On Feb 2, 2006, at 11:55 PM, Mike Rylander wrote: > > However, if a base service description document is approved and is > made to resolve and specify site supported verbs then I'm forcefully > +1 on this. :) Fair enough. I've added "Should we require a "base document", and if so, what must it specify?" to the to-do list after we close on "do we need a services verb" and "what are the required verbs". So, back to those... can we close on "do we need a services verb"? If we can, then we can talk about the base document sooner. :) (Btw, something to remember here is that we don't have to get everything "right" by revision 1, due Feb. 16. We just need to make it better, and track where we've been, so we can revisit decisions etc. At this still-early stage can easily put something off for the next revision; imho the key is to keep moving forward small change by small change toward something better and easily implemented all along.) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Fri Feb 3 08:33:36 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Feb 3 08:34:40 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> <20060202201058.GH7497@sildin.med.yale.edu> Message-ID: On 2/3/06, Daniel Chudnov wrote: > On Feb 2, 2006, at 11:55 PM, Mike Rylander wrote: > > > > However, if a base service description document is approved and is > > made to resolve and specify site supported verbs then I'm forcefully > > +1 on this. :) > > Fair enough. > > I've added "Should we require a "base document", and if so, what must > it specify?" to the to-do list after we close on "do we need a > services verb" and "what are the required verbs". > > So, back to those... can we close on "do we need a services verb"? > If we can, then we can talk about the base document sooner. :) It looks like there are no (technical) dissents with your addition. Sounds closed to me! :) -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From daniel.chudnov at yale.edu Fri Feb 3 11:22:56 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 3 11:22:59 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> <20060202201058.GH7497@sildin.med.yale.edu> Message-ID: <20060203162256.GD31769@sildin.med.yale.edu> Mike Rylander wrote, on Fri, Feb 03, 2006 at 01:33:36PM +0000: > On 2/3/06, Daniel Chudnov wrote: > > So, back to those... can we close on "do we need a services verb"? > > If we can, then we can talk about the base document sooner. :) > > It looks like there are no (technical) dissents with your addition. > Sounds closed to me! :) Done. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Feb 3 11:53:55 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 3 11:53:57 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> Message-ID: <20060203165355.GF31769@sildin.med.yale.edu> Back to this thread, as "What *exactly* are the core, required verbs?" is now the to-do item on the table. Mike Rylander wrote, on Thu, Feb 02, 2006 at 01:09:57PM +0000: > On 2/2/06, Robert Sanderson wrote: > > > > >I think there's an important and convenient human/usability > > >distinction. > > I think it's important that we not let this verb not get lax about the > technical equivalence to fetch(id, displayable_format). It should > return as much information as is practicable and displayable via > [X]HTML. For instance, if target object is a bibliographic record, it > should return the entire displayable portion of that record, not just > part of it. If that target is an online book in PDF format, it should > include whatever meta data surrounds the PDF /and/ a direct link to > the PDF. Ideally, a data url containing the PDF would be included, > but that might be going a little overboard. ;-) I think we're misunderstanding each other. My hope for the verb "go" was to *not* ask webapp developers to change anything about how they display content now (aside from whatever we ask with a unAPI microfauxmat). "go" would just "take us to your existing view of this item". Like, for a weblog entry with, say, uri tag:news.canarydatabase.org,2005:/entry/7, the unAPI function: http://news.canarydatabase.org/unapi/? verb=go& uri=tag:news.canarydatabase.org,2005:/entry/7 ...would simply redirect immediately to: http://news.canarydatabase.org/archives/7 Ideally the weblog would include whatever unapi/autodiscovery links/microfauxmat data in that entry page, then. It seems likely that asking webapp developers to change their app behavior any more than this is a non-starter. > I think the proponents of the distinction (Dan, Alf, correct me if > I've misinterpreted you), of which I'm one, see this as a shortcut to > the human usable interface to and of the target object. It's the only > required unAPI format, and it's a full-fledged format option that > requires as much of the target object be embedded as the physical > format ([X]HTML) allows (and that common user agents can use). It's a subtle point, whether "go" implies a "format" or not. I can see it both ways, sure. Your point here, plus Ross's that a webapp's native default human display for a URI might not be HTML, is well-taken. One more distinction worth raising here: the "fetch w/format" function is something the user specifies... "gimme this object in this format". The "go" redirection function instead allows the webapp to decide: "take me to your home page for this object." Which completes the cycle... "oh, so that's what this object is, eh? now, gimme it in this format." Very convenient, and a closed loop back to where you first got an object from wherever it might have ended up. That said, since this is just the first revision, I could live with Alf's suggestion that this is arguably outside of the strict scope. Which means I'll +1 keeping a "go" verb, removing the explicit mention of "HTML" as expected response format, unless everybody else wants to -1 it, which I'd go along with for now so we can move along down the list. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri Feb 3 12:21:29 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Feb 3 12:24:50 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060203165355.GF31769@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: On 03 Feb 2006, at 11:53, Daniel Chudnov wrote: > >> I think the proponents of the distinction (Dan, Alf, correct me if >> I've misinterpreted you), of which I'm one, see this as a shortcut to >> the human usable interface to and of the target object. It's the >> only >> required unAPI format, and it's a full-fledged format option that >> requires as much of the target object be embedded as the physical >> format ([X]HTML) allows (and that common user agents can use). > > It's a subtle point, whether "go" implies a "format" or not. I can > see > it both ways, sure. Your point here, plus Ross's that a webapp's > native > default human display for a URI might not be HTML, is well-taken. > > One more distinction worth raising here: the "fetch w/format" > function > is something the user specifies... "gimme this object in this format". > The "go" redirection function instead allows the webapp to decide: > "take > me to your home page for this object." Which completes the > cycle... "oh, > so that's what this object is, eh? now, gimme it in this format." > Very convenient, and a closed loop back to where you first got an > object > from wherever it might have ended up. The use case being, presumably: you see a post on someone else's page, copy it to your blog using unAPI to retrieve the text and the associated metadata then, pretending for this example that the object is not given a dereferenceable http:// URI, use the 'go' link to provide a link from your copied version of the post back to the original source. > That said, since this is just the first revision, I could live with > Alf's suggestion that this is arguably outside of the strict scope. > Which means I'll +1 keeping a "go" verb, removing the explicit > mention of > "HTML" as expected response format, unless everybody else wants to > -1 it, > which I'd go along with for now so we can move along down the list. I'm still not sure the term 'go' is very self-explanatory... anyway: 0 to postpone it until after the copying function (formats and services) is decided. alf. From azaroth at liverpool.ac.uk Fri Feb 3 13:38:10 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Fri Feb 3 13:43:17 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060203165355.GF31769@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: <1138991890.21343.108.camel@helmsdeep> On Fri, 2006-02-03 at 11:53 -0500, Daniel Chudnov wrote: > Back to this thread, as "What *exactly* are the core, required verbs?" > is now the to-do item on the table. > I think we're misunderstanding each other. My hope for the verb "go" was > to *not* ask webapp developers to change anything about how they display > content now (aside from whatever we ask with a unAPI microfauxmat). > "go" would just "take us to your existing view of this item". > Your point here, plus Ross's that a webapp's native > default human display for a URI might not be HTML, is well-taken. > That said, since this is just the first revision, I could live with > Alf's suggestion that this is arguably outside of the strict scope. > Which means I'll +1 keeping a "go" verb, removing the explicit mention of > "HTML" as expected response format, unless everybody else wants to -1 it, > which I'd go along with for now so we can move along down the list. -1 fetch(document) can be the redirect fetch(document, format) can be the formatted fetch. There's still no difference in functionality between a fetch with no specified format and go. if go(identifier) can return a PDF, then it's identical to fetch(identifier, pdf). The only difference is that the server gets to choose the representation not the client. No need to multiply verbs unnecessarily. 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 lists at hubmed.org Fri Feb 3 14:20:00 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Feb 3 14:20:13 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <1138991890.21343.108.camel@helmsdeep> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <1138991890.21343.108.camel@helmsdeep> Message-ID: On 03 Feb 2006, at 13:38, Rob Sanderson wrote: > On Fri, 2006-02-03 at 11:53 -0500, Daniel Chudnov wrote: >> Back to this thread, as "What *exactly* are the core, required >> verbs?" >> is now the to-do item on the table. > >> I think we're misunderstanding each other. My hope for the verb >> "go" was >> to *not* ask webapp developers to change anything about how they >> display >> content now (aside from whatever we ask with a unAPI microfauxmat). >> "go" would just "take us to your existing view of this item". > >> Your point here, plus Ross's that a webapp's native >> default human display for a URI might not be HTML, is well-taken. > >> That said, since this is just the first revision, I could live with >> Alf's suggestion that this is arguably outside of the strict scope. >> Which means I'll +1 keeping a "go" verb, removing the explicit >> mention of >> "HTML" as expected response format, unless everybody else wants to >> -1 it, >> which I'd go along with for now so we can move along down the list. > > -1 > > fetch(document) can be the redirect Not sure about that: I would have thought fetch(object) would return the object in its native format (ie MP3 for an MP3 file, PDF for a PDF file, etc). There might also need to be room for fetch(object) to look at Accept headers and decide which format to send that way, though that hasn't been voted on yet. > fetch(document, format) can be the formatted fetch. > > There's still no difference in functionality between a fetch with no > specified format and go. > > if go(identifier) can return a PDF, then it's identical to > fetch(identifier, pdf). The only difference is that the server > gets to > choose the representation not the client. I think the point is that go(identifier) wouldn't return a PDF, it would return, say, an HTML page with the abstract for the PDF and a link to the full text and PDF itself (using a journal as an example). alf. From mrylander at gmail.com Fri Feb 3 15:54:57 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Feb 3 15:56:00 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060203165355.GF31769@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: On 2/3/06, Daniel Chudnov wrote: > Back to this thread, as "What *exactly* are the core, required verbs?" > is now the to-do item on the table. > > > Mike Rylander wrote, on Thu, Feb 02, 2006 at 01:09:57PM +0000: > > On 2/2/06, Robert Sanderson wrote: > > > > > > >I think there's an important and convenient human/usability > > > >distinction. > > > > I think it's important that we not let this verb not get lax about the > > technical equivalence to fetch(id, displayable_format). It should > > return as much information as is practicable and displayable via > > [X]HTML. For instance, if target object is a bibliographic record, it > > should return the entire displayable portion of that record, not just > > part of it. If that target is an online book in PDF format, it should > > include whatever meta data surrounds the PDF /and/ a direct link to > > the PDF. Ideally, a data url containing the PDF would be included, > > but that might be going a little overboard. ;-) > > I think we're misunderstanding each other. My hope for the verb "go" was > to *not* ask webapp developers to change anything about how they display > content now (aside from whatever we ask with a unAPI microfauxmat). > "go" would just "take us to your existing view of this item". Like, for > a weblog entry with, say, uri tag:news.canarydatabase.org,2005:/entry/7, > the unAPI function: > > http://news.canarydatabase.org/unapi/? > verb=go& > uri=tag:news.canarydatabase.org,2005:/entry/7 > > ...would simply redirect immediately to: > > http://news.canarydatabase.org/archives/7 > > Ideally the weblog would include whatever unapi/autodiscovery > links/microfauxmat data in that entry page, then. > > It seems likely that asking webapp developers to change their app > behavior any more than this is a non-starter. > I think I just confused the issue by trying to be too abstract about implemention and specific about return format, because that's exactly what I imagine the common implementation of the "go" verb would be. > > > I think the proponents of the distinction (Dan, Alf, correct me if > > I've misinterpreted you), of which I'm one, see this as a shortcut to > > the human usable interface to and of the target object. It's the only > > required unAPI format, and it's a full-fledged format option that > > requires as much of the target object be embedded as the physical > > format ([X]HTML) allows (and that common user agents can use). > > It's a subtle point, whether "go" implies a "format" or not. I can see > it both ways, sure. Your point here, plus Ross's that a webapp's native > default human display for a URI might not be HTML, is well-taken. > > One more distinction worth raising here: the "fetch w/format" function > is something the user specifies... "gimme this object in this format". > The "go" redirection function instead allows the webapp to decide: "take > me to your home page for this object." Which completes the cycle... "oh, > so that's what this object is, eh? now, gimme it in this format." > Very convenient, and a closed loop back to where you first got an object > from wherever it might have ended up. > > That said, since this is just the first revision, I could live with > Alf's suggestion that this is arguably outside of the strict scope. > Which means I'll +1 keeping a "go" verb, removing the explicit mention of > "HTML" as expected response format, unless everybody else wants to -1 it, > which I'd go along with for now so we can move along down the list. > In any case, +1. I want my "go". :) > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Fri Feb 3 17:23:55 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Feb 3 17:24:18 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: > On 2/3/06, Daniel Chudnov wrote: >> >> It's a subtle point, whether "go" implies a "format" or not. I can see >> it both ways, sure. Your point here, plus Ross's that a webapp's native >> default human display for a URI might not be HTML, is well-taken. Not sure if this is brough out before, I am just wondering if it makes sense to define some _reserved_ keywords for "format", such as "default" or "native". This way "fetch w/format=native" will do the job of "go" verb, and "go" verb can be removed. How to repsond with "format=native" is a decision of individual repositories, I think it reflects the different views with "go" verb. regards, xiaoming From ross.singer at library.gatech.edu Fri Feb 3 18:10:15 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Feb 3 18:08:44 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: <43E3E2D7.2090602@library.gatech.edu> I think that Rob's response to this idea was to just leave the format argument out. With no specified format, the server could just send back what it likes best. Not sure it matters much one way or the other, but I would opt for not "reserving" anything and going with "null". -Ross. Xiaoming Liu wrote: >> On 2/3/06, Daniel Chudnov wrote: > > >>> >>> It's a subtle point, whether "go" implies a "format" or not. I can see >>> it both ways, sure. Your point here, plus Ross's that a webapp's >>> native >>> default human display for a URI might not be HTML, is well-taken. >> > > > Not sure if this is brough out before, I am just wondering if it makes > sense to define some _reserved_ keywords for "format", such as > "default" or "native". This way "fetch w/format=native" will do the > job of "go" verb, and "go" verb can be removed. > > How to repsond with "format=native" is a decision of individual > repositories, I think it reflects the different views with "go" verb. > > regards, > xiaoming > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From lists at hubmed.org Fri Feb 3 18:57:53 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Feb 3 19:01:14 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: On 03 Feb 2006, at 17:23, Xiaoming Liu wrote: >> On 2/3/06, Daniel Chudnov wrote: > >>> >>> It's a subtle point, whether "go" implies a "format" or not. I >>> can see >>> it both ways, sure. Your point here, plus Ross's that a webapp's >>> native >>> default human display for a URI might not be HTML, is well-taken. > > > Not sure if this is brough out before, I am just wondering if it > makes sense to define some _reserved_ keywords for "format", such > as "default" or "native". This way "fetch w/format=native" will do > the job of "go" verb, and "go" verb can be removed. > > How to repsond with "format=native" is a decision of individual > repositories, I think it reflects the different views with "go" verb. I was thinking that too - especially if the string passed to 'format' is normally a MIME type, eg application/rdf+xml: then a string like 'native' wouldn't collide with anything. alf. From liu_x at lanl.gov Fri Feb 3 19:49:54 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Feb 3 19:50:17 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: > I think that Rob's response to this idea was to just leave the format > argument out. With no specified format, the server could just send back > what it likes best. > Not sure it matters much one way or the other, but I would opt for not > "reserving" anything and going with "null". > -Ross. I think a reserved "native" is a little different from Rob's scenario. If "native" is a legal format, its type information can be contained in "UNAPI/formats" reponse, such as {"native":{"type":"application/pdf"}}, which might be handy to other applications. -- Xiaoming From azaroth at liverpool.ac.uk Sat Feb 4 08:29:17 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Sat Feb 4 08:32:32 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: >> I think that Rob's response to this idea was to just leave the format >> argument out. With no specified format, the server could just send back >> what it likes best. >I think a reserved "native" is a little different from Rob's scenario. If >"native" is a legal format, its type information can be contained in >"UNAPI/formats" reponse, such as {"native":{"type":"application/pdf"}}, >which might be handy to other applications. Which could be expressed for omitted as: {"" : {"type":"application/pdf"}} However, similar to the default search index issue in SRU, the default might be different for different objects. Yes you could put it in the formats/identifier operation, but not necessarily in the main formats response. That said, I'm not opposed to having a reserved format word, I'm opposed to having a separate verb. Rob From azaroth at liverpool.ac.uk Sat Feb 4 08:32:51 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Sat Feb 4 08:36:03 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <1138991890.21343.108.camel@helmsdeep> Message-ID: >> fetch(document) can be the redirect >Not sure about that: I would have thought fetch(object) would return >the object in its native format There hasn't been an 'official' definition of fetch(object) yet. >I think the point is that go(identifier) wouldn't return a PDF, it >would return, say, an HTML page with the abstract for the PDF and a >link to the full text and PDF itself (using a journal as an example). Not according to Dan's latest revision of the definition, which is why I'm -1. Rob From daniel.chudnov at yale.edu Sun Feb 5 13:39:01 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Feb 5 13:39:02 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> Message-ID: <20060205183900.GA28557@sildin.med.yale.edu> Xiaoming Liu wrote, on Fri, Feb 03, 2006 at 05:49:54PM -0700: > > >I think that Rob's response to this idea was to just leave the format > >argument out. With no specified format, the server could just send back > >what it likes best. > > >Not sure it matters much one way or the other, but I would opt for not > >"reserving" anything and going with "null". > >-Ross. > > I think a reserved "native" is a little different from Rob's scenario. If > "native" is a legal format, its type information can be contained in > "UNAPI/formats" reponse, such as {"native":{"type":"application/pdf"}}, > which might be handy to other applications. Somewhere in here a lightbulb went on... if we did away with the notion of a "verb" entirely, we could have three functions: UNAPI? - basic default site-wide response (formats list and/or services list, to be discussed) UNAPI?uri=URI - default "server-chosen" view of a URI. probably HTML. maybe just a redirect. UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format fetch. This simplifies everything enormously. The main problem it raises is that "default, server-chosen" views then must comprise per-URI format options somehow. And, then, the microformat/anchor question. But the answers to those would sway pretty hard toward in-HTML options, imho, which is also good. I think this is just a foreshortening of Alf's alternate spec function definition, without "action" or "search", and without an answer for the response formats (yet). Forgive me for needing three weeks to get your point, Alf, but the discussion led me here, eventually. :) It seems supremely simple, far more so than where we are now. Am I missing something? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Sun Feb 5 14:42:28 2006 From: lists at hubmed.org (Alf Eaton) Date: Sun Feb 5 14:45:48 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060205183900.GA28557@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: <7AF8264D-4B53-46AF-9689-3F5BC6403820@hubmed.org> On 05 Feb 2006, at 13:39, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Fri, Feb 03, 2006 at 05:49:54PM -0700: >> >>> I think that Rob's response to this idea was to just leave the >>> format >>> argument out. With no specified format, the server could just >>> send back >>> what it likes best. >> >>> Not sure it matters much one way or the other, but I would opt >>> for not >>> "reserving" anything and going with "null". >>> -Ross. >> >> I think a reserved "native" is a little different from Rob's >> scenario. If >> "native" is a legal format, its type information can be contained in >> "UNAPI/formats" reponse, such as {"native":{"type":"application/ >> pdf"}}, >> which might be handy to other applications. > > Somewhere in here a lightbulb went on... if we did away with the > notion > of a "verb" entirely, we could have three functions: > > UNAPI? - basic default site-wide response (formats list and/or > services > list, to be discussed) > > UNAPI?uri=URI - default "server-chosen" view of a URI. probably HTML. > maybe just a redirect. > > UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format > fetch. > > It seems supremely simple, far more so than where we are now. Am I > missing something? It seems reasonable to me (in this case, the server-chosen view could still look at the accept headers, to serve different views as appropriate)). GET and PUT/POST on UNAPI?uri=URI could be enough for copy & paste, at least. And it leaves open the option of adding an 'action' parameter to unAPI later if you wanted to add any extra functions. alf. From mrylander at gmail.com Sun Feb 5 15:01:48 2006 From: mrylander at gmail.com (Mike Rylander) Date: Sun Feb 5 15:02:53 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060205183900.GA28557@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: On 2/5/06, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Fri, Feb 03, 2006 at 05:49:54PM -0700: > > > > >I think that Rob's response to this idea was to just leave the format > > >argument out. With no specified format, the server could just send back > > >what it likes best. > > > > >Not sure it matters much one way or the other, but I would opt for not > > >"reserving" anything and going with "null". > > >-Ross. > > > > I think a reserved "native" is a little different from Rob's scenario. If > > "native" is a legal format, its type information can be contained in > > "UNAPI/formats" reponse, such as {"native":{"type":"application/pdf"}}, > > which might be handy to other applications. > > Somewhere in here a lightbulb went on... if we did away with the notion > of a "verb" entirely, we could have three functions: > > UNAPI? - basic default site-wide response (formats list and/or services > list, to be discussed) > > UNAPI?uri=URI - default "server-chosen" view of a URI. probably HTML. > maybe just a redirect. > > UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format fetch. > > > This simplifies everything enormously. The main problem it raises is > that "default, server-chosen" views then must comprise per-URI format > options somehow. And, then, the microformat/anchor question. But the > answers to those would sway pretty hard toward in-HTML options, imho, > which is also good. > > I think this is just a foreshortening of Alf's alternate spec function > definition, without "action" or "search", and without an answer for the > response formats (yet). Forgive me for needing three weeks to get your > point, Alf, but the discussion led me here, eventually. :) > > It seems supremely simple, far more so than where we are now. Am I > missing something? miker_ gazes into his crystal ball: That certainly covers the "copy" end of "copy and paste" ... The question then becomes, does the proto-idea of "paste" mean "paste what was copied into a thingy that I control, using some other API", or does it mean "paste via unapi what I copied into a repository that supports unapi-paste"? That doesn't need to be answered now, it just needs to be considered. If it ends up being the latter, then keeping "fetch", allowing the format to fetch to be server chosen (by not specifying it) and mandating that "go" does what you (Dan) said before -- bring the user to the "home page" of the object -- would be either 1) inconsistent with the the "copy" api if it required a URL param or 2) be notrivial to implement on the server side by requiring HTTP method detection, POST or PUT for "paste" vs GET for "copy". (Not non-trivial to a "developer", non-trivial to the "bad" programmer for which an implementation shouldn't be any more difficult that absolutely necessary. However, I could see simplifying the spec to make the "retrieval" verb optional such that "if no verb is supplied then 'fetch' is assumed". Again, my objection is removing specificity (and creating the potential for ambiguity or complexity down the road) under the guise of pruning verbosity. The only thing, IMHO, that is /actually/ simplifed by removing the action/verb/whatever URL param is the URL itself, especially if paste will eventually mean unapi-paste. > > -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 lists at hubmed.org Sun Feb 5 16:51:18 2006 From: lists at hubmed.org (Alf Eaton) Date: Sun Feb 5 16:51:24 2006 Subject: [gcs-pcs-list] issue vote: don't add "search" or "services" In-Reply-To: References: <20060202181647.GD7497@sildin.med.yale.edu> Message-ID: <2E4F6DB7-F80A-45CC-A9CE-9C433D85E1FA@hubmed.org> On 02 Feb 2006, at 16:45, Alf Eaton wrote: > > > > > > > > > > > > > Another useful section to add to a base document might be something like , using patterns in PCRE format to show which URIs this server has information about. eg ^info:pmid/\d+$ ^urn:isbn:\d{10,12}$ This could make it easier to automate the creation of a registry of unAPI servers as well. alf. From azaroth at liverpool.ac.uk Mon Feb 6 05:47:43 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Mon Feb 6 05:53:09 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060205183900.GA28557@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: <1139222863.7462.8.camel@helmsdeep> On Sun, 2006-02-05 at 13:39 -0500, Daniel Chudnov wrote: > UNAPI? - basic default site-wide response (formats list and/or services > list, to be discussed) > UNAPI?uri=URI - default "server-chosen" view of a URI. probably HTML. > maybe just a redirect. > UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format fetch. +1 Other patterns can always be added later, but at this stage it simplifies the spec dramatically I would use 'identifier' instead of 'uri' as a more neutral descriptor (it avoids a lot of headaches over what a URI is, whether they're pointful or not, etc.) > This simplifies everything enormously. The main problem it raises is > that "default, server-chosen" views then must comprise per-URI format > options somehow. How likely do you think it is that people will implement one service that has many different items that have many different non-overlapping formats? My guess is that it's not very frequent, so my suggestion is: Don't have a per item list of formats. If you have to retrieve the list of formats for each item, pick one, and retrieve it, you could just use the global list and expect that some sort of failure message (404 Item not available in this format) might occur. In Z39.50 explain, we tried to say 'these are all the possible combinations of everything you could possibly want'. That didn't work. In ZeeRex, while it's possible to give all the myriad ways, it's very uncommon and not especially useful. If a server doesn't support the 'any' relation, then it'll tell you in a diagnostic to your query. 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 azaroth at liverpool.ac.uk Mon Feb 6 05:51:32 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Mon Feb 6 05:56:58 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: <1139223092.7462.13.camel@helmsdeep> On Sun, 2006-02-05 at 15:01 -0500, Mike Rylander wrote: > or > does it mean "paste via unapi what I copied into a repository that > supports unapi-paste"? -6! The world does not need another record update spec. Even I'm not especially interested in the SRU update spec because there's six zillion other CRUD specs out there! Once you have copied it via unapi, you use your own methods to paste it down somewhere. 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 azaroth at liverpool.ac.uk Mon Feb 6 05:57:46 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Mon Feb 6 06:03:09 2006 Subject: [gcs-pcs-list] introspection document In-Reply-To: <2E4F6DB7-F80A-45CC-A9CE-9C433D85E1FA@hubmed.org> References: <20060202181647.GD7497@sildin.med.yale.edu> <2E4F6DB7-F80A-45CC-A9CE-9C433D85E1FA@hubmed.org> Message-ID: <1139223466.7462.19.camel@helmsdeep> On Sun, 2006-02-05 at 16:51 -0500, Alf Eaton wrote: > On 02 Feb 2006, at 16:45, Alf Eaton wrote: > > > > > > > > > > > > > > > > > Another useful section to add to a base document might be something > like , using patterns in PCRE format to show which URIs > this server has information about. > > eg > > ^info:pmid/\d+$ > ^urn:isbn:\d{10,12}$ > > > This could make it easier to automate the creation of a registry of > unAPI servers as well. XML: +1 services: -1 identifier patterns: +1 My slight revision would be: human readable text regexp single identifier string Why? So you can XSLT it into something with hyperlinks and human readable text in the same way you can XSLT an SRU explain document into a search interface. 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 lists at hubmed.org Tue Feb 7 14:55:32 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue Feb 7 14:58:52 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <20060205183900.GA28557@sildin.med.yale.edu> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: On 05 Feb 2006, at 13:39, Daniel Chudnov wrote: > Somewhere in here a lightbulb went on... if we did away with the > notion > of a "verb" entirely, we could have three functions: > > UNAPI? - basic default site-wide response (formats list and/or > services > list, to be discussed) > > UNAPI?uri=URI - default "server-chosen" view of a URI. probably HTML. > maybe just a redirect. > > UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format > fetch. There's a problem with having UNAPI?uri=URI produce one standard viewing format though: I'd originally thought of the response to 'UNAPI?uri=URI' to be returning the object in the object's default format. If it was a JPEG image it would be in that format; if it was an MP3 it would be in that format, etc. Otherwise, if a site hosts lots of objects in different formats and someone wants to just 'copy' one of them (not to just get metadata about it), they wouldn't automatically know which format to ask for. I think it's worth a comparison with HTTP, as that's essentially what we're reinventing here (but for non-http identifiers): for example, when a client calls http://www.example.com/item/1234567, the server looks at the Accept headers to see in which format the client would prefer the response. For a web browser, it's normally HTML or XHTML that have the highest q values. If there's no HTML version of the object available (eg if it's a JPEG image), the server will return that instead. I think this is what UNAPI?uri=URI should do. Then adding '&format=FORMAT' would be the equivalent of a file extension on the HTTP URL: '&format=jpg' vs '1234567.jpg', to force the return of a particular format. Hopefully that makes some sense. I think I'm saying that I prefer moving 'go' to 'format=server' or something, rather than having it as the default action for a URI. alf. From daniel.chudnov at yale.edu Tue Feb 7 15:52:18 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 7 15:53:27 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: <421F565B-7939-4B4A-88AA-B288325D2FB9@yale.edu> On Feb 7, 2006, at 2:55 PM, Alf Eaton wrote: > On 05 Feb 2006, at 13:39, Daniel Chudnov wrote: > >> Somewhere in here a lightbulb went on... if we did away with the >> notion >> of a "verb" entirely, we could have three functions: >> >> UNAPI? - basic default site-wide response (formats list and/or >> services >> list, to be discussed) >> >> UNAPI?uri=URI - default "server-chosen" view of a URI. probably >> HTML. >> maybe just a redirect. >> >> UNAPI?uri=URI&format=FORMAT - client-specified per-URI bare format >> fetch. > > There's a problem with having UNAPI?uri=URI produce one standard > viewing format though: I'd originally thought of the response to > 'UNAPI?uri=URI' to be returning the object in the object's default > format. If it was a JPEG image it would be in that format; if it > was an MP3 it would be in that format, etc. Otherwise, if a site > hosts lots of objects in different formats and someone wants to > just 'copy' one of them (not to just get metadata about it), they > wouldn't automatically know which format to ask for. > > I think it's worth a comparison with HTTP, as that's essentially > what we're reinventing here (but for non-http identifiers): for > example, when a client calls http://www.example.com/item/1234567, > the server looks at the Accept headers to see in which format the > client would prefer the response. For a web browser, it's normally > HTML or XHTML that have the highest q values. If there's no HTML > version of the object available (eg if it's a JPEG image), the > server will return that instead. I think this is what UNAPI?uri=URI > should do. Then adding '&format=FORMAT' would be the equivalent of > a file extension on the HTTP URL: '&format=jpg' vs '1234567.jpg', > to force the return of a particular format. I *think* I understand what you mean. I also think there are some fundamental cognitive impedance mismatches at play here. Maybe we have to clear those up before we close on this. The above suggested UNAPI call doesn't claim that there's "one standard viewing format" response for UNAPI?uri=URI. It essentially does what I'd asked "go" to do earlier: take me to *your* webapp's choice of a default page for the identified object. Whether the identifier itself is http or not shouldn't matter, imho, as we only want coders to have to do this one way. Even if it looks silly to ask for unapi.flickr.com/?uri=http://flickr.com/photos/ somebody/12345678/ when you could just go to the url/uri, it means there's one simply way for coders to build apps that take people back to that object's home in the flickr.com web application. When unalog starts collection objects, you might want to be able to ask unalog for unapi.unalog.com/?uri=http://flickr.com/photos/somebody/12345678/ and unalog might want to show you a unalog page for that same object. Or maybe not. It's the webapp's choice. Similarly for resolver- or router-like apps; if you say UNAPI? uri=info:isbn/1234567890X, you might get a list of services: library, amazon, etc. It depends on what the app decides. And that, in turn, depends on which app the user has decided to ask about the uri. In that way I totally agree that if there's no HTML view of a uri in a UNAPI application, the application should be expected to return whatever dissemination format it chooses. In practice, I suspect most every app will have some sort of default HTML page for every object, but it's right not to assume that. In the end it probably comes down to which pieces of these transactions are automatically performed by software, and which are dependent on per-transaction user choices. We probably don't have the same vision of that yet. And it seems likely we won't have a shared understanding of which is which until we have some UNAPI apps to play with. :) > Hopefully that makes some sense. I think I'm saying that I prefer > moving 'go' to 'format=server' or something, rather than having it > as the default action for a URI. I'm not sure I follow this. In general I'd be against any sort of "magic" or "reserved word" option because it's not simple, i.e. it sets up an easy mistake for everybody to make. What you're suggesting (and Xiaoming, before) for "format=server" seems completely consistent with the description in your second paragraph above for the behavior of UNAPI?uri=URI alone. Funny how I can read what you wrote and presume the opposite conclusion! -Dan From ehs at pobox.com Tue Feb 7 23:43:47 2006 From: ehs at pobox.com (Edward Summers) Date: Tue Feb 7 23:44:24 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: On Feb 7, 2006, at 1:55 PM, Alf Eaton wrote: > I think it's worth a comparison with HTTP, as that's essentially > what we're reinventing here (but for non-http identifiers): for > example, when a client calls http://www.example.com/item/1234567, > the server looks at the Accept headers to see in which format the > client would prefer the response. For a web browser, it's normally > HTML or XHTML that have the highest q values. If there's no HTML > version of the object available (eg if it's a JPEG image), the > server will return that instead. I think this is what UNAPI?uri=URI > should do. Then adding '&format=FORMAT' would be the equivalent of > a file extension on the HTTP URL: '&format=jpg' vs '1234567.jpg', > to force the return of a particular format. Thanks for bringing this up Alf. I really like the elegance of this, although I imagine the average javascript/cgi person is going to scratch their head at how to send extra accept headers and extract them properly on the server side. Of course they could just use the '&format=FORMAT' and call it a day. Is there an HTTP parallel to discovering what formats a particular URI can emit? //Ed From daniel.chudnov at yale.edu Wed Feb 8 10:44:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 10:44:52 2006 Subject: [gcs-pcs-list] vote: verb structure Message-ID: <20060208154446.GG6888@sildin.med.yale.edu> I'm a little lost about where we are w/r/to verb structure. There's a revision deadline next week, and many of us will be travelling to code4libcon in between. If possible I'd like to close on some more to-do items so we can move forward, even if we're just taking a few provisional decisions to be revisited. Please vote +1/0/-1 for each of the following: - Drop the explicit "verb" param. - unAPI becomes three functions: UNAPI? - introspection doc w/site-wide format list UNAPI?uri=URI - give user-specified object in server-chosen format, not specifying anything about accept-headers behavior *in* the unAPI spec (i.e., HTTP stays HTTP :) UNAPI?uri=URI&format=FORMAT - give user-specified object in user- specified format - unAPI becomes two functions: UNAPI? - introspection doc w/site-wide format list UNAPI?uri=URI&format=native - give user-specified object in server-chosen format ("native" value is special) UNAPI?uri=URI&format=FORMAT - give user-specified object in user- specified format I don't know if I've captured the distinctions accurately. But, I'd like to choose one and move on so we can talk about the base/introspection document. We will be iterating over these questions again, but need a next baseline. Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From alf at hubmed.org Wed Feb 8 10:50:01 2006 From: alf at hubmed.org (Alf Eaton) Date: Wed Feb 8 11:04:39 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208154446.GG6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> Message-ID: <43EA1329.30407@hubmed.org> Daniel Chudnov wrote: > - unAPI becomes two functions: > > UNAPI? - introspection doc w/site-wide format list > UNAPI?uri=URI&format=native - give user-specified object in server-chosen > format ("native" value is special) > UNAPI?uri=URI&format=FORMAT - give user-specified object in user- > specified format > Just to make sure where the distinction is here to allow someone to retrieve an object in a) it's original format (being JPEG for an image, MP3 for an audio file, etc) and b) the "server view" of an object (being HTML or whatever, but the same for each object)... In the example above, would 'uri=URI' produce (a) and 'uri=URI&format=native' produce (b)? alf. From daniel.chudnov at yale.edu Wed Feb 8 11:10:09 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 11:10:11 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <43EA1329.30407@hubmed.org> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> Message-ID: <20060208161009.GI6888@sildin.med.yale.edu> Alf Eaton wrote, on Wed, Feb 08, 2006 at 10:50:01AM -0500: > Daniel Chudnov wrote: > > >- unAPI becomes two functions: > > > > UNAPI? - introspection doc w/site-wide format list > > UNAPI?uri=URI&format=native - give user-specified object in > > server-chosen > > format ("native" value is special) > > UNAPI?uri=URI&format=FORMAT - give user-specified object in user- > > specified format > > Just to make sure where the distinction is here to allow someone to > retrieve an object in a) it's original format (being JPEG for an image, > MP3 for an audio file, etc) and b) the "server view" of an object (being > HTML or whatever, but the same for each object)... > > In the example above, would 'uri=URI' produce (a) and > 'uri=URI&format=native' produce (b)? In this specific option (two functions), there is *no* UNAPI?uri=URI function. It would be invalid. If that's not what you meant, could you distinguish between your vision of UNAPI?uri=URI and UNAPI?uri=URI&format=native? Or whatever the options you wanted to see would be? Sorry if this is making you repeat yourself, I just don't think I can accurately spell out what you mean just yet. Fwiw, I'm still held up by your use of the phrase "original format". I refuse to believe there is such a thing. :) That said, I want to move forward, whatever the outcome, so long as we agree on what we're agreeing on! -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Wed Feb 8 11:06:56 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Feb 8 11:12:57 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208154446.GG6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> Message-ID: <43EA1720.6060805@hubmed.org> Daniel Chudnov wrote: > - unAPI becomes two functions: > > UNAPI? - introspection doc w/site-wide format list > UNAPI?uri=URI&format=native - give user-specified object in server-chosen > format ("native" value is special) > UNAPI?uri=URI&format=FORMAT - give user-specified object in user- > specified format > Just to make sure where the distinction is here to allow someone to retrieve an object in a) it's original format (being JPEG for an image, MP3 for an audio file, etc) and b) the "server view" of an object (being HTML or whatever, but the same for each object)... In the example above, would 'uri=URI' produce (a) and 'uri=URI&format=native' produce (b)? alf. From lists at hubmed.org Wed Feb 8 11:18:06 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Feb 8 11:24:09 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208161009.GI6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> Message-ID: <43EA19BE.3030805@hubmed.org> Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Feb 08, 2006 at 10:50:01AM -0500: >> Daniel Chudnov wrote: >> >>> - unAPI becomes two functions: >>> >>> UNAPI? - introspection doc w/site-wide format list >>> UNAPI?uri=URI&format=native - give user-specified object in >>> server-chosen >>> format ("native" value is special) >>> UNAPI?uri=URI&format=FORMAT - give user-specified object in user- >>> specified format >> Just to make sure where the distinction is here to allow someone to >> retrieve an object in a) it's original format (being JPEG for an image, >> MP3 for an audio file, etc) and b) the "server view" of an object (being >> HTML or whatever, but the same for each object)... >> >> In the example above, would 'uri=URI' produce (a) and >> 'uri=URI&format=native' produce (b)? > > In this specific option (two functions), there is *no* UNAPI?uri=URI > function. It would be invalid. > > If that's not what you meant, could you distinguish between your vision > of UNAPI?uri=URI and UNAPI?uri=URI&format=native? Or whatever the options > you wanted to see would be? Sorry if this is making you repeat yourself, > I just don't think I can accurately spell out what you mean just yet. Excuse the made-up URIs (that's for another debate :-)... UNAPI?uri=flickr.com;1234567 would return a full-size image in JPEG format (as it was uploaded to Flickr) UNAPI?uri=flickr.com;1234567&format=rdf+xml would return the metadata for that image (author, camera model, date, etc) in RDF/XML. UNAPI?uri=flickr.com;1234567&format=native (I think 'native' isn't the best choice of term here, maybe 'server' or something) is the equivalent of your 'go' action, where it would display the image in the server's choice of format, probably HTML, or redirect to the original Flickr page. It's what someone who copied the image to their server would link to as a 'source' link. > > Fwiw, I'm still held up by your use of the phrase "original format". > I refuse to believe there is such a thing. :) That said, I want to > move forward, whatever the outcome, so long as we agree on what we're > agreeing on! Imagine if you wanted to retrieve an object from a server that hosted MP3s, images, text, etc (a weblog, say), how would you know in advance what to put in the format parameter? The "original format" would be the most appropriate format for that object (which is different from your 'go' action, I believe). alf. From azaroth at liverpool.ac.uk Wed Feb 8 11:20:43 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed Feb 8 11:26:29 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208161009.GI6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> Message-ID: <1139415643.12344.83.camel@helmsdeep> On Wed, 2006-02-08 at 11:10 -0500, Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Feb 08, 2006 at 10:50:01AM -0500: > If that's not what you meant, could you distinguish between your vision > of UNAPI?uri=URI and UNAPI?uri=URI&format=native? Or whatever the options > you wanted to see would be? Sorry if this is making you repeat yourself, > I just don't think I can accurately spell out what you mean just yet. Native: Whatever format the object is stored in. Server Chosen Human Oriented View: Some server chosen view of the data for human consumption, rather than machine consumption. For example, an XML database would return XML for native, whereas a relational database might return the text output from the SQL query. However both of them would likely produce something in HTML for the SCHO view. The point of exposing a 'native' view is for cases when you might be able to automatically transform the object into some other format, but lose information in the process. For example, the LC server would return raw MARC rather than MODS or Dublin Core XML in response to 'native'. Otherwise, you could still retrieve simple DC, but you wouldn't know whether there was a better format or not... ... unless that was explained in the introspection document. So there are two orthogonal special cases: * The object presented for human consumption * The object in as 'natural' a format as possible 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 daniel.chudnov at yale.edu Wed Feb 8 11:55:42 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 11:55:43 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <43EA19BE.3030805@hubmed.org> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> <43EA19BE.3030805@hubmed.org> Message-ID: <20060208165542.GL6888@sildin.med.yale.edu> Alf Eaton wrote, on Wed, Feb 08, 2006 at 11:18:06AM -0500: > Daniel Chudnov wrote: > >>> UNAPI?uri=URI&format=native - give user-specified object in > >>> server-chosen > >>> format ("native" value is special) > >>> UNAPI?uri=URI&format=FORMAT - give user-specified object in user- > >>> specified format > >>Just to make sure where the distinction is here to allow someone to > >>retrieve an object in a) it's original format (being JPEG for an image, > >>MP3 for an audio file, etc) and b) the "server view" of an object (being > >>HTML or whatever, but the same for each object)... > >> > >>In the example above, would 'uri=URI' produce (a) and > >>'uri=URI&format=native' produce (b)? > > > >In this specific option (two functions), there is *no* UNAPI?uri=URI > >function. It would be invalid. > > > >If that's not what you meant, could you distinguish between your vision > >of UNAPI?uri=URI and UNAPI?uri=URI&format=native? Or whatever the options > >you wanted to see would be? Sorry if this is making you repeat yourself, > >I just don't think I can accurately spell out what you mean just yet. > > Excuse the made-up URIs (that's for another debate :-)... > > UNAPI?uri=flickr.com;1234567 would return a full-size image in JPEG > format (as it was uploaded to Flickr) > > UNAPI?uri=flickr.com;1234567&format=rdf+xml would return the metadata > for that image (author, camera model, date, etc) in RDF/XML. > > UNAPI?uri=flickr.com;1234567&format=native (I think 'native' isn't the > best choice of term here, maybe 'server' or something) is the equivalent > of your 'go' action, where it would display the image in the server's > choice of format, probably HTML, or redirect to the original Flickr > page. It's what someone who copied the image to their server would link > to as a 'source' link. > > > > >Fwiw, I'm still held up by your use of the phrase "original format". > >I refuse to believe there is such a thing. :) That said, I want to > >move forward, whatever the outcome, so long as we agree on what we're > >agreeing on! > > Imagine if you wanted to retrieve an object from a server that hosted > MP3s, images, text, etc (a weblog, say), how would you know in advance > what to put in the format parameter? The "original format" would be the > most appropriate format for that object (which is different from your > 'go' action, I believe). Wait... does this contradict what you said above? In your formulation, wouldn't it make more sense for UNAPI?uri=URI to take you to the "go-equivalent" server-choice, and for UNAPI?uri=URI&format=native to take you to the "full-size image as it was uploaded"? I see the value of your mp3 use case... you want an mp3, and expect an mp3, so it should give you an mp3. I just don't think it's a global use case, and I think it confuses things, making the spec more complicated, to have UNAPI?uri=URI&format=native. It's not a global use case because even for photo or audio examples, assuming that "native" or "original" or whathaveyou should imply "jpeg at originally uploaded size" or "mp3 128kbps" is assuming too much. What if an audio provider stores everything as FLAC, and then generates AAC, MP3, OGG, and ASF, each at different levels, as needed? Do you really want their original FLAC? Same with photos... what if the "native/original" is TIFF? What if, whatever format photos users originally upload, the backend always generates the highest-quality tiff equivalent, and then regenerates the other formats out of that? What's the right answer to "what's native?" Or "what's original?" I *think* this agrees with the earlier argument that "assuming the server will provide [X]HTML in response to the go function is assuming too much." I think this confuses things because we'll have to explain this distinction to everybody in the spec, and that will be hard to get right without leaving a lot of people scratching their heads or challenging us the same way we're challenging each other. We can generate competing use cases all day, to be sure, whether they're edge cases or typical cases. For the purpose of the spec, though, imho we should stick to the most general functions that make the most sense to the most people, and avoid anything fancy that we need more than two sentences to explain. :) Again, though, like I said before, I'd be willing to go along with UNAPI?uri=URI&format=native (or whatever instead of "native") if everybody wants to, modulo your answer to my first question in this message above. It's just a revision for now, anyway. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Wed Feb 8 12:14:54 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Feb 8 12:20:55 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208161009.GI6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> Message-ID: <43EA270E.5070003@hubmed.org> [sorry for the broken threading] Daniel Chudnov wrote: >> Imagine if you wanted to retrieve an object from a server that hosted >> MP3s, images, text, etc (a weblog, say), how would you know in advance >> what to put in the format parameter? The "original format" would be the >> most appropriate format for that object (which is different from your >> 'go' action, I believe). > Wait... does this contradict what you said above? In your > formulation, > wouldn't it make more sense for UNAPI?uri=URI to take you to the > "go-equivalent" server-choice, and for UNAPI?uri=URI&format=native to > take you to the "full-size image as it was uploaded"? Rob Sanderson wrote: >Native: Whatever format the object is stored in. > >Server Chosen Human Oriented View: Some server chosen view of the data for human consumption, rather than machine consumption. This is why I said 'native' wasn't the best choice :-) Call it 'format=go' and it might be more understandable. Basically, I'm saying that calling UNAPI?uri=http://www.example.com/id/1234567 without any specified format should be the same as calling http://www.example.com/id/1234567 alf. From daniel.chudnov at yale.edu Wed Feb 8 13:32:59 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 13:33:00 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <43EA270E.5070003@hubmed.org> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> <43EA270E.5070003@hubmed.org> Message-ID: <20060208183258.GN6888@sildin.med.yale.edu> Alf Eaton wrote, on Wed, Feb 08, 2006 at 12:14:54PM -0500: > > This is why I said 'native' wasn't the best choice :-) Call it > 'format=go' and it might be more understandable. > > Basically, I'm saying that calling > UNAPI?uri=http://www.example.com/id/1234567 > without any specified format should be the same as calling > http://www.example.com/id/1234567 Not to repeat myself, beating this topic yet further into submission, but I think what you're saying here for this: UNAPI?uri=URI ...is exactly what I wanted from what was in version 0 as "go". Our polarity seems to be reversed... just to beat it down still further: MY-AMAZON-PROXY-UNAPI?uri=info:isbn/123456789X ...could take you to: http://www.amazon.com/gp/product/123456789X/what/ev/er ...or... FANCY-OPAC-UNAPI?uri=info:isbn/123456789X ...could send you to: http://FANCY-OPAC/isbn/123456789X or http://FULL-TEXT-SITE/isbn/123456789X , depending. If we agreed on that, we can vote that in, and then we can vote on a format=[native|original|whatnot] separately. The reason I don't like "format=[native|original|whatnot]" is that it's still not clear to me what that would mean for the above ISBN info URI, and if it's not clear here to us now, it will not likely be clear to spec implementers. It's just not a globally useful use case like UNAPI?uri=URI a.k.a. the-function-formerly-known-as-go is globally useful. -Dan, who promises not to say this again, and also to listen and not speak again for a little while others weigh in, hopefully. :P -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Wed Feb 8 13:51:30 2006 From: liu_x at lanl.gov (xiaoming liu) Date: Wed Feb 8 13:52:35 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> Message-ID: <43EA3DB2.10906@lanl.gov> Edward Summers wrote: > > Thanks for bringing this up Alf. I really like the elegance of this, > although I imagine the average javascript/cgi person is going to > scratch their head at how to send extra accept headers and extract > them properly on the server side. Of course they could just use the > '&format=FORMAT' and call it a day. > > Is there an HTTP parallel to discovering what formats a particular > URI can emit? I hope I am not confusing the issue anymore, but Edward's comments make me check the HTTP specification, and I think it might bring some insight into this discussion. Read [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12], there are server-driven negoitation and agent-driven negotiation. In parallel, the "go" verb is essential server-driven and "fetch" verb is agent-driven. I am wondering if it makes sense to drop the server-driven scenario in UNAPI, and always let client decide what to "fetch". However the server can express its preference in URI/formats response. Put it concretely, I am talking two-verb scenario: (1) UNAPI/URI/formats: List the formats available for the object identified by this URI, including server's perference or other metadata. (2)UNAPI/URI/SOMEFORMAT: returns the specified object in the specified format. xiaoming From lists at hubmed.org Wed Feb 8 19:12:26 2006 From: lists at hubmed.org (Alf Eaton) Date: Wed Feb 8 19:15:45 2006 Subject: [gcs-pcs-list] vote: verb structure In-Reply-To: <20060208183258.GN6888@sildin.med.yale.edu> References: <20060208154446.GG6888@sildin.med.yale.edu> <43EA1329.30407@hubmed.org> <20060208161009.GI6888@sildin.med.yale.edu> <43EA270E.5070003@hubmed.org> <20060208183258.GN6888@sildin.med.yale.edu> Message-ID: On 08 Feb 2006, at 13:32, Daniel Chudnov wrote: > Alf Eaton wrote, on Wed, Feb 08, 2006 at 12:14:54PM -0500: >> >> This is why I said 'native' wasn't the best choice :-) Call it >> 'format=go' and it might be more understandable. >> >> Basically, I'm saying that calling >> UNAPI?uri=http://www.example.com/id/1234567 >> without any specified format should be the same as calling >> http://www.example.com/id/1234567 > > Not to repeat myself, beating this topic yet further into submission, > but I think what you're saying here for this: > > UNAPI?uri=URI > > ...is exactly what I wanted from what was in version 0 as "go". No (which is why I said 'native' wan't a good choice). It's the other way round: UNAPI?uri=URI&format=server-view (say, for conciseness) would be the same as your "go". > Our > polarity seems to be reversed... just to beat it down still further: > > MY-AMAZON-PROXY-UNAPI?uri=info:isbn/123456789X > > ...could take you to: > > http://www.amazon.com/gp/product/123456789X/what/ev/er I think that UNAPI?uri=info:isbn/123456789X should return the full text of the book. Otherwise if you don't know what formats are available for that object, you'd have to go through all the possible options. I guess that could be taken as an argument for having a 'formats' description for each URI, but I'm not sure if that would be enough, and it's certainly more complicated (the client fetching the object would have to know about all possible formats to know which one it would prefer). alf. From daniel.chudnov at yale.edu Wed Feb 8 21:29:58 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 21:31:06 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: <43EA3DB2.10906@lanl.gov> References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> <43EA3DB2.10906@lanl.gov> Message-ID: On Feb 8, 2006, at 1:51 PM, xiaoming liu wrote: > Edward Summers wrote: >> >> Is there an HTTP parallel to discovering what formats a >> particular URI can emit? > > I hope I am not confusing the issue anymore, but Edward's comments > make me check the HTTP specification, and I think it might bring > some insight into this discussion. Read [http://www.w3.org/ > Protocols/rfc2616/rfc2616-sec12.html#sec12], there are server- > driven negoitation and agent-driven negotiation. This *is* very helpful, thanks for the pointer. I can't say I understand its implications fully, and I've never implemented anything for these protocol patterns. But, the pointer to the 300 Multiple Choices status code is enlightening. If I understand it correctly, it's essentially a redirect-class code where the status is essentially "choose one of these". It's possible, but not required, for the server to indicate a preference within a Location field; either way there's something called an "entity list" which provides format/location options. That sounds exactly like what we need! Has anybody here ever implemented this anywhere? :) If I'm not mistaken, what it would mean is that we could follow the spec closely, like this: UNAPI? - return a generally descriptive format list for the whole site (introspection document). UNAPI?uri=URI - return a 300 code with a list of formats (i.e., *this* becomes the "formats" response). the server can choose to state a preference in the Location: header; the client can choose to automatically follow the server preference, or not. UNAPI?uri=URI&format=FORMAT - return the client-specified FORMAT for URI. We could also specify a 406 Not Acceptable response for URI+FORMAT requests with invalid FORMAT values, which would additionally provide the format list entity response as the 300. Our previously distinct notions of "go" and "per-URI formats" becomes subsumed by the 300 response and the optional "Location" header value. So, there's no need for either "format=native" or "verb=formats". Does that make sense? And, again... has anybody ever implemented 300 responses, or know of a sample response entity list format we could use/adapt? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed Feb 8 22:55:55 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed Feb 8 22:57:04 2006 Subject: [gcs-pcs-list] suggested revision: "go" and "fetch" are different In-Reply-To: References: <9788368B-632A-4A18-BC37-BB27C699436D@yale.edu> <20060203165355.GF31769@sildin.med.yale.edu> <20060205183900.GA28557@sildin.med.yale.edu> <43EA3DB2.10906@lanl.gov> Message-ID: On Feb 8, 2006, at 9:29 PM, Daniel Chudnov wrote: > But, the pointer to the 300 Multiple Choices status code is > enlightening. Further on this: playing with apache's mod_speling, apache will generate an html entity list: http://curtis.med.yale.edu/dchud/test/112.txt And, poking around further, there's this: http://rfc.net/rfc2295.html RFC 2295: Transparent Content Negotiation in HTTP "ABSTRACT HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags." See also: http://rfc.net/rfc2296.html http://httpd.apache.org/docs/2.0/content-negotiation.html I've never read any of this stuff before (sure as hell didn't come up in library school! :). Well, maybe in the early days of learning my way around apache and why the default "it worked!" pages negotiated the right language like they do. Aside from that, I've never built fully internationalized webapps, and don't know how contemporary frameworks support this. So I can't yet figure out how its apparent bias toward a "literal file in this directory" scenario translates to a dynamic world, or whether the difference matters at all. I'd gladly repay you Wednesday for a clue today... -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Feb 9 14:56:14 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Feb 9 14:59:33 2006 Subject: [gcs-pcs-list] unapi without a format, sometimes Message-ID: <883CEB0C-2DD6-4850-A386-2763A75E0143@hubmed.org> I've been arguing myself in circles about this, so someone else is going to have to decide whether it's useful or not. I'd been trying to explain why calling UNAPI?uri=URI, with no format specified, should return the whole object in whatever format the server deemed best. It's essentially the client saying "I don't care what format it's in, just give me the ***** object!", which is what HTTP does when you use wget (for example) to fetch data from a http:// URL. You could say that, if it's possible to fetch the object in this way, then the object should just have a http:// URI and let HTTP handle it, but the whole point of unAPI is that it's essentially a replication of HTTP for objects that don't have http:// URIs (as well as being a workaround for servers that aren't designed to look at Accept headers to decide which format to return for a requested URL). I can imagine searching a database for a particular term, getting a list of results and then wanting to use unAPI to fetch each of those results using their identifiers, without actually knowing what each of the objects is (so not knowing whether to ask for an audio format or an image format, for example). I don't know if it's actually a likely scenario and, again, you could just use http:// identifiers for each of the objects, but it's a possibility. Anyway, if no-one thinks it's important then I'll be happy to forget about it :-) alf. From daniel.chudnov at yale.edu Thu Feb 9 16:13:18 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 9 16:13:23 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices Message-ID: <20060209211317.GA9320@sildin.med.yale.edu> Here's a first stab at working with 300 Multiple Choices responses as specified in RFC 2295: http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=pubmed http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=text Use wget -S on the above urls to see what's happening. I've modified Aaron Swartz's web.py to include a new multiple_choices() function which you can pass a server-preferred url and a list of alternates. def multiple_choices(url, alt_list=[]): context.status = '300 Multiple Choices' header('Content-Type', 'text/html') header('Location', url) header('TCN', 'list') alternates = ',\n'.join(['{"%s" %s {%s} {language %s}}' % \ (a['path'], a['q'], a['type'], a['lang']) for a in alt_list]) header('Alternates', alternates) alternates_html = '\n'.join(['
  • %s (%s, %s)
    • ' % \ (a['path'], a['path'], a['type'], a['lang']) for a in alt_list]) out = """

    Multiple Choices:

    """ % alternates_html return output(out) I am calling it from OPA, my UNAPI demo app which wraps the pubmed, flickr, and amazon apis and provides UNAPI services through web.py. If a bare (formatless) UNAPI?uri=URI call comes through, it returns the multiple choices response with a default Location: header with the value of the server-chosen preferred response. Here's what that call, which exercises the new web.py multiple_choices() function, looks like (handler is a per-URI-type handler, e.g. Amazon, or Flickr, each of which has its own list of formats): formats = handler.formats() alternates = [] for f in formats: alternates.append({ 'path': '?uri=%s&format=%s' % (uri, f[0]), 'q': 1.0, 'type': f[1], 'lang': 'en', }) web.multiple_choices(url=alternates[0]['path'], alt_list=alternates) And here's a sample call/response: [dlc33@sildin opa]$ wget -S http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 --16:00:23-- http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 => `index.html?uri=info:pmid%2F12345678' Resolving sildin.med.yale.edu... 127.0.0.1 Connecting to sildin.med.yale.edu|127.0.0.1|:8080... connected. HTTP request sent, awaiting response... HTTP/1.0 300 Multiple Choices Server: SimpleHTTP/0.6 Python/2.4.2 Date: Thu, 09 Feb 2006 21:00:23 GMT Content-Type: text/html Location: ?uri=info:pmid/12345678&format=pubmed TCN: list Alternates: {"?uri=info:pmid/12345678&format=pubmed" 1.0 {application/xml} {language en}}, {"?uri=info:pmid/12345678&format=text" 1.0 {text/plain} {language en}} Location: ?uri=info:pmid/12345678&format=pubmed [following] --16:00:23-- http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=pubmed => `index.html?uri=info:pmid%2F12345678&format=pubmed.2' Connecting to sildin.med.yale.edu|127.0.0.1|:8080... connected. HTTP request sent, awaiting response... HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/2.4.2 Date: Thu, 09 Feb 2006 21:00:23 GMT Content-Type: application/xml Length: unspecified [application/xml] [ <=> ] 5,745 --.--K/s 16:00:23 (43.14 MB/s) - `index.html?uri=info:pmid%2F12345678&format=pubmed.2' saved [5745] As you can see, the server provides the default Location, and all the alternates, right there. wget (and firefox and ie6) automatically redirect to the alternates. (Use firefox's livehttpheaders sidebar extension to see for yourself... I dunno what to use for IE.) I have *no idea* if I'm doing this correctly. But, it must be following the spec at least partly correctly, because the browsers/clients are behaving as expected. I am really liking this... the less we invent, the better! -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Feb 9 16:27:14 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Feb 9 16:27:26 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: <20060209211317.GA9320@sildin.med.yale.edu> References: <20060209211317.GA9320@sildin.med.yale.edu> Message-ID: <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> On 09 Feb 2006, at 16:13, Daniel Chudnov wrote: > Here's a first stab at working with 300 Multiple Choices responses > as specified in RFC 2295: > > http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 > http://sildin.med.yale.edu:8080/?uri=info:pmid/ > 12345678&format=pubmed > http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=text > > Use wget -S on the above urls to see what's happening. It seems to be working, which is nice, though it's giving the wrong address for the text/html version at the moment: Date: Thu, 09 Feb 2006 21:23:18 GMT Content-Type: text/html Location: ?uri=info:pmid/12345678&format=text TCN: list Alternates: {"?uri=info:pmid/12345678&format=text" 1.0 {text/plain} {language en}}, {"?uri=info:pmid/12345678&format=pubmed" 1.0 {application/xml} {language en}} Do the 1.0 values indicate some kind of preference? afl. From daniel.chudnov at yale.edu Thu Feb 9 16:36:41 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 9 16:36:42 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> Message-ID: <20060209213640.GB9320@sildin.med.yale.edu> Alf Eaton wrote, on Thu, Feb 09, 2006 at 04:27:14PM -0500: > > >Here's a first stab at working with 300 Multiple Choices responses > >as specified in RFC 2295: > > > > http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 > > http://sildin.med.yale.edu:8080/?uri=info:pmid/ > >12345678&format=pubmed > > http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=text > > > >Use wget -S on the above urls to see what's happening. > > It seems to be working, which is nice, though it's giving the wrong > address for the text/html version at the moment: Actually, the text/html Content-Type header is correct. It describes the included HTML payload which lists the alternates in an HTML ul, somewhat like the apache mod_speling 300 response does. You just don't see that if your client automatically follows the Location header. When I tried this without the Location header (i.e. without the default server-chosen variant), the HTML response came up in my browsers. I don't know the correct wget incantation to prevent wget from automatically following the redirect. > Date: Thu, 09 Feb 2006 21:23:18 GMT > Content-Type: text/html > Location: ?uri=info:pmid/12345678&format=text > TCN: list > Alternates: {"?uri=info:pmid/12345678&format=text" 1.0 {text/plain} > {language en}}, > {"?uri=info:pmid/12345678&format=pubmed" 1.0 {application/xml} > {language en}} > > Do the 1.0 values indicate some kind of preference? Yes. Right now I just hard-coded 1.0 values for everything. See: http://rfc.net/rfc2295.html#s5.1 -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Feb 10 12:21:49 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 10 12:21:51 2006 Subject: [gcs-pcs-list] Wednesday in Corvallis Message-ID: <20060210172149.GD18029@sildin.med.yale.edu> I'll be doing a talk Wednesday at code4lib 2006 called "Connecting Everything with unAPI and OPA". (OPA being the API proxy I sent links to yesterday.) For the purposes of that talk, I'll need to take some liberties with the state of unAPI just to get code working. A large percentage of the people who've been active in the unAPI discussions so far will be in attendance. During the Wednesday breakout sessions, there will be a "Developing unAPI" session where I hope all of y'all can sit together and hammer out some decisions so we can get Revision 1 out the door the next day (2/16) as planned. Which is to say - I have to make some choices on my own to get the talk prepared in time, but those are just arbitrary. I *really* hope many of you can join up Wednesday afternoon at the breakout session to make these decisions together. So... all that in mind, and knowing that a few of you won't be there, here are the key questions right in front of us: - What exactly are the verbs? - Do we like the HTTP 300 Multiple Choices response? I really do, but nobody else has tried it afaik. - What should the base/introspection document look like? These are the most critical choices we need to make for revision 1, imho. They don't have to be *right*, they just need to be *made*, so we can all try something common out. We'll have at least two more revisions to get things right. :) So, if you know you can't get to Corvallis, please weigh in between now and Tuesday on these three issues. In particular (and even if you will be there Wednesday), if you have ideas about what the base/introspection doc should look like, please send a sample expressing that idea to the list before Wednesday. The sooner the better, actually... if anybody sends anything I understand before Monday, I won't have to make something up for my talk. Or, come to think of it, I can probably just use one of the examples somebody already sent... so now's a good time to revise or replace those if you want. :) We slid back about a week this month, which I'll just blame on my aching wrists. But, we've made a ton of progress and surfaced a lot of issues. There's no reason we shouldn't have a much improved revision done for the deadline Thursday, which we can then test and promote more actively. And, thanks, everybody, for taking what clearly must be significant time from your busy lives to help work on this. Who knows if unAPI will take over the world... it's sure fun trying, though! -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Mon Feb 13 03:11:16 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Feb 13 03:11:22 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: <20060209213640.GB9320@sildin.med.yale.edu> References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> Message-ID: Dan, This is my understainding of HTTP 300 and RFC 2295 (it's also a new learning to me). Although using HTTP 300, RFC 2995 is only one possible implementation. HTTP spec only says "the response SHOULD include an entity containing a list of resource characteristics and location", but it doesn't specify exactly how the payload will be look alike. So my understanding is that we can use RFC 2295 if appropriate, otherwise it's still correct to use HTTP 300 with some custom formats for the list of resources. My reservations with RFC 2295 are: (a) it looks complex, (b) it focus on format translation, such as source-quality attributes (http://rfc.net/rfc2295.html#s5.3), which might be difficult to apply in typical unAPI applications, how do we measure source-qualit of a DC, METS, or PDF represenation of a resource? (c) RFC 2295 allows flexible location URLs, it's not clear how to enforce nice unAPI URL pattern (?uri=###&format=###). So I very much like HTTP 300 in unAPI, but I am not so sure about RFC 2295. I am thinking it's perhaps appropriate to combine formats of unAPI version 0 with HTTP 300. Following this thinking I wrote a simle Java interface to demonstrate the idea: * http://dp9.cs.odu.edu:8080/unapi/ * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027 * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=html * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=oai_dc * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=pdf Notice http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027 returns a HTTP 300 response with a Location: header pointing to arXiv, and the payload is an XML file same as format list definition of unAPI revision 0. A browser will automatically redirect the page to Location:header; but an unAPI-aware agent can parse the XML file and choose appropriate version. The telnet output is like: $ telnet dp9.cs.odu.edu 8080 Trying 128.82.7.229... Connected to dp9.cs.odu.edu. Escape character is '^]'. GET /unapi/?uri=nlin/0004027 HTTP/1.0 HTTP/1.1 300 Multiple Choices Server: Apache-Coyote/1.1 Location: http://arxiv.org/abs/nlin/0004027 Content-Type: text/xml;charset=ISO-8859-1 Content-Length: 475 Date: Mon, 13 Feb 2006 09:49:43 GMT Connection: close htmlhttp://www.w3.org/TR/xhtml1text/htmlXHTML 1.0 pdfapplication/pdffulltext in pdf format psapplication/pdffulltext in ps format oai_dchttp://www.openarchives.orgtext/xmloai dc regards, xiaoming On Thu, 9 Feb 2006, Daniel Chudnov wrote: > Alf Eaton wrote, on Thu, Feb 09, 2006 at 04:27:14PM -0500: >> >>> Here's a first stab at working with 300 Multiple Choices responses >>> as specified in RFC 2295: >>> >>> http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678 >>> http://sildin.med.yale.edu:8080/?uri=info:pmid/ >>> 12345678&format=pubmed >>> http://sildin.med.yale.edu:8080/?uri=info:pmid/12345678&format=text >>> >>> Use wget -S on the above urls to see what's happening. >> >> It seems to be working, which is nice, though it's giving the wrong >> address for the text/html version at the moment: > > Actually, the text/html Content-Type header is correct. It describes > the included HTML payload which lists the alternates in an HTML ul, > somewhat like the apache mod_speling 300 response does. You just don't > see that if your client automatically follows the Location header. > > When I tried this without the Location header (i.e. without the default > server-chosen variant), the HTML response came up in my browsers. I > don't know the correct wget incantation to prevent wget from automatically > following the redirect. > > >> Date: Thu, 09 Feb 2006 21:23:18 GMT >> Content-Type: text/html >> Location: ?uri=info:pmid/12345678&format=text >> TCN: list >> Alternates: {"?uri=info:pmid/12345678&format=text" 1.0 {text/plain} >> {language en}}, >> {"?uri=info:pmid/12345678&format=pubmed" 1.0 {application/xml} >> {language en}} >> >> Do the 1.0 values indicate some kind of preference? > > Yes. Right now I just hard-coded 1.0 values for everything. > > See: http://rfc.net/rfc2295.html#s5.1 > > -Dan > > From daniel.chudnov at yale.edu Mon Feb 13 08:12:18 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Feb 13 08:13:22 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> Message-ID: <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> On Feb 13, 2006, at 3:11 AM, Xiaoming Liu wrote: > This is my understainding of HTTP 300 and RFC 2295 (it's also a new > learning to me). Although using HTTP 300, RFC 2995 is only one > possible implementation. HTTP spec only says "the response SHOULD > include an entity containing a list of resource characteristics and > location", but it doesn't specify exactly how the payload will be > look alike. So my understanding is that we can use RFC 2295 if > appropriate, otherwise it's still correct to use HTTP 300 with some > custom formats for the list of resources. Right, that's my understanding too. I *think* the only thing RFC2295 specifies w/r/to the list is the syntax of the Alternates header. > My reservations with RFC 2295 are: > (a) it looks complex, (b) it focus on format translation, such as > source-quality attributes (http://rfc.net/rfc2295.html#s5.3), which > might be difficult to apply in typical unAPI applications, how do > we measure source-qualit of a DC, METS, or PDF represenation of a > resource? > (c) RFC 2295 allows flexible location URLs, it's not clear how to > enforce nice unAPI URL pattern (?uri=###&format=###). (a) Agreed! I don't want to have to do all that. :) (b) Agreed about fudging q values. But, do we really even have to do that? I'm just setting them all to 1.0 in OPA for now... though, I don't know if that's wrong or not. The values themselves are required, indeed. (c) I ran into this with OPA and flickr. I ended up using unAPI URLs for formats I was generating myself (e.g. DC/MODS for flickr images), but just pointing instead to actual flickr.com URLs for their various image sizes. Seemed like a decent tradeoff when the actual list of formats can be dynamically altered per object and the resulting object disseminations actually came from somewhere else. It could have just as easily pulled the external resources in through an unAPI- style uri&format URL. If I'm reading RFC 2295 correctly, we don't *have* to do all of the transparent/automatic negotiation, and can just do the list entities (i.e. no "choice"). > So I very much like HTTP 300 in unAPI, but I am not so sure about > RFC 2295. I am thinking it's perhaps appropriate to combine formats > of unAPI version 0 with HTTP 300. This was my thinking, too, for the formats lists. > Following this thinking I wrote a simle Java interface to > demonstrate the idea: Cool! > * http://dp9.cs.odu.edu:8080/unapi/ > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027 > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=html > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=oai_dc > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=pdf Very cool! The one (tangiential) comment I'd make on this is that I'd intended (though maybe hadn't said this well yet) that remote protocol response wrappers would be elided and just the bare data objects should be brought back through unAPI. So instead of the whole OAI response, in OPA I'm just slicing out the section and return what's inside that. As for whether we should stick to RFC 2295, I don't know. Having your code to compare with helps a lot! Afaik, though, there aren't any other RFCs describing HTTP 300 response structures and strategies. So, I'd want to see several good arguments against RFC 2295 before dismissing it entirely. Like, maybe we could make a list up of whether/how different user-agent client apps/libraries handle 300 responses and RFC 2295 implementations... if nobody does the right thing, we can roll our own, but if lots of tools do use RFC 2295, I'd be loath to do something incompatible. Which is not to say that what you're suggesting is incompatible, either. :) I'm *really* looking forward to working on this together in person in a few days! -Dan From mrylander at gmail.com Mon Feb 13 10:05:37 2006 From: mrylander at gmail.com (Mike Rylander) Date: Mon Feb 13 10:06:43 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> Message-ID: First, I'm really, /really/ warming up to the status-300 proposal. The more I roll it over in my head, the more natural it seems. I'm also really digging the Alternates header format, though I'd like to tweak it so that it's valid JSON ... Actually, there's an idea. It's very close now, and with some "s and :s, and a hash key or two it would be JSON. Perhaps that would allay some of the complexity concerns? More (direct response) comments inline below. On 2/13/06, Daniel Chudnov wrote: > On Feb 13, 2006, at 3:11 AM, Xiaoming Liu wrote: > > > This is my understainding of HTTP 300 and RFC 2295 (it's also a new > > learning to me). Although using HTTP 300, RFC 2995 is only one > > possible implementation. HTTP spec only says "the response SHOULD > > include an entity containing a list of resource characteristics and > > location", but it doesn't specify exactly how the payload will be > > look alike. So my understanding is that we can use RFC 2295 if > > appropriate, otherwise it's still correct to use HTTP 300 with some > > custom formats for the list of resources. > > Right, that's my understanding too. > > I *think* the only thing RFC2295 specifies w/r/to the list is the > syntax of the Alternates header. > That is my reading too. IMHO, the header version would be easier to interpret programatically than respsonse body. If we wanted to use the response body, the spec could go something like read: If you get a status 300 response and you don't know how to parse the Alternates header, look for elements in the response body that contain the class 'unapi-link', grab the type attribute to find the format, and use the href as direct links to the listed items ... hmmm.... the header version solves a lot of information-loss issues for us, though. I'd hate for us to have to come up with YAMF (microformat) to handle the 'ambiguous format' case. :( > > > My reservations with RFC 2295 are: > > (a) it looks complex, (b) it focus on format translation, such as > > source-quality attributes (http://rfc.net/rfc2295.html#s5.3), which > > might be difficult to apply in typical unAPI applications, how do > > we measure source-qualit of a DC, METS, or PDF represenation of a > > resource? > > (c) RFC 2295 allows flexible location URLs, it's not clear how to > > enforce nice unAPI URL pattern (?uri=###&format=###). > > (a) Agreed! I don't want to have to do all that. :) > However, it's less complex than trying to encode as much information in a or . > (b) Agreed about fudging q values. But, do we really even have to do > that? I'm just setting them all to 1.0 in OPA for now... though, I > don't know if that's wrong or not. The values themselves are > required, indeed. The q value is a function of the format translation lossiness. If the native to format-x translation is completely losses, it's 1.0. If there's some minor loss of data, it's 0.8. Arbitrary? Sure, to some small degree, but unless the format has a quality scale built in, like JPEG, then it's always a bit arbitrary. I guess my point is, this is a /very good/ feature, especially for those that don't know MARCXML from a hole in the ground and can't judge the relative precision of the available formats. > > (c) I ran into this with OPA and flickr. I ended up using unAPI URLs > for formats I was generating myself (e.g. DC/MODS for flickr images), > but just pointing instead to actual flickr.com URLs for their various > image sizes. Seemed like a decent tradeoff when the actual list of > formats can be dynamically altered per object and the resulting > object disseminations actually came from somewhere else. It could > have just as easily pulled the external resources in through an unAPI- > style uri&format URL. > As your experiment suggests, I don't think we'd have to validate server-generated URLs. The URLs coming through in the header would be generated by the server that is, or should be, interpreting them, so we can safely assume that it created URLs it understands. > > If I'm reading RFC 2295 correctly, we don't *have* to do all of the > transparent/automatic negotiation, and can just do the list entities > (i.e. no "choice"). > > > > So I very much like HTTP 300 in unAPI, but I am not so sure about > > RFC 2295. I am thinking it's perhaps appropriate to combine formats > > of unAPI version 0 with HTTP 300. > > This was my thinking, too, for the formats lists. > > > > Following this thinking I wrote a simle Java interface to > > demonstrate the idea: > > Cool! > > > > * http://dp9.cs.odu.edu:8080/unapi/ > > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027 > > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=html > > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=oai_dc > > * http://dp9.cs.odu.edu:8080/unapi/?uri=nlin/0004027&format=pdf > > Very cool! > > The one (tangiential) comment I'd make on this is that I'd intended > (though maybe hadn't said this well yet) that remote protocol > response wrappers would be elided and just the bare data objects > should be brought back through unAPI. So instead of the whole OAI > response, in OPA I'm just slicing out the section and return > what's inside that. > > > As for whether we should stick to RFC 2295, I don't know. Having > your code to compare with helps a lot! Afaik, though, there aren't > any other RFCs describing HTTP 300 response structures and > strategies. So, I'd want to see several good arguments against RFC > 2295 before dismissing it entirely. Like, maybe we could make a list > up of whether/how different user-agent client apps/libraries handle > 300 responses and RFC 2295 implementations... if nobody does the > right thing, we can roll our own, but if lots of tools do use RFC > 2295, I'd be loath to do something incompatible. > > Which is not to say that what you're suggesting is incompatible, > either. :) > > I'm *really* looking forward to working on this together in person in > a few days! > Arg! I'm jealous :( > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Mon Feb 13 13:00:25 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Feb 13 13:00:31 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> Message-ID: On Mon, 13 Feb 2006, Mike Rylander wrote: > > That is my reading too. IMHO, the header version would be easier to > interpret programatically than respsonse body. > > If we wanted to use the response body, the spec could go something > like read: If you get a status 300 response and you don't know how to > parse the Alternates header, look for elements in the response body > that contain the class 'unapi-link', grab the type attribute to find > the format, and use the href as direct links to the listed items ... I am kind of looking at this problem in an inverse way :-) (1) the response body always carries authentic unapi information, which can be payloaded by plain http 300 message, or rfc2295 compatible http 300 message, or http 200 (not sure about last one). (2) when unapi is payloaded by rfc2295 compatible response, more information can be expressed by Alternates header, such as lang, charset,font, source-quality, or any other features. This is a value-added process and is out of the scope of unapi. And the server _must_ guarantee that information in Alternates header doesn't conflict with unapi payload. Another issue is how to define unapi-specific features (e.g. namespace of xml data, such as DC or MODS), it might be interesting to check http://www.ietf.org/rfc/rfc2506.txt (Media Feature Tag Registration Procedure) and existing assignments: http://www.iana.org/assignments/media-feature-tags regards, xiaoming From liu_x at lanl.gov Mon Feb 13 13:27:14 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon Feb 13 13:27:17 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> Message-ID: On Mon, 13 Feb 2006, Daniel Chudnov wrote: > > As for whether we should stick to RFC 2295, I don't know. Having your code > to compare with helps a lot! Afaik, though, there aren't any other RFCs I am not really using RFC 2295, in Java servlet I did it this way: if (format==null){ response.setContentType("text/xml;charset=UTF-8"); if (uri!=null){ response.setStatus(300); response.setHeader("Location",ARXIV+"abs/"+uri); } //print unapi response } else{ //process uri=###&format=### } > describing HTTP 300 response structures and strategies. So, I'd want to see > several good arguments against RFC 2295 before dismissing it entirely. Like, > maybe we could make a list up of whether/how different user-agent client > apps/libraries handle 300 responses and RFC 2295 implementations... if nobody > does the right thing, we can roll our own, but if lots of tools do use RFC > 2295, I'd be loath to do something incompatible. > I think one design choice is the capacity of user-agent, whether it has to be RFC2295 aware, or unAPI, or both. For now IMHO unAPI seems easiest for developer to understand and use. xiaoming From daniel.chudnov at yale.edu Mon Feb 13 13:33:43 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Feb 13 13:33:45 2006 Subject: [gcs-pcs-list] using 300 Multiple Choices In-Reply-To: References: <20060209211317.GA9320@sildin.med.yale.edu> <35498E29-9E13-4F2C-8052-FAB5F6B645E4@hubmed.org> <20060209213640.GB9320@sildin.med.yale.edu> <51616E61-139E-4124-99E5-3E5865B2FD92@yale.edu> Message-ID: <20060213183343.GF14368@sildin.med.yale.edu> Xiaoming Liu wrote, on Mon, Feb 13, 2006 at 11:27:14AM -0700: > On Mon, 13 Feb 2006, Daniel Chudnov wrote: > >describing HTTP 300 response structures and strategies. So, I'd want to > >see several good arguments against RFC 2295 before dismissing it > >entirely. Like, maybe we could make a list up of whether/how different > >user-agent client apps/libraries handle 300 responses and RFC 2295 > >implementations... if nobody does the right thing, we can roll our own, > >but if lots of tools do use RFC 2295, I'd be loath to do something > >incompatible. > > I think one design choice is the capacity of user-agent, whether it has > to be RFC2295 aware, or unAPI, or both. For now IMHO unAPI seems easiest > for developer to understand and use. You *are* thinking about it in an inverse way from me. :) My thinking is that if RFC 2295 provides what we need, and if a decent number of user-agents already support it, then this part of unAPI itself shouldn't specify anything other than how to implement RFC 2295. Or, put differently, if we did go that way, unAPI would primarily be a convention for implementing RFC 2295, and unAPI's scope would shrink accordingly. We'd still need to discuss the introspection bit either way... -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Feb 16 11:06:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 16 11:06:52 2006 Subject: [gcs-pcs-list] yesterday's meeting at code4lib 2006 Message-ID: <20060216160646.GB23763@sildin.med.yale.edu> We had a very productive meeting yesterday here in Corvallis. At least 25 people were there, many of whom have been active in discussions here on-list, along with many new folks. I had given a talk earlier on "connecting everything with unAPI and OPA", and whether the talk itself increased or diminished the number of meeting attendees is perhaps subject to debate. To the point, though, there seemed to be unanimous consent that where we're going with unAPI is generally a good an useful direction, and that making some decisions together for this next revision was a good plan. So, we did just that, and the choices we made were nearly unanimous. Here they are, in short: - Use 300 Multiple Choices responses (it's the best fit) - Don't use RFC 2295 (it's much more complex than what we need) - Use the link autodiscovery pattern with type application/xml - Use an xml formats list payload - The xml formats list payload for the site (i.e. the introspection doc) looks like this: formats format (repeats) name (required) type (required) docs (optional, just a url for humans) namespace_uri (optional) schema_location (optional) - The xml formats list payload for specific URIs looks exactly the same, but also includes an element "uri" as a second-level element under formats with the uri as the text value - The microformat for identifying objects in web pages is: whatever you want There are subtleties to these decisions which we went over, and for several of these at least one person had particular concerns, and promised to follow up on-list with proof validating or invalidating their concerns. :) Probably the biggest issue we agreed to track carefully is browser /language/framework support for 300 Multiple Choices response. In this iteration of the spec we'd like to be reasonably thorough in testing the pattern with a variety of popular tools to see how easily this response pattern can be implemented. So please block off a few hours in the next few weeks to try it out with your own favorite toolchain. I'll update the unapi-revision-1 writeboard this morning and post again when a draft is ready. Other attendees from yesterday are hereby invited to share their own impressions of the meeting. :) More soon, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Feb 16 15:42:12 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 16 15:42:14 2006 Subject: [gcs-pcs-list] latest revision (please review) Message-ID: <20060216204212.GA23835@sildin.med.yale.edu> I've updated the unapi-revision-1 writeboard in the backpack page and posted txt and html exports of it here: http://curtis.med.yale.edu/dchud/unapi/ (under latest.{txt,html}) Please review and note any corrections/comments. There were several interesting issues raised yesterday, which remain to discuss. I will start a backpack to-do for revision 2 soon to capture these. In the meantime please verify that this revision captures what you recall of yesterday's discussion and generally seems copasetic. And, please do so today as I'd like to post this before the day is over and if that happens we (er, many of us) can celebrate in person with tasty oregon microbrew. :) Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu Feb 16 19:05:38 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu Feb 16 19:09:26 2006 Subject: [gcs-pcs-list] yesterday's meeting at code4lib 2006 In-Reply-To: <20060216160646.GB23763@sildin.med.yale.edu> References: <20060216160646.GB23763@sildin.med.yale.edu> Message-ID: <783F8F3E-DB17-4C3F-AD2A-F8F17A10A3E3@hubmed.org> On 16 Feb 2006, at 11:06, Daniel Chudnov wrote: > > Probably the biggest issue we agreed to track carefully is browser > /language/framework support for 300 Multiple Choices response. In > this iteration of the spec we'd like to be reasonably thorough in > testing the pattern with a variety of popular tools to see how > easily this response pattern can be implemented. So please block > off a few hours in the next few weeks to try it out with your own > favorite toolchain. I wasn't at the meeting, so this was probably mentioned there, but could you describe what the benefit is of using a 300 Multiple Choices response? What it seems like is duplication in the header of information already in the XML response, or vice versa. alf. From liu_x at lanl.gov Thu Feb 16 21:56:54 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu Feb 16 21:56:52 2006 Subject: [gcs-pcs-list] yesterday's meeting at code4lib 2006 In-Reply-To: <783F8F3E-DB17-4C3F-AD2A-F8F17A10A3E3@hubmed.org> References: <20060216160646.GB23763@sildin.med.yale.edu> <783F8F3E-DB17-4C3F-AD2A-F8F17A10A3E3@hubmed.org> Message-ID: On Thu, 16 Feb 2006, Alf Eaton wrote: > > On 16 Feb 2006, at 11:06, Daniel Chudnov wrote: >> >> Probably the biggest issue we agreed to track carefully is browser >> /language/framework support for 300 Multiple Choices response. In >> this iteration of the spec we'd like to be reasonably thorough in >> testing the pattern with a variety of popular tools to see how >> easily this response pattern can be implemented. So please block >> off a few hours in the next few weeks to try it out with your own >> favorite toolchain. > > I wasn't at the meeting, so this was probably mentioned there, but could you > describe what the benefit is of using a 300 Multiple Choices response? What > it seems like is duplication in the header of information already in the XML > response, or vice versa. > I think the idea is to use HTTP 300 without RFC 2295, there will be no "Alternative" header, therefore no conflicts. In current spec, HTTP 300 is really an indicator that the reponse is a "multiple choice". I think it's same as HTTP 300 usage in mod_speling. Below is my personal opinion. Though I like RFC 2295, so far we cannot figure out an "official" way of "profiling" RFC 2295 to the scope of unapi. I also wonder if HTTP300 Location: header should be used, per previous "go" verb discussion. xiaoming > alf. > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list -- Xiaoming From azaroth at liverpool.ac.uk Fri Feb 17 01:56:32 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Fri Feb 17 01:59:46 2006 Subject: [gcs-pcs-list] yesterday's meeting at code4lib 2006 In-Reply-To: <783F8F3E-DB17-4C3F-AD2A-F8F17A10A3E3@hubmed.org> References: <20060216160646.GB23763@sildin.med.yale.edu> <783F8F3E-DB17-4C3F-AD2A-F8F17A10A3E3@hubmed.org> Message-ID: >I wasn't at the meeting, so this was probably mentioned there, but >could you describe what the benefit is of using a 300 Multiple >Choices response? What it seems like is duplication in the header of >information already in the XML response, or vice versa. As Xiaoming says, the thought was that the compromise between existing specs and doing the easy thing to implement was to set the status to 300, but not use rfc2295 header syntax, which is a pain to send and a bigger pain to process on the client end compared to simple xml. Mod_speling doesn't do 2295, just html in the payload, so if people criticise us for not doing it, we can point at the 'official' module that doesn't do it either. The advantage to 300 over 200 is one of explicitness, but one that needs to be tested out in various toolkits as to how easy it is to return, and how easy it is to process once received. Although Firefox might not do anything with 300 now (unless there's a location: header) it quite possibly could be convinced to do it in the future, whereas a 200 is practically impossible to do anything with at a browser level, it's just yet-another-xml-payload (potentially + a styleshet reference). Does that help? Rob From daniel.chudnov at yale.edu Fri Feb 17 05:03:29 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 17 05:03:32 2006 Subject: [gcs-pcs-list] latest revision (please review) In-Reply-To: <20060216204212.GA23835@sildin.med.yale.edu> References: <20060216204212.GA23835@sildin.med.yale.edu> Message-ID: <20060217100329.GA22884@curtis.med.yale.edu> This is now posted publicly at: http://www.code4lib.org/specs/unapi/revision-1 An upcoming to-do item will be "where should this spec live?" -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jyoung at oclc.org Tue Feb 21 10:59:05 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Tue Feb 21 10:59:36 2006 Subject: [gcs-pcs-list] latest revision (please review) Message-ID: Following the code4lib unAPI breakout session, I implemented unAPI v1 in WikiD. Examples can be found at the bottom of http://alcme.oclc.org/wikid/WikiDApis. At the breakout, I argued for including namespace_uri and schema_location elements to the unAPI responses. Since "format" values are uncontrolled, I think these additional fields will be useful so that automated processes have a chance to interact with unAPI as well as humans. I would like to propose a small change to the spec, however. Instead of "schema_location", I would like to see something like "schema_url". This is to avoid confusion with the meaning of XML's xsi:schemaLocation which pairs namespaceURIs with schemaURLs. The WikiD implementation reflects this proposed change. Comments, suggestions, and corrections are welcome. Thanks. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Daniel Chudnov > Sent: Friday, February 17, 2006 5:03 AM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] latest revision (please review) > > This is now posted publicly at: > > http://www.code4lib.org/specs/unapi/revision-1 > > An upcoming to-do item will be "where should this spec live?" > > -Dan > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From eric at openly.com Fri Feb 17 22:51:37 2006 From: eric at openly.com (Eric Hellman) Date: Thu Feb 23 02:10:38 2006 Subject: [gcs-pcs-list] Fwd: COinS OpenURL link in Copac V3 Message-ID: >COinS OpenURL link in Copac V3 > >The Copac V3 Experimental Interface now has COinS (ContextObjects in >Spans) in the Full Record display. The COinS is an HTML element that >contains an OpenURL and is structured in such as way that it is not >normally visible. To make the COinS useful (and visible) you need to >install an extension into your Web browser. > >One such extension is Openly Informatics' OpenURL Referrer >(http://www.openly.com/openurlref/) for the Firefox browser. Once >installed the extension can be configured to make the COinS into a >clickable link that delivers an OpenURL to your Institutional >OpenURL Resolver. > >You can access Copac V3 from the Copac Home Page at: > > http://copac.ac.uk/ > >If you try the COinS please let us know how you get on - all >feedback appreciated. > >regards > >Shirley Cousins >Copac service > >-- >Dr Shirley Cousins >copac@manchester.ac.uk - Copac is a MIMAS >Copac Service service, funded by >Manchester Computing, JISC using records >University of Manchester supplied by CURL - >Oxford Road, Manchester M13 9PL, UK >Fax: 0161 275 6040 Tel: 0161 275 6037 http://copac.ac.uk/ > -- Eric Hellman, Director OCLC Openly Informatics Division eric@openly.com 2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Thu Feb 23 10:36:59 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Feb 23 10:37:02 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: <20060223153659.GA8530@sildin.med.yale.edu> So far I know about three unAPI (revision 1) implementations; one has been mentioned here. For the benefit of those not tuned into blogspace, could I trouble the other two people/groups on this list who've not mentioned their work here yet to do so, and indicate what language/toolkits you used, and share any thoughts on what worked and what didn't? One of our tasks for revision 2 is to keep close watch on whether the 300 response was an issue for mainstream languages/frameworks, so the more data, the better. Nudzh nudzh... -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Thu Feb 23 11:44:31 2006 From: mrylander at gmail.com (Mike Rylander) Date: Thu Feb 23 11:45:35 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <20060223153659.GA8530@sildin.med.yale.edu> References: <20060223153659.GA8530@sildin.med.yale.edu> Message-ID: On 2/23/06, Daniel Chudnov wrote: > So far I know about three unAPI (revision 1) implementations; one has been > mentioned here. For the benefit of those not tuned into blogspace, could > I trouble the other two people/groups on this list who've not mentioned > their work here yet to do so, and indicate what language/toolkits you > used, and share any thoughts on what worked and what didn't? > http://open-ils.org/blog/?p=47 :) I'll be reposting that with externally accessible links for the unAPI stuff (well, all of it, actually). The only issue I ran into is that I can't set the content type to application/xml for the status 300 responses. It always comes across as text/html. I also need to make failures more graceful, but I'm programming for success right now. > One of our tasks for revision 2 is to keep close watch on whether the > 300 response was an issue for mainstream languages/frameworks, so the > more data, the better. > > Nudzh nudzh... -dc > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From jyoung at oclc.org Thu Feb 23 12:13:25 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Thu Feb 23 12:13:56 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: I mentioned the WikiD implementation, but I didn't provide any details about the implementation. Every request to WikiD is implemented as an OpenURL service (written in Java). These services return XML responses containing an XSL Stylesheet reference for rendering in the browser. This OpenURL request, for example, displays the WikiD Sandbox page: http://alcme.oclc.org/wikid/resolver?url_ver=Z39.88-2004&url_ctx_fmt=inf o:ofi/fmt:kev:mtx:ctx&ctx_enc=info:ofi/enc:UTF-8&rft_id=info:sid/localho st:CollectionWikiPages:WikiDSandbox&svc_dat=action=display&rfr_id=info:s id/oclc.org:referrer/WikiD As an aside, WikiD supports a shorthand variant which is immediately transformed into the OpenURL equivalent above and handed off to the OpenURL resolver for processing: http://alcme.oclc.org/wikid/WikiDSandbox The XSL Stylesheet referenced in the response generates unAPI URI microformat and autodiscovery HTML links that are derived from information found in the OpenURL XML response. The unAPI HTTP interface functions are also implemented as OpenURL services. For example: http://alcme.oclc.org/wikid/resolver?url_ver=Z39.88-2004&url_ctx_fmt=inf o:ofi/fmt:kev:mtx:ctx&ctx_enc=info:ofi/enc:UTF-8&rft_id=info:sid/localho st:CollectionGsafd&svc_dat=action%3Dunapi&rfr_id=info:sid/oclc.org:refer rer/WikiD (Do a "View/Source" in your browser to see the underlying unAPI XML response.) Just like the shorthand example above, I have a similar shorthand unAPI interface to hide the OpenURL complexity: http://alcme.oclc.org/wikid/unapi/CollectionGsafd http://alcme.oclc.org/wikid/unapi/CollectionGsafd?uri=info:sid/localhost :CollectionGsafd:GSAFD000001 http://alcme.oclc.org/wikid/unapi/CollectionGsafd?uri=info:sid/localhost :CollectionGsafd:GSAFD000001&format=zthes As in the earlier case, WikiD immediately transforms these shorthand variants into the OpenURL equivalents and hands them off to the OpenURL resolver for processing. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu [mailto:gcs-pcs-list- > bounces@cipolo.med.yale.edu] On Behalf Of Daniel Chudnov > Sent: Thursday, February 23, 2006 10:37 AM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: [gcs-pcs-list] rev1 implementations > > So far I know about three unAPI (revision 1) implementations; one has been > mentioned here. For the benefit of those not tuned into blogspace, could > I trouble the other two people/groups on this list who've not mentioned > their work here yet to do so, and indicate what language/toolkits you > used, and share any thoughts on what worked and what didn't? > > One of our tasks for revision 2 is to keep close watch on whether the > 300 response was an issue for mainstream languages/frameworks, so the > more data, the better. > > Nudzh nudzh... -dc > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From Peter.Binkley at ualberta.ca Thu Feb 23 18:19:02 2006 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Thu Feb 23 18:27:47 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: <908893006339C0409519E4065DF3B24901571047@mailserver.ualibrary.ualberta.ca> My Wordpress plugin is described here: http://www.wallandbinkley.com/quaedam/?p=59 It's a single PHP file that can be dropped into a Wordpress instance. With the appropriate modifications to a couple of other Wordpress templates, it provides unAPI service, in the form of oai_dc or mods records for blog entries. Peter Peter Binkley Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley@ualberta.ca > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Daniel Chudnov > Sent: Thursday, February 23, 2006 08:37 AM > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: [gcs-pcs-list] rev1 implementations > > So far I know about three unAPI (revision 1) implementations; > one has been mentioned here. For the benefit of those not > tuned into blogspace, could I trouble the other two > people/groups on this list who've not mentioned their work > here yet to do so, and indicate what language/toolkits you > used, and share any thoughts on what worked and what didn't? > > One of our tasks for revision 2 is to keep close watch on > whether the 300 response was an issue for mainstream > languages/frameworks, so the more data, the better. > > Nudzh nudzh... -dc > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From azaroth at liverpool.ac.uk Fri Feb 24 06:38:16 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Fri Feb 24 06:46:08 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: <20060223153659.GA8530@sildin.med.yale.edu> Message-ID: <1140781097.7181.46.camel@helmsdeep> On Thu, 2006-02-23 at 16:44 +0000, Mike Rylander wrote: > On 2/23/06, Daniel Chudnov wrote: > > So far I know about three unAPI (revision 1) implementations; one has been > > mentioned here. > http://open-ils.org/blog/?p=47 :) > > I'll be reposting that with externally accessible links for the unAPI > stuff (well, all of it, actually). >From the blog post: Which leads into the third interface; OpenILS/Evergreen has joined the unAPI club. The URLs follow the r1 version for the unAPI spec, and look like http://10.4.0.10/opac/extras/unapi?uri=info:oils/metabib-metarecord/424582&format=mods. Yeah, that?s a fake info: URI, but it works for us. Any suggestions (other than ?get that approved as a real info: uri?) would be graciously accepted. My suggestion is to relax the requirement for a uri and allow any sort of identifier. This MAY be a uri, or it might be a local identifier of some description. Here's a second implementation (I'll count myself as a first) where it just does not work. Forcing potential implementers to first understand what a URI is, understand that they can't build one properly, then make the decision to implement the spec anyway and just fake it, is simply not productive for the very limited (if any?) benefit. 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 jyoung at oclc.org Fri Feb 24 09:04:19 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Feb 24 09:05:00 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: I agree with Rob. The only legitimate use of the identifier in unAPI is to send it back to the specified unAPI service. They should never leak out, and the service should never be called except in the context of pulling the information out of the . I worry that people will be tempted to push unAPI beyond its copy-and-paste formats sanction, and turn it into OpenURL Lite. We should actively discourage this and removing the URI restriction on identifiers would be step in that direction. Jeff > -----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: Friday, February 24, 2006 6:38 AM > To: Mike Rylander > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] rev1 implementations > > On Thu, 2006-02-23 at 16:44 +0000, Mike Rylander wrote: > > On 2/23/06, Daniel Chudnov wrote: > > > So far I know about three unAPI (revision 1) implementations; one has > been > > > mentioned here. > > http://open-ils.org/blog/?p=47 :) > > > > I'll be reposting that with externally accessible links for the unAPI > > stuff (well, all of it, actually). > > >From the blog post: > > Which leads into the third interface; OpenILS/Evergreen has joined the > unAPI club. The URLs follow the r1 version for the unAPI spec, and look > like > http://10.4.0.10/opac/extras/unapi?uri=info:oils/metabib- > metarecord/424582&format=mods. Yeah, that's a fake info: URI, but it works > for us. Any suggestions (other than "get that approved as a real info: > uri") would be graciously accepted. > > > My suggestion is to relax the requirement for a uri and allow any sort > of identifier. This MAY be a uri, or it might be a local identifier of > some description. > > Here's a second implementation (I'll count myself as a first) where it > just does not work. Forcing potential implementers to first understand > what a URI is, understand that they can't build one properly, then make > the decision to implement the spec anyway and just fake it, is simply > not productive for the very limited (if any?) benefit. > > > 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 liu_x at lanl.gov Fri Feb 24 12:08:39 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Feb 24 12:08:20 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <908893006339C0409519E4065DF3B24901571047@mailserver.ualibrary.ualberta.ca> References: <908893006339C0409519E4065DF3B24901571047@mailserver.ualibrary.ualberta.ca> Message-ID: hi, I put together a simple greasemonkey script to insert unapi links (largely following Dan's COINS-PMH examle). This is my first greasemonkey code so be cautioned ;-) It's very simple but may be useful for testing unapi page. http://lxming.blogspot.com/2006_02_19_lxming_archive.html#114079874086518136 It seems to work well with Peter's wordpress site, but it doesn't work with Jeff's wikiD, I suspect wikiD's content (XML) is rendered at client side, and greasemonkey only intercept the XML page, but not the rendered HTML page. regards, xiaoming On Thu, 23 Feb 2006, Binkley, Peter wrote: > My Wordpress plugin is described here: > http://www.wallandbinkley.com/quaedam/?p=59 > > It's a single PHP file that can be dropped into a Wordpress instance. > With the appropriate modifications to a couple of other Wordpress > templates, it provides unAPI service, in the form of oai_dc or mods > records for blog entries. > > Peter > > Peter Binkley > Digital Initiatives Technology Librarian > Information Technology Services > 4-30 Cameron Library > University of Alberta Libraries > Edmonton, Alberta > Canada T6G 2J8 > Phone: (780) 492-3743 > Fax: (780) 492-9243 > e-mail: peter.binkley@ualberta.ca > > > >> -----Original Message----- >> From: gcs-pcs-list-bounces@cipolo.med.yale.edu >> [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf >> Of Daniel Chudnov >> Sent: Thursday, February 23, 2006 08:37 AM >> To: gcs-pcs-list@cipolo.med.yale.edu >> Subject: [gcs-pcs-list] rev1 implementations >> >> So far I know about three unAPI (revision 1) implementations; >> one has been mentioned here. For the benefit of those not >> tuned into blogspace, could I trouble the other two >> people/groups on this list who've not mentioned their work >> here yet to do so, and indicate what language/toolkits you >> used, and share any thoughts on what worked and what didn't? >> >> One of our tasks for revision 2 is to keep close watch on >> whether the 300 response was an issue for mainstream >> languages/frameworks, so the more data, the better. >> >> Nudzh nudzh... -dc >> >> >> -- >> Daniel Chudnov >> Yale Center for Medical Informatics >> (203) 737-5789 >> _______________________________________________ >> gcs-pcs-list mailing list >> gcs-pcs-list@cipolo.med.yale.edu >> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list >> > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From liu_x at lanl.gov Fri Feb 24 12:18:14 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Feb 24 12:17:58 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <1140781097.7181.46.camel@helmsdeep> References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> Message-ID: On Fri, 24 Feb 2006, Rob Sanderson wrote: > > My suggestion is to relax the requirement for a uri and allow any sort > of identifier. This MAY be a uri, or it might be a local identifier of > some description. > > Here's a second implementation (I'll count myself as a first) where it > just does not work. Forcing potential implementers to first understand > what a URI is, understand that they can't build one properly, then make > the decision to implement the spec anyway and just fake it, is simply > not productive for the very limited (if any?) benefit. > I am not sure I agree on this. I think one purpose of unapi is to encourage reuse of identifiers, thus you can easily copy/paste them across different applications. Clearly we are not there yet, but it seems a right direction to me. The issues is rather the practice of using URI, in the case of Mike's example, other alternatives may include: (a) use unregisterred URI, so simply something like: oils:metabib-metarecord/424582 or whatever. (b) use tag URI. see http://www.faqs.org/rfcs/rfc4151.html xiaoming From jyoung at oclc.org Fri Feb 24 12:50:45 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Feb 24 12:51:13 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: I can't believe I'm arguing against using URIs, but I'm having trouble believing that unregistered URIs or tag URI will ever prove useful across different applications. I have trouble enough thinking info URIs will cross that threshold. Jeff > I am not sure I agree on this. I think one purpose of unapi is to > encourage reuse of identifiers, thus you can easily copy/paste them across > different applications. Clearly we are not there yet, but it seems a right > direction to me. > > The issues is rather the practice of using URI, in the case of Mike's > example, other alternatives may include: > (a) use unregisterred URI, so simply something like: > oils:metabib-metarecord/424582 or whatever. > > (b) use tag URI. see http://www.faqs.org/rfcs/rfc4151.html From mrylander at gmail.com Fri Feb 24 13:26:38 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Feb 24 13:27:41 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: Message-ID: On 2/24/06, Young,Jeff (OR) wrote: > I can't believe I'm arguing against using URIs, but I'm having trouble > believing that unregistered URIs or tag URI will ever prove useful > across different applications. I have trouble enough thinking info URIs > will cross that threshold. Well, as someone mentioned at some point, somewhere that I can't find ATM, these identifiers will only be used against the generating server. I think this is the same misunderstanding that got me in trouble with Rob and Ross in #code4lib: the "copy" for copy-and-paste is a copy of the /target/ of the unapi call, not a copy of the identifier in the unapi call. In other words, it's always copy-by-value and never by-ref. OpenURL/COinS would fill the copy-by-ref need. So, I like the idea of URIs because they can be parsed and validated with existing software. And, though I'd not seen them before, tag URIs look interesting because they include a description of the authoritative body. So, I'd like to propose that, if we want to use URIs (which I do), they should either be valid info URIs or correctly constructed tag URIs. Is this a TODO, and possibly a vote? > > Jeff > > > I am not sure I agree on this. I think one purpose of unapi is to > > encourage reuse of identifiers, thus you can easily copy/paste them > across > > different applications. Clearly we are not there yet, but it seems a > right > > direction to me. > > > > The issues is rather the practice of using URI, in the case of Mike's > > example, other alternatives may include: > > (a) use unregisterred URI, so simply something like: > > oils:metabib-metarecord/424582 or whatever. > > > > (b) use tag URI. see http://www.faqs.org/rfcs/rfc4151.html > > _______________________________________________ > 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 daniel.chudnov at yale.edu Fri Feb 24 14:38:17 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Feb 24 14:38:19 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: Message-ID: <20060224193816.GQ8497@sildin.med.yale.edu> Mike Rylander wrote, on Fri, Feb 24, 2006 at 06:26:38PM +0000: > > So, I'd like to propose that, if we want to use URIs (which I do), > they should either be valid info URIs or correctly constructed tag > URIs. Wait... did you misspeak? Because this doesn't make sense to me. URLs are valid URIs. ftp protocol addresses are valid URIs. I'd be dead-set against limiting to *just* info and tag URIs. That said, rev1 of the spec is almost neutral on this point. It doesn't say "these must be valid URIs as defined by RFC ____." It just refers to the objects as "identifiable" in one place, and later, "URI means 'some URI of interest'." So, essentially, the "allow bare identifiers" side of this discussion almost already has what it wants. And, yes, we should decide one way or the other and make it explicit. > Is this a TODO, and possibly a vote? It already is a TODO. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Fri Feb 24 17:30:51 2006 From: mrylander at gmail.com (Mike Rylander) Date: Fri Feb 24 17:31:55 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <20060224193816.GQ8497@sildin.med.yale.edu> References: <20060224193816.GQ8497@sildin.med.yale.edu> Message-ID: On 2/24/06, Daniel Chudnov wrote: > Mike Rylander wrote, on Fri, Feb 24, 2006 at 06:26:38PM +0000: > > > > So, I'd like to propose that, if we want to use URIs (which I do), > > they should either be valid info URIs or correctly constructed tag > > URIs. > > Wait... did you misspeak? Because this doesn't make sense to me. I don't think so... > > URLs are valid URIs. ftp protocol addresses are valid URIs. I'd be > dead-set against limiting to *just* info and tag URIs. > Limiting it to info: and tag: URIs seems arbitrary, granted, but that would provide structure for cross-server interpretation (or at least human investigation), a target for implementers to hit, and impetus to include at least /some/ globally recognizable information. Good things in my mind, but if the requirements outweigh the benefits in others minds I won't fight. :) > > That said, rev1 of the spec is almost neutral on this point. It doesn't > say "these must be valid URIs as defined by RFC ____." It just refers > to the objects as "identifiable" in one place, and later, "URI means > 'some URI of interest'." So, essentially, the "allow bare identifiers" > side of this discussion almost already has what it wants. And, yes, > we should decide one way or the other and make it explicit. > If we want to go the other way and say "pass something that the server understands via the uri param" then that's cool. I'm not married to the fake info: URIs, or to tag: URIs for that matter (haven't moved to them yet), so whatever the consensus is, I'll follow. > > > Is this a TODO, and possibly a vote? > > It already is a TODO. :) > Cool. > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From lists at hubmed.org Fri Feb 24 18:28:58 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri Feb 24 18:32:18 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <1140781097.7181.46.camel@helmsdeep> References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> Message-ID: <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> On 24 Feb 2006, at 06:38, Rob Sanderson wrote: > My suggestion is to relax the requirement for a uri and allow any sort > of identifier. This MAY be a uri, or it might be a local identifier of > some description. I agree with this. My suggestion is to denote local identifiers using either 'local' in the class (eg ) or prefixing the identifier with a hash (eg ). URIs would look like . alf. From liu_x at lanl.gov Fri Feb 24 19:21:06 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri Feb 24 19:20:46 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> Message-ID: On Fri, 24 Feb 2006, Alf Eaton wrote: > > On 24 Feb 2006, at 06:38, Rob Sanderson wrote: > >> My suggestion is to relax the requirement for a uri and allow any sort >> of identifier. This MAY be a uri, or it might be a local identifier of >> some description. > > I agree with this. My suggestion is to denote local identifiers using either > 'local' in the class (eg ) or > prefixing the identifier with a hash (eg title="#123456"/>). URIs would look like title="info:pmid/1234567"/>. I think this is essentially re-inventing URI. To me using unregistered URI is perfectly ok in this case. see http://www.w3.org/TR/uri-clarification/#unregistered-uri-schemes I wrote a small piece to describe my view of this matter, not that I am good at writing, but I believe the issue is important. http://lxming.blogspot.com/2006/02/thinking-about-identifier-and-unapi.html regards, xiaoming > > alf. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From azaroth at liverpool.ac.uk Sat Feb 25 09:57:51 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Sat Feb 25 10:01:06 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> Message-ID: On Fri, 24 Feb 2006, Xiaoming Liu wrote: >On Fri, 24 Feb 2006, Alf Eaton wrote: > >> >> On 24 Feb 2006, at 06:38, Rob Sanderson wrote: >> >>> My suggestion is to relax the requirement for a uri and allow any sort >>> of identifier. This MAY be a uri, or it might be a local identifier of >>> some description. >> >> I agree with this. My suggestion is to denote local identifiers using either >I think this is essentially re-inventing URI. To me using unregistered >URI is perfectly ok in this case. As Xiaoming says in his blog post, there are two types of persistence, which equate to three types of 'value'. An identifier can persist across time, and/or between applications. This is where we need clarification from dchud ... is the goal to promote persistent identifiers, or merely enable them? My thoughts are with Jeff that requiring persistent identifiers is creating openUrl-lite. If the idea is a copy protocol, not a resolve or link-to protocol, then I don't see that persistent identifiers are required. You see something you want, and you copy it. You don't link to it, so you don't need persistent identifiers. Rob From jyoung at oclc.org Sat Feb 25 13:35:20 2006 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Sat Feb 25 13:35:59 2006 Subject: [gcs-pcs-list] rev1 implementations Message-ID: I think a useful analogy here would be to OAI resumptionTokens. They aren't required to be URIs and have no meaning outside the context of OAI. You can expect them to remain viable for some (perhaps unspecified) period of time, but you shouldn't assume forever. This implies that the microformat should contain an optional expiration timestamp on the identifier. This raises another problem with instances of pages being cached. If the identifiers aren't persistent, then the unAPI HTML inclusions in cached pages might lose their viability over time. Despite these problems, I'm still inclined to think that URIs are an unnecessary requirement. Jeff > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Robert Sanderson > Sent: Saturday, February 25, 2006 9:58 AM > Cc: GCS-PCS list > Subject: Re: [gcs-pcs-list] rev1 implementations > > > On Fri, 24 Feb 2006, Xiaoming Liu wrote: > >On Fri, 24 Feb 2006, Alf Eaton wrote: > > > >> > >> On 24 Feb 2006, at 06:38, Rob Sanderson wrote: > >> > >>> My suggestion is to relax the requirement for a uri and allow any > >>> sort of identifier. This MAY be a uri, or it might be a local > >>> identifier of some description. > >> > >> I agree with this. My suggestion is to denote local > identifiers using > >> either > > >I think this is essentially re-inventing URI. To me using > unregistered > >URI is perfectly ok in this case. > > As Xiaoming says in his blog post, there are two types of > persistence, which equate to three types of 'value'. > > An identifier can persist across time, and/or between applications. > > This is where we need clarification from dchud ... is the > goal to promote persistent identifiers, or merely enable > them? My thoughts are with Jeff that requiring persistent > identifiers is creating openUrl-lite. > > If the idea is a copy protocol, not a resolve or link-to > protocol, then I don't see that persistent identifiers are > required. You see something you want, and you copy it. You > don't link to it, so you don't need persistent identifiers. > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From liu_x at lanl.gov Sat Feb 25 16:22:32 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Sat Feb 25 16:22:10 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> Message-ID: On Sat, 25 Feb 2006, Robert Sanderson wrote: > > As Xiaoming says in his blog post, there are two types of persistence, > which equate to three types of 'value'. > > An identifier can persist across time, and/or between applications. > > This is where we need clarification from dchud ... is the goal to > promote persistent identifiers, or merely enable them? My thoughts are > with Jeff that requiring persistent identifiers is creating > openUrl-lite. > > If the idea is a copy protocol, not a resolve or link-to protocol, then > I don't see that persistent identifiers are required. You see something > you want, and you copy it. You don't link to it, so you don't need > persistent identifiers. Rob, I am really arguing the case for URI, not persistent URI. I think whether persistent or not is not core of this discussion. URI makes unapi consistent with other web specifications. In my mind, unapi specification is flexible and simple as long as it sticks to URI. How to use is up to developer's imagination, in some occasions persistent URI might be a good case, and in other occasions transient URI might work well too. We don't need to define library convention for either "local" URI or "transisient" URI. An URI is an URI, period. regards, xiaoming > > Rob > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From azaroth at liverpool.ac.uk Sat Feb 25 17:32:39 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Sat Feb 25 17:36:01 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> Message-ID: >> An identifier can persist across time, and/or between applications. >> This is where we need clarification from dchud ... is the goal to >> promote persistent identifiers, or merely enable them? >> If the idea is a copy protocol, not a resolve or link-to protocol, then >> I don't see that persistent identifiers are required. >I am really arguing the case for URI, not persistent URI. I think whether >persistent or not is not core of this discussion. URI makes unapi >consistent with other web specifications. But having an identifier instead of necessarily a URI doesn't make it inconsistent because you can always have a URI, you just don't have to. If there's no requirement for persisence across time or applications, then there's no just need for a URI. >In my mind, unapi specification is flexible and simple as long as it >sticks to URI. Surely a URI is less flexible than a string that could be a URI but doesn't have to be. Surely a URI is less simple than a string that could be a URI but doesn't have to be. I just don't see any argument for why we NEED a URI rather than an arbitrary identifier and a recommended best practice to use URIs when appropriate? Rob From liu_x at lanl.gov Sat Feb 25 18:47:58 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Sat Feb 25 18:47:35 2006 Subject: [gcs-pcs-list] rev1 implementations In-Reply-To: References: <20060223153659.GA8530@sildin.med.yale.edu> <1140781097.7181.46.camel@helmsdeep> <215C169D-C2A6-4221-B16E-9C33DCDC5816@hubmed.org> Message-ID: I promise this will be my last email on this topic ;-) I will opt to Dan's decision on this. On Sat, 25 Feb 2006, Robert Sanderson wrote: > > If there's no requirement for persisence across time or applications, > then there's no just need for a URI. I disagree, URI doesn't say anything about persistece, it's just the standard way of identifying resource on the web. > > I just don't see any argument for why we NEED a URI rather than an > arbitrary identifier and a recommended best practice to use URIs when > appropriate? I think unapi is two part, an URI microformat, and a way of accessing the URI. In the spec, Dan mentioned: A URI microformat (note: this has not been endorsed by the microformats.org project) I think there is a strong case for URI microformat, and URI microformat can be used in wider scope than unapi, e.g. if amazon has isbn number in URI microformat (urn:isbn:0596007019), this alone can inspire many applications beyond unapi. While I cannot see a strong case of pushing "identifier" microformat, because "identifier" is vague and not well-defined. Anyhow, my point is that the problem is two part, the URI microformat and unapi. And URI microformat itself is interesting if we can make it happen. regards, xiaoming From daniel.chudnov at yale.edu Sun Feb 26 23:56:26 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Feb 26 23:57:08 2006 Subject: [gcs-pcs-list] OPA updated for rev1, available Message-ID: <9D9E961D-9029-4364-9B45-947B359888DE@yale.edu> OPA (OPA Proxies APIs), the unAPI demo app I showed last week at code4lib, has been updated for unAPI revision 1, and is available here: http://onebiglibrary.net/story/opa-release-0.1 It's not necessarily good software, but it's fun to play with, and it has been very helpful in clarifying a number of issues. Also, several people told me after the talk that they "got unAPI after [I] showed OPA." It's implemented in python in just a few hundred lines (would be half as long if it didn't need to generate xml :). It uses the amazon.py and flickr.py libraries to speak to the remote APIs of those services, and it can proxy any OAI-PMH service provider just by adding a few lines to the config file. The unAPI web interface (there's also a commandline interface) uses web.py. More details and examples at the link above. Alf: it would be cool to try to roll a configurable equivalent of the CiteProxy SRU fetch mechanism into this. More unAPI TODOs coming soon, too. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue Feb 28 20:17:36 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 28 20:17:40 2006 Subject: [gcs-pcs-list] on using URIs Message-ID: <20060301011736.GB6692@sildin.med.yale.edu> I'm surprised that opinions are all over the map here. URIs should be the least controversial aspect of this. :) Before I launch into this, I'll just say: I totally agree with Xiaoming's analysis and opinion. The case for URIs includes: - they are well-defined - they are well-accepted - all our languages know what they are - they refer to the same thing across applications - anybody knowledgeable enough to implement unAPI should be able to understand URIs - they imply some measure of identifier persistence - where objects might be copied around using unAPI there is probably already some sort of implication of object+id persistence - it encourages use of URIs - they're the reason the web works to begin with :) Fwiw, we're getting to the point where we should be weighing decisions more and more w/r/to implemented code. So, from the point of view of the projects for which I'm using unAPI... The case from OPA's perspective: - it is easy to map specific identifier patterns to specific webapps - without the standard URI prefix patterns, it might be impossible to efficiently assign a handler to a particular arbitrary identifier The case from unalog's perspective (I am working on adding unAPI copy out and paste in, and hope to have it demoable within a week): - having full URI patterns makes it easy to use a library like OPA to resolve ids - using full URIs makes it more likely that different pasted-in stuff can refer to the same thing consistently, e.g. if user1 writes about a book in a blog, user2 saves an amazon book link, and user3 saves an OPAC record for the book, unalog can collate all three around the URI (as opposed to randomly differing variants on ISBNs) - unalog itself referring to an object by its URI allows potentially better precision in service/content resolution, e.g. queries for object "12345" might return wildly different things with (unlike w/tagging) zero potential value to be derived from overlaps across disparate objects Another good reason to require URIs is that bridging other protocols (APP, OpenURL, OpenSearch/SRU) might be easier if implementers already have fully-specified URIs. As for the Evergreen blog post: Mike, I'd suggest that what you want there isn't some tag or other made-up URI for your internal record identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant for the item in your catalog (or an ISSN, etc.), unless an item in the catalog has no known public identifier already. There's a critical distinction to be made between content identifiers and package/datastream identifiers: - content identifiers represent publicly-known identifiers that are independent of system implementations. all systems dealing with the same content item would use the same content identifier. some examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, etc. these are probably at least "precious" or "normal", to use Xiaoming's formulation. - package and datastream identifiers represent specific-to-an- application identifiers that aren't necessarily public or known outside of the system itself. maybe they are, maybe they aren't. some examples would be unalog entry ids, flickr image file URLs, repository bitstream uuids, etc. (see the OAIS reference model for a better explication of same.) The key difference here is that content identifiers mean the same thing across people and application contexts, whereas package/datastream identifiers don't, necessarily. imho unAPI is all about content identifiers. Or, rather, you could use the other kinds of identifiers with it, but if it really takes off as an cross-application spec, it will be through the common use of content identifiers, most of which can be usefully rendered as URIs. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Tue Feb 28 22:09:54 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Feb 28 22:10:57 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <20060301011736.GB6692@sildin.med.yale.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: On 3/1/06, Daniel Chudnov wrote: [snip] > > As for the Evergreen blog post: Mike, I'd suggest that what you want > there isn't some tag or other made-up URI for your internal record > identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant > for the item in your catalog (or an ISSN, etc.), unless an item in the > catalog has no known public identifier already. > Agreed. Unfortunately, in our test data load (~1/4 of our bib data) only 42% of our MARC records have anything in the 02x fields. After that, our catalogers would have us fall back to local system number or OCLC accession number... so, you see my pickle. :P Also, that only works for bib records. Metarecords (and FRBR work-sets, and any other record grouping, AFAIK) don't have standardized identifier schemes. > There's a critical distinction to be made between content identifiers > and package/datastream identifiers: > > - content identifiers represent publicly-known identifiers that are > independent of system implementations. all systems dealing with > the same content item would use the same content identifier. some > examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers, > etc. these are probably at least "precious" or "normal", to use > Xiaoming's formulation. > > - package and datastream identifiers represent specific-to-an- > application identifiers that aren't necessarily public or known > outside of the system itself. maybe they are, maybe they aren't. > some examples would be unalog entry ids, flickr image file URLs, > repository bitstream uuids, etc. > > (see the OAIS reference model for a better explication of same.) > > The key difference here is that content identifiers mean the same > thing across people and application contexts, whereas package/datastream > identifiers don't, necessarily. > > imho unAPI is all about content identifiers. Or, rather, you could use > the other kinds of identifiers with it, but if it really takes off as > an cross-application spec, it will be through the common use of content > identifiers, most of which can be usefully rendered as URIs. Is this promoting an assumption of content equality across servers that identify local to each using identical content identifiers? If so, we're talking more about copy-by-ref, because it no longer matters where one gets their, er, copy of the item. We could look at unAPI as a simple discovery mechanism for each site's "open access" OpenURL resolver, combined with a relaxed/simpler CO scheme and a much shallower learning curve. That's not a bad thing, but I do see it as the logical end of focusing on content identifiers. > > -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 daniel.chudnov at yale.edu Tue Feb 28 22:57:09 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 28 22:57:10 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: References: <20060301011736.GB6692@sildin.med.yale.edu> Message-ID: <20060301035708.GC6692@sildin.med.yale.edu> Mike Rylander wrote, on Wed, Mar 01, 2006 at 03:09:54AM +0000: > On 3/1/06, Daniel Chudnov wrote: > > As for the Evergreen blog post: Mike, I'd suggest that what you want > > there isn't some tag or other made-up URI for your internal record > > identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant > > for the item in your catalog (or an ISSN, etc.), unless an item in the > > catalog has no known public identifier already. > > Agreed. Unfortunately, in our test data load (~1/4 of our bib data) > only 42% of our MARC records have anything in the 02x fields. After > that, our catalogers would have us fall back to local system number or > OCLC accession number... so, you see my pickle. :P Fair enough. But, even here you could drop in the pecking order from "most public" (ISBN) to "somewhat less public but still recognizable" (OCLC accession number) before going fully-local, right? I ain't saying it should catch all cases... just that whenever possible, using the most public content identifier is probably most useful across the most (admittedly still vapor) apps. But aside from that... even if it's not public, would not requiring a URI help things? Imho by even putting a fairly-local identifier into a URI structure you are namespacing it and making it more likely that the further it travels, the more possible it might be for others to find their way back to your system. > Also, that only works for bib records. Metarecords (and FRBR > work-sets, and any other record grouping, AFAIK) don't have > standardized identifier schemes. Do people care about metarecords? Will they? Either way, can't you still just assign an identifier to it? Here i'm pretty ignorant, I'm still in the late 1990s mode of "but FRBR is a set of requirements, not a system spec" and don't know anything about what a FRBR work-set is. > > imho unAPI is all about content identifiers. Or, rather, you could use > > the other kinds of identifiers with it, but if it really takes off as > > an cross-application spec, it will be through the common use of content > > identifiers, most of which can be usefully rendered as URIs. > > Is this promoting an assumption of content equality across servers > that identify local to each using identical content identifiers? Maybe it's just late, but I can't parse this sentence. I'm sorry, could you say this again? If it matters, I'm not assuming anything about content itself. I'm format-agnostic, and don't believe we can impose any "truth" of what an "original" or "correct" format for an object is. That's a hard enough problem without trying to address it in unAPI. We just want to be able to know if people are talking about the same thing (w/r/to identifiers). > If so, we're talking more about copy-by-ref, because it no longer > matters where one gets their, er, copy of the item. We could look at > unAPI as a simple discovery mechanism for each site's "open access" > OpenURL resolver, combined with a relaxed/simpler CO scheme and a much > shallower learning curve. That's not a bad thing, but I do see it as > the logical end of focusing on content identifiers. I didn't ever think it mattered where anybody gets their "copy" of an item. From a "primary source", from a friend, from an aggregator, from a republisher, from a blogger, from a library, from a linklog/objectlog... it's all good. Sorry, again, I'm not sure I understand the rest of this paragraph, or whether you're implying that that's less-than- or different-from- what-you-hoped-it-would-be. :) To repeat something I've said before, though, I don't want unAPI to be "OpenURL lite" or "APP lite" or any such thing... it's just the simplest way to get object disseminations out of a webapp so you can do stuff with 'em. As for existing specs, if we are good about making unAPI layer over them cleanly (Jeff has proven this for OpenURL, OPA proves it for OAI-PMH), then we're doing well. If people developing with unAPI realize they need something heavier-duty and then discover OpenURL or APP or OAI-PMH, that's great... it would be a huge success if unAPI merely served as a gateway drug of epidemic proportions. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Tue Feb 28 23:18:44 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue Feb 28 23:19:59 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <20060301035708.GC6692@sildin.med.yale.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> Message-ID: <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> I don't understand how URIs would work on something like a blog posting, honestly. Can you elaborate on that? -Ross. On Feb 28, 2006, at 10:57 PM, Daniel Chudnov wrote: > Mike Rylander wrote, on Wed, Mar 01, 2006 at 03:09:54AM +0000: >> On 3/1/06, Daniel Chudnov wrote: >>> As for the Evergreen blog post: Mike, I'd suggest that what you want >>> there isn't some tag or other made-up URI for your internal record >>> identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) >>> relevant >>> for the item in your catalog (or an ISSN, etc.), unless an item in >>> the >>> catalog has no known public identifier already. >> >> Agreed. Unfortunately, in our test data load (~1/4 of our bib data) >> only 42% of our MARC records have anything in the 02x fields. After >> that, our catalogers would have us fall back to local system number or >> OCLC accession number... so, you see my pickle. :P > > Fair enough. But, even here you could drop in the pecking order from > "most public" (ISBN) to "somewhat less public but still recognizable" > (OCLC accession number) before going fully-local, right? > > I ain't saying it should catch all cases... just that whenever > possible, > using the most public content identifier is probably most useful across > the most (admittedly still vapor) apps. > > But aside from that... even if it's not public, would not requiring a > URI help things? Imho by even putting a fairly-local identifier into > a URI structure you are namespacing it and making it more likely that > the further it travels, the more possible it might be for others to > find their way back to your system. > > >> Also, that only works for bib records. Metarecords (and FRBR >> work-sets, and any other record grouping, AFAIK) don't have >> standardized identifier schemes. > > Do people care about metarecords? Will they? Either way, can't you > still just assign an identifier to it? > > Here i'm pretty ignorant, I'm still in the late 1990s mode of "but FRBR > is a set of requirements, not a system spec" and don't know anything > about what a FRBR work-set is. > > >>> imho unAPI is all about content identifiers. Or, rather, you could >>> use >>> the other kinds of identifiers with it, but if it really takes off as >>> an cross-application spec, it will be through the common use of >>> content >>> identifiers, most of which can be usefully rendered as URIs. >> >> Is this promoting an assumption of content equality across servers >> that identify local to each using identical content identifiers? > > Maybe it's just late, but I can't parse this sentence. I'm sorry, > could > you say this again? > > If it matters, I'm not assuming anything about content itself. I'm > format-agnostic, and don't believe we can impose any "truth" of what an > "original" or "correct" format for an object is. That's a hard enough > problem without trying to address it in unAPI. We just want to be able > to know if people are talking about the same thing (w/r/to > identifiers). > > >> If so, we're talking more about copy-by-ref, because it no longer >> matters where one gets their, er, copy of the item. We could look at >> unAPI as a simple discovery mechanism for each site's "open access" >> OpenURL resolver, combined with a relaxed/simpler CO scheme and a much >> shallower learning curve. That's not a bad thing, but I do see it as >> the logical end of focusing on content identifiers. > > I didn't ever think it mattered where anybody gets their "copy" of an > item. From a "primary source", from a friend, from an aggregator, > from a > republisher, from a blogger, from a library, from a > linklog/objectlog... > it's all good. > > Sorry, again, I'm not sure I understand the rest of this paragraph, or > whether you're implying that that's less-than- or different-from- > what-you-hoped-it-would-be. :) > > To repeat something I've said before, though, I don't want unAPI to be > "OpenURL lite" or "APP lite" or any such thing... it's just the > simplest > way to get object disseminations out of a webapp so you can do stuff > with > 'em. As for existing specs, if we are good about making unAPI layer > over them cleanly (Jeff has proven this for OpenURL, OPA proves it > for OAI-PMH), then we're doing well. If people developing with unAPI > realize they need something heavier-duty and then discover OpenURL or > APP or OAI-PMH, that's great... it would be a huge success if unAPI > merely served as a gateway drug of epidemic proportions. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From daniel.chudnov at yale.edu Tue Feb 28 23:42:35 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue Feb 28 23:42:36 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> <1edaf10337ff1de9cd3c6a0f27f5b57a@library.gatech.edu> Message-ID: <20060301044235.GD6692@sildin.med.yale.edu> Ross Singer wrote, on Tue, Feb 28, 2006 at 11:18:44PM -0500: > I don't understand how URIs would work on something like a blog > posting, honestly. > > Can you elaborate on that? Peter's wordpress implementation is probably the best place to start w/r/to URIs for a blog posting: http://www.wallandbinkley.com/quaedam/?p=59 ...in which he says: "choose a URI prefix for your blog, e.g. oai:wallandbinkley.com:quaedam: (I?m using oai prefixes for compatibility with my Wordpress OAI-PMH plugin)." ...then indicates where to put the span[@class='unapi-uri']. I suppose you could also just use the URL for the entry itself. It seems likely that the (as-yet-vaporous) growth of APP and "Atom stores" will tend most popular blog packages to being a little bit smarter about what they mean by "permalinks" or URIs. As for URIs *within* a blog posting, something like an hReview for a book or article might contain DOIs or ISBNs or whatnot. It would take a little more code to get the hReview bundle out specifically for a given ISBN, say... but I think this is the kind of thing the Structured Blogging folks have been working on lately. The need for all of which is indicated by Peter... :) As for other microformats inside a blog posting but not necessarily associated with a URI, I'm not so sure. Maybe some sort of URI from the page URL and a fragment path/indicator... maybe just the microcontent bare next to the page URL, i've no idea yet what the right way would be. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From mrylander at gmail.com Tue Feb 28 23:56:37 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue Feb 28 23:57:40 2006 Subject: [gcs-pcs-list] on using URIs In-Reply-To: <20060301035708.GC6692@sildin.med.yale.edu> References: <20060301011736.GB6692@sildin.med.yale.edu> <20060301035708.GC6692@sildin.med.yale.edu> Message-ID: On 3/1/06, Daniel Chudnov wrote: > Mike Rylander wrote, on Wed, Mar 01, 2006 at 03:09:54AM +0000: > > On 3/1/06, Daniel Chudnov wrote: > > > As for the Evergreen blog post: Mike, I'd suggest that what you want > > > there isn't some tag or other made-up URI for your internal record > > > identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant > > > for the item in your catalog (or an ISSN, etc.), unless an item in the > > > catalog has no known public identifier already. > > > > Agreed. Unfortunately, in our test data load (~1/4 of our bib data) > > only 42% of our MARC records have anything in the 02x fields. After > > that, our catalogers would have us fall back to local system number or > > OCLC accession number... so, you see my pickle. :P > > Fair enough. But, even here you could drop in the pecking order from > "most public" (ISBN) to "somewhat less public but still recognizable" > (OCLC accession number) before going fully-local, right? Sure. I'll probably end up using the "best" for each record. > > I ain't saying it should catch all cases... just that whenever possible, > using the most public content identifier is probably most useful across > the most (admittedly still vapor) apps. > Understood. > But aside from that... even if it's not public, would not requiring a > URI help things? Imho by even putting a fairly-local identifier into > a URI structure you are namespacing it and making it more likely that > the further it travels, the more possible it might be for others to > find their way back to your system. > Absolutely! I'm in favor of URIs!!! Hence the (current, fake) info URIs, and the plan for tag URIs where I must use a local identifier. However, as you suggest, I'll go with the "most public" identifier when available. > > > Also, that only works for bib records. Metarecords (and FRBR > > work-sets, and any other record grouping, AFAIK) don't have > > standardized identifier schemes. > > Do people care about metarecords? Will they? Either way, can't you > still just assign an identifier to it? > Well, PINES does. And anyone that has used xISBN does (at least to some degree). Our metarecords simple elevate these groupings to an entity level with a group identifier, which is certainly the spirit, if not the letter, of FRBR. > Here i'm pretty ignorant, I'm still in the late 1990s mode of "but FRBR > is a set of requirements, not a system spec" and don't know anything > about what a FRBR work-set is. > It's simply a record grouping that uses an algorithm based on a MARC-centered interpretation of FRBR to map records (MODS in our case, MARC in the xISBN case) into ephemeral entities that exist as composites of the constituent records. > > > > imho unAPI is all about content identifiers. Or, rather, you could use > > > the other kinds of identifiers with it, but if it really takes off as > > > an cross-application spec, it will be through the common use of content > > > identifiers, most of which can be usefully rendered as URIs. > > > > Is this promoting an assumption of content equality across servers > > that identify local to each using identical content identifiers? > > Maybe it's just late, but I can't parse this sentence. I'm sorry, could > you say this again? Heh ... no, it made no sense. I left out an important word. ;) Is this promoting an assumption of (semantic; interpreted) content equality across servers that identify *items* local to each using identical content identifiers? IOW, two servers serve the URI "urn:isbn:123456789X"; do we assume that they point to the same item or serve the same content (assuming overlap in formats)? (Perhaps ISBN is the wrong identify to use in examples, what with its know issues regarding reuse ...) > > If it matters, I'm not assuming anything about content itself. I'm > format-agnostic, and don't believe we can impose any "truth" of what an > "original" or "correct" format for an object is. That's a hard enough > problem without trying to address it in unAPI. We just want to be able > to know if people are talking about the same thing (w/r/to identifiers). > Sure. Which means that users /should/ use the original unAPI server to retrieve objects, even if they've seen the same "thing" elsewhere, perhaps even in the same format. I would go as far as to write that explicitly into the unAPI spec (using standard RFC "SHOULD" or even "MUST" language). > > > If so, we're talking more about copy-by-ref, because it no longer > > matters where one gets their, er, copy of the item. We could look at > > unAPI as a simple discovery mechanism for each site's "open access" > > OpenURL resolver, combined with a relaxed/simpler CO scheme and a much > > shallower learning curve. That's not a bad thing, but I do see it as > > the logical end of focusing on content identifiers. > > I didn't ever think it mattered where anybody gets their "copy" of an > item. From a "primary source", from a friend, from an aggregator, from a > republisher, from a blogger, from a library, from a linklog/objectlog... > it's all good. > > Sorry, again, I'm not sure I understand the rest of this paragraph, or > whether you're implying that that's less-than- or different-from- > what-you-hoped-it-would-be. :) I think I've failed to get my point across. I'm not saying one source should be considered better than another, I was just making an observation about where I see "content" as opposed to "package" identifiers leading. If the content (value, not structure) of the URI is important (i.e., the spec says "try to use 'urn:isbn:123456789x' instead of 'tag:gapines.org:2006:record/12345'"), then why would someone with a Amazon greasemonkey script use the site-local unAPI server instead of the, arguably more prevalent/complete/well-know, Amazon webservice copy of the object? Not that I'm advocating any /particular/ URI scheme. And again, not a critique, just an observation. (See above re "SHOULD/MUST" :) ) > > To repeat something I've said before, though, I don't want unAPI to be > "OpenURL lite" or "APP lite" or any such thing... it's just the simplest > way to get object disseminations out of a webapp so you can do stuff with > 'em. As for existing specs, if we are good about making unAPI layer > over them cleanly (Jeff has proven this for OpenURL, OPA proves it > for OAI-PMH), then we're doing well. If people developing with unAPI > realize they need something heavier-duty and then discover OpenURL or > APP or OAI-PMH, that's great... it would be a huge success if unAPI > merely served as a gateway drug of epidemic proportions. > Right, that would be awesome. I think it's also a good sign that unAPI can be based on the same underlying infrastructure as OpenURL/OpenSearch/whatever (as in OpenILS/Evergreen), but with a /much/ lower implementation investment. I think it can stand on its own, right along side the heavier-duty protocols. Plus, with discovery built in, it's easier to actually use IMNSHO. > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org