From ross.singer at library.gatech.edu Mon May 1 09:08:31 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon May 1 09:10:08 2006 Subject: [gcs-pcs-list] validating unAPI URIs In-Reply-To: <6D40146E-2D71-4641-B10C-7C77967A0762@pobox.com> References: <6D40146E-2D71-4641-B10C-7C77967A0762@pobox.com> Message-ID: <23b83f160605010608s285f3bfai602e999211fb46b4@mail.gmail.com> Er, have we come to agreement on what a "unapi-uri" is? -Ross. On 4/30/06, Edward Summers wrote: > > Does anyone have an opinion about whether or not the unapi-validator > [1] should validate unapi-uris? > > > > For example, should it make sure XXX is a legitimate URI and throw a > suitable error/warning indicating the situation if it's not? Should > it be an error or a warning? > > //Ed > > [1] http://validator.unapi.info/ > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060501/bf78c93c/attachment.htm From ross.singer at library.gatech.edu Mon May 1 09:14:14 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon May 1 09:15:49 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501034128.GJ22732@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> Message-ID: <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> I personally prefer the docs attribute. I'm not sure how that conflicts with the model of preserving a reference to the original unAPI server? -Ross. On 4/30/06, Daniel Chudnov wrote: > > Daniel Chudnov wrote, on Sun, Apr 30, 2006 at 11:21:29PM -0400: > > After the recent rewrite-for-terseness Xiaoming pointed out that the > > ability to specify a reference to documentation for an object format > > disappeared. > > Shoot - I should have combined this issue with this other remaining one: > > "Add UNAPI?format=FORMAT for a descriptive document concerning > that format" > > They really address the same concern. Which is better? > > I *think* I prefer the docs attribute, as some systems (like unalog) > might simply pass through objects in formats unknown to the system itself. > > On the other hand, I argued earlier that systems like unalog should do > their best to preserve a reference to the original unAPI source server > URL and format name so downstream users can attempt to fetch the source > object for themselves. In that case, the same downstream users could > just as easily call SOURCE_UNAPI?format=FORMAT for themselves. > > So, now I don't know what I prefer, but the docs attribute is probably > simpler -- less for publishers to implement. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060501/c9565309/attachment.htm From daniel.chudnov at yale.edu Mon May 1 10:59:26 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 1 10:59:59 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> Message-ID: <20060501145925.GB20857@sildin.med.yale.edu> Ross Singer wrote, on Mon, May 01, 2006 at 09:14:14AM -0400: > I personally prefer the docs attribute. I'm not sure how that conflicts > with the model of preserving a reference to the original unAPI server? I think I do too. I worry a bit that if a general-purpose paste app like unalog presents an interface to unknown object formats, unalog itself might be expected to tell users more about those formats. So the scenario is: - random site A has interesting object urn:blah:1 in format Foo - user X copies A/UNAPI?uri=urn:blah:1&format=Foo into unalog - user Y sees that object in X's unalog stack and wants to know more about format Foo. So the question right then is: whose job is it to answer user Y's question about format Foo? You can't really expect unalog to know anything that it couldn't get from site A. To me, this is a case where it *might* be preferable to be able to ask: A/UNAPI?format=Foo Though the user/client might actually ask: UNALOG_SITE/UNAPI?format=Foo ...which might not be easy to resolve to an object that knows about Foo. Like, what if different objects in unalog say different things about format Foo? unalog would have to find them and then choose between them, maybe just using the most recent one or something simple like that. In the context of a specific object's format list, however, if the docs attribute is preserved from the source site, then unalog can just rebroadcast the docs value it got from the source site, which is most appropriate for that object anyway. So, I see value in UNAPI?format=FORMAT, but also think this is more complicated and thus not quite in the spirit of the spec. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Mon May 1 11:14:59 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 1 11:15:33 2006 Subject: [gcs-pcs-list] validating unAPI URIs In-Reply-To: <23b83f160605010608s285f3bfai602e999211fb46b4@mail.gmail.com> References: <6D40146E-2D71-4641-B10C-7C77967A0762@pobox.com> <23b83f160605010608s285f3bfai602e999211fb46b4@mail.gmail.com> Message-ID: <20060501151458.GC20857@sildin.med.yale.edu> Ross Singer wrote, on Mon, May 01, 2006 at 09:08:31AM -0400: > Er, have we come to agreement on what a "unapi-uri" is? [Fyi, possibly renaming that class is a remaining to-do... vote now on the active issue threads and we'll get to it sooner. :) ] The spec refers to "A URI Microformat". It isn't stated explicitly that "URI" implies RFC 3986. Maybe it should? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Mon May 1 11:34:18 2006 From: ehs at pobox.com (Edward Summers) Date: Mon May 1 11:35:24 2006 Subject: [gcs-pcs-list] validating unAPI URIs In-Reply-To: <20060501151458.GC20857@sildin.med.yale.edu> References: <6D40146E-2D71-4641-B10C-7C77967A0762@pobox.com> <23b83f160605010608s285f3bfai602e999211fb46b4@mail.gmail.com> <20060501151458.GC20857@sildin.med.yale.edu> Message-ID: <079CCD1D-6984-4775-8F35-8D72E0912375@pobox.com> On May 1, 2006, at 10:14 AM, Daniel Chudnov wrote: > The spec refers to "A URI Microformat". It isn't stated explicitly > that "URI" implies RFC 3986. Maybe it should? +1 I imagine most web developers know that the URI is deep www-magic documented in an RFC somewhere. But referencing RFC 3986 directly in the unAPI spec would be a good thing I think. //Ed From liu_x at lanl.gov Mon May 1 11:36:07 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon May 1 11:37:02 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501145925.GB20857@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> Message-ID: On Mon, 1 May 2006, Daniel Chudnov wrote: > > ...which might not be easy to resolve to an object that knows about Foo. > Like, what if different objects in unalog say different things about > format Foo? unalog would have to find them and then choose between them, We may hope that in future a pattern will occur in most frequently used formats. Maybe it's useful to setup a wiki to facilitate good practices, and various chosen formats can be roughly registered and explained? > maybe just using the most recent one or something simple like that. > In the context of a specific object's format list, however, if the > docs attribute is preserved from the source site, then unalog can just > rebroadcast the docs value it got from the source site, which is most > appropriate for that object anyway. > > So, I see value in UNAPI?format=FORMAT, but also think this is more > complicated and thus not quite in the spirit of the spec. > agree, I also prefer an optional "docs" attribute. regards, xiaoming From leftwing at alumni.rutgers.edu Mon May 1 11:40:05 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Mon May 1 11:41:29 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> Message-ID: <6.0.1.1.2.20060501083922.03ec1700@pop.gmail.com> At 08:36 PT, 05/01/2006, Xiaoming Liu wrote: > >agree, I also prefer an optional "docs" attribute. > +1 (both to the docs attr and its optionality) From daniel.chudnov at yale.edu Mon May 1 11:46:29 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 1 11:47:01 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> Message-ID: <20060501154626.GD20857@sildin.med.yale.edu> Xiaoming Liu wrote, on Mon, May 01, 2006 at 09:36:07AM -0600: > On Mon, 1 May 2006, Daniel Chudnov wrote: > >...which might not be easy to resolve to an object that knows about Foo. > >Like, what if different objects in unalog say different things about > >format Foo? unalog would have to find them and then choose between them, > > We may hope that in future a pattern will occur in most frequently used > formats. Maybe it's useful to setup a wiki to facilitate good > practices, and various chosen formats can be roughly registered and > explained? Sounds like a good idea. Would you (or somebody else) like to take lead on it? We can work out the hosting details off-list. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Mon May 1 12:07:16 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon May 1 12:08:52 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501145925.GB20857@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> Message-ID: <23b83f160605010907hc8c003fhb1930758fccfcb57@mail.gmail.com> Dan, You raise a handful of issues with this one. 1) We still have the unresolved uri vs. identifier debate We could possibly steer around this problem with some sort of registry and the use of prefixes on the unapi-uri "uri" -- so for my opac unapi install, I could use: gil.gatech.edu:Voyager/10643 (or whatever, switch the colon and the slash around, if need be). Unalog can then ask, say, some sort of registry about the uri prefix to try to find the original item --however-- 2) This implies persistence -- which is another issue we've punted on in the past. I think it's important to stress that any of expectation of persistence /could be met with abject failure and mockery/. Still, this is an important issue. -Ross. On 5/1/06, Daniel Chudnov wrote: > > Ross Singer wrote, on Mon, May 01, 2006 at 09:14:14AM -0400: > > I personally prefer the docs attribute. I'm not sure how that conflicts > > with the model of preserving a reference to the original unAPI server? > > I think I do too. > > I worry a bit that if a general-purpose paste app like unalog presents > an interface to unknown object formats, unalog itself might be expected > to tell users more about those formats. So the scenario is: > > - random site A has interesting object urn:blah:1 in format Foo > - user X copies A/UNAPI?uri=urn:blah:1&format=Foo into unalog > - user Y sees that object in X's unalog stack and wants to know > more about format Foo. > > So the question right then is: whose job is it to answer user Y's question > about format Foo? You can't really expect unalog to know anything that > it couldn't get from site A. To me, this is a case where it *might* be > preferable to be able to ask: > > A/UNAPI?format=Foo > > Though the user/client might actually ask: > > UNALOG_SITE/UNAPI?format=Foo > > ...which might not be easy to resolve to an object that knows about Foo. > Like, what if different objects in unalog say different things about > format Foo? unalog would have to find them and then choose between them, > maybe just using the most recent one or something simple like that. > In the context of a specific object's format list, however, if the > docs attribute is preserved from the source site, then unalog can just > rebroadcast the docs value it got from the source site, which is most > appropriate for that object anyway. > > So, I see value in UNAPI?format=FORMAT, but also think this is more > complicated and thus not quite in the spirit of the spec. > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060501/9e55bfd6/attachment.htm From daniel.chudnov at yale.edu Mon May 1 12:27:52 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 1 12:28:25 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <23b83f160605010907hc8c003fhb1930758fccfcb57@mail.gmail.com> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> <23b83f160605010907hc8c003fhb1930758fccfcb57@mail.gmail.com> Message-ID: <20060501162751.GF20857@sildin.med.yale.edu> Before we spin out of control on identifiers... this thread is about the "docs" attribute issue. Let's close on that first, with a plan for identifier discussion below. Ross Singer wrote, on Mon, May 01, 2006 at 12:07:16PM -0400: > > 1) We still have the unresolved uri vs. identifier debate Fwiw, the recent rewrite essentially resolved this, if in a heavy-handed manner: "Should we allow "bare" identifiers, i.e., without fully-specified uri context prefix No." http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-April/000742.html I'll admit that that was a snarky way to handle this problem given its history here, on uf-discuss, and everywhere else. There were no outright objections to that part of that message at that time, though. Of course we should still discuss this, ideally in the context of the remaining "rename the class value?" issue, but if we can just close on the other issues first (it need not take more than 24 hours if a few more people will vote!) we can have this as a final discussion. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Mon May 1 12:33:32 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon May 1 12:34:22 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501154626.GD20857@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> <20060501154626.GD20857@sildin.med.yale.edu> Message-ID: On Mon, 1 May 2006, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Mon, May 01, 2006 at 09:36:07AM -0600: >> On Mon, 1 May 2006, Daniel Chudnov wrote: >>> ...which might not be easy to resolve to an object that knows about Foo. >>> Like, what if different objects in unalog say different things about >>> format Foo? unalog would have to find them and then choose between them, >> >> We may hope that in future a pattern will occur in most frequently used >> formats. Maybe it's useful to setup a wiki to facilitate good >> practices, and various chosen formats can be roughly registered and >> explained? > > Sounds like a good idea. Would you (or somebody else) like to take > lead on it? We can work out the hosting details off-list. I think this concurs to a more general wiki for unAPI, and formats best-practice can be part of it? I would be glad to work on it, but preferably with someone with better knowledge of wiki admin. xiaoming > > -Dan > > > From liu_x at lanl.gov Tue May 2 00:58:29 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 2 00:59:17 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: > Using class="unapi-uri" seems to make the markup less re-usable. > Perhaps either "uri unapi", so anything else looking for class="uri" > can use it, or drop the "unapi" altogether. Not intend to further complicate the issue, but after reading more about microformats (especially uid vs. uri discussion), I am starting to appreciate Alf's proposal above. Maybe we are trying to achieve two objectives in one go: (1) a uri microformats, which is applicable to a wider scope. (2) a simple API to copy disseminations of an object, which we are trying to define here. In microformats, these may be best expressed by two classes: "uri" and "unapi", and the combination of two classes is encouraged [1]. So maybe it's a good compromise to focus on the "unapi" part in this spec, and if indeed Microformats.org accepts a "uri" class, it can be combined with "unapi" without extra efforts. To put it concrete, I would propose a variation of Alf's original idea: -- in unAPI, the only defined class is "unapi", such as ISBN 123456789X Whatever in the "title" can be issued against UNAPI?id=xxx, and an application should always look for "unapi" class. -- "unapi" and "uri" can be combined This would be a perfect case and will be trivial if Microformats indeed accepts "uri", such as: ISBN 123456789X even without Microformats's endorsement, nothing prevents using "uri" class, which I think is a good practice anyhow. -- "uri" can be used seperately ISBN 123456789X So a site may not support unAPI, but it still uses "uri" class for interoperability. While this is a step back from some my previous thinking, I feel it is more technical sound and follows Microformats's design. In retrospection I think this is also part of Rob and Mike's original concern? xiaoming From ross.singer at library.gatech.edu Tue May 2 09:34:17 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue May 2 09:35:55 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: <23b83f160605020634k194fcdc5re44f4490d3a46cbc@mail.gmail.com> +1 (I'm not sure where place this inline) Of course, my concerns regarding this were alleviated yesterday when Dan told me that tag uris were ok in this context. -Ross. On 5/2/06, Xiaoming Liu wrote: > > Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: > > > Using class="unapi-uri" seems to make the markup less re-usable. > > Perhaps either "uri unapi", so anything else looking for class="uri" > > can use it, or drop the "unapi" altogether. > > Not intend to further complicate the issue, but after reading more about > microformats (especially uid vs. uri discussion), I am starting to > appreciate Alf's proposal above. > > Maybe we are trying to achieve two objectives in one go: > (1) a uri microformats, which is applicable to a wider scope. > (2) a simple API to copy disseminations of an object, which we are trying > to define here. > > In microformats, these may be best expressed by two classes: "uri" and > "unapi", and the combination of two classes is encouraged [1]. So maybe > it's a good compromise to focus on the "unapi" part in this spec, and if > indeed Microformats.org accepts a "uri" class, it can be combined with > "unapi" without extra efforts. > > To put it concrete, I would propose a variation of Alf's original idea: > > -- in unAPI, the only defined class is "unapi", such as > ISBN 123456789X > > Whatever in the "title" can be issued against UNAPI?id=xxx, and an > application should always look for "unapi" class. > > -- "unapi" and "uri" can be combined > > This would be a perfect case and will be trivial if Microformats > indeed accepts "uri", such as: > ISBN 123456789X > > even without Microformats's endorsement, nothing prevents using "uri" > class, which I think is a good practice anyhow. > > -- "uri" can be used seperately > > ISBN 123456789X > > So a site may not support unAPI, but it still uses "uri" class for > interoperability. > > While this is a step back from some my previous thinking, I feel it is > more technical sound and follows Microformats's design. In retrospection I > think this is also part of Rob and Mike's original concern? > > xiaoming > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060502/2443d825/attachment-0001.htm From daniel.chudnov at yale.edu Tue May 2 09:58:53 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 2 10:00:06 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: On May 2, 2006, at 12:58 AM, Xiaoming Liu wrote: > Alf Eaton wrote, on Wed, Apr 05, 2006 at 09:16:30AM -0400: > > Maybe we are trying to achieve two objectives in one go: > (1) a uri microformats, which is applicable to a wider scope. > (2) a simple API to copy disseminations of an object, which we are > trying to define here. Yes, those have always been the objectives. (1) is why I first asked about an identifier microformat on uf-discuss last fall... it would be better if we didn't have to define it ourselves. > In microformats, these may be best expressed by two classes: "uri" > and "unapi", and the combination of two classes is encouraged [1]. > So maybe it's a good compromise to focus on the "unapi" part in > this spec, and if indeed Microformats.org accepts a "uri" class, it > can be combined with "unapi" without extra efforts. > To put it concrete, I would propose a variation of Alf's original > idea: > > -- in unAPI, the only defined class is "unapi", such as > -- "unapi" and "uri" can be combined > -- "uri" can be used seperately I'll go along with any variation of this if enough people support it. But - what does the "unapi" class mean in this case? That "this server can give you the object identified by the value inside @title via unapi"? And - what is the expectation of a unapi server for an object it publishes with class="uri" (without the 'unapi')? Should there be any expectation at all? Ultimately, my concerns are the same: - The spec must be relentlessly short and simple - It must be easy to understand - It must be easy to implement It's not clear to me what the model you suggest would mean w/r/to specific changes to the spec. Would you support, say: - Change "An URI microformat" to "A unAPI microformat" - Change param name from "uri" to "id" - Add an informative suggestion to add class="uri" if ids are URIs? If the class name is "unapi" it might seem weird to use the param name "id". -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Tue May 2 10:21:32 2006 From: lists at hubmed.org (Alf Eaton) Date: Tue May 2 10:25:29 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: On 02 May 2006, at 09:58, Daniel Chudnov wrote: > On May 2, 2006, at 12:58 AM, Xiaoming Liu wrote: > > >> In microformats, these may be best expressed by two classes: "uri" >> and "unapi", and the combination of two classes is encouraged [1]. >> So maybe it's a good compromise to focus on the "unapi" part in >> this spec, and if indeed Microformats.org accepts a "uri" class, >> it can be combined with "unapi" without extra efforts. > >> To put it concrete, I would propose a variation of Alf's original >> idea: >> >> -- in unAPI, the only defined class is "unapi", such as >> -- "unapi" and "uri" can be combined >> -- "uri" can be used seperately > > I'll go along with any variation of this if enough people support it. > > But - what does the "unapi" class mean in this case? That "this > server can give you the object identified by the value inside > @title via unapi"? I think that is what it means, so having the "unapi" there would only be useful in cases where there are multiple items with class="uri" on the page and only some of them are able to be provided by the unapi server linked at the head of the page. Is that likely? alf. From liu_x at lanl.gov Tue May 2 10:59:18 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 2 11:00:12 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: On Tue, 2 May 2006, Daniel Chudnov wrote: > On May 2, 2006, at 12:58 AM, Xiaoming Liu wrote: > > >> In microformats, these may be best expressed by two classes: "uri" and >> "unapi", and the combination of two classes is encouraged [1]. So maybe >> it's a good compromise to focus on the "unapi" part in this spec, and if >> indeed Microformats.org accepts a "uri" class, it can be combined with >> "unapi" without extra efforts. > >> To put it concrete, I would propose a variation of Alf's original idea: >> >> -- in unAPI, the only defined class is "unapi", such as >> -- "unapi" and "uri" can be combined >> -- "uri" can be used seperately > > I'll go along with any variation of this if enough people support it. > > But - what does the "unapi" class mean in this case? That "this server can > give you the object identified by the value inside @title via unapi"? I think so, it doesn't carry extra meaning, the only semantic is that you can issue a request to UNAPI baseURL and expect some results back. There might be some better description here. > > And - what is the expectation of a unapi server for an object it publishes > with class="uri" (without the 'unapi')? Should there be any expectation at > all? Perhaps no expectation. Maybe this can be demonstrated by a citation example, an unAPI server may offer an unAPI service to an article, but not necessarily all references of this article, but it still can use "uri" class for recognized references. So in article level, you may have class ="uri unapi", and in reference level, only class = "uri" is used. > > Ultimately, my concerns are the same: > > - The spec must be relentlessly short and simple > - It must be easy to understand > - It must be easy to implement > > It's not clear to me what the model you suggest would mean w/r/to specific > changes to the spec. Would you support, say: > > - Change "An URI microformat" to "A unAPI microformat" yes. > - Change param name from "uri" to "id" Perhaps we should just re-use "unapi", as you implied later? "id" is indeed confusing because we are not even talk about "identifier" here. > - Add an informative suggestion to add class="uri" if ids are URIs? I don't have a strong opinion on this. If a "uri" microformats is established, I hope people starts to mark-up "uri" whenever possible, not just for unapi services. regards, xiaoming > > If the class name is "unapi" it might seem weird to use the param name "id". > From ehs at pobox.com Tue May 2 11:29:02 2006 From: ehs at pobox.com (Edward Summers) Date: Tue May 2 11:30:14 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: <5049D0AA-7517-4EEC-8C4E-3D96C996A751@pobox.com> On May 2, 2006, at 9:59 AM, Xiaoming Liu wrote: > I don't have a strong opinion on this. If a "uri" microformats is > established, I hope people starts to mark-up "uri" whenever > possible, not just for unapi services. fwiw, I don't see the microformats people going with 'uri' anytime soon. If I had to bet I would say it was going to be 'uid' given the hCard and hCalendar backstory. //Ed From liu_x at lanl.gov Tue May 2 12:06:47 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 2 12:07:43 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <5049D0AA-7517-4EEC-8C4E-3D96C996A751@pobox.com> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <5049D0AA-7517-4EEC-8C4E-3D96C996A751@pobox.com> Message-ID: On Tue, 2 May 2006, Edward Summers wrote: > > On May 2, 2006, at 9:59 AM, Xiaoming Liu wrote: >> I don't have a strong opinion on this. If a "uri" microformats is >> established, I hope people starts to mark-up "uri" whenever possible, not >> just for unapi services. > > fwiw, I don't see the microformats people going with 'uri' anytime soon. If I > had to bet I would say it was going to be 'uid' given the hCard and hCalendar > backstory. If 'uid' is chosen maybe class="unapi uid" can be used when appropriate, I think this is a benefit of seperating unapi from 'uri uid' discussion. If unapi becomes standalone it can be easily mixed with other sensible markup. thanks, xiaoming From daniel.chudnov at yale.edu Tue May 2 12:31:11 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 2 12:31:44 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> Message-ID: <20060502163110.GA25858@sildin.med.yale.edu> Xiaoming Liu wrote, on Tue, May 02, 2006 at 08:59:18AM -0600: > On Tue, 2 May 2006, Daniel Chudnov wrote: > >- Change param name from "uri" to "id" > > Perhaps we should just re-use "unapi", as you implied later? "id" is > indeed confusing because we are not even talk about "identifier" here. I see your point, but, this is awkward: UNAPI?unapi=foo Don't you think? After all, it's the name of the spec/convention, not really a descriptor. I don't have a better answer. The best alternative I can come up with off the top of my head is to rename unAPI to "getobj", call the class "getobj", and call the parameter "obj", e.g.: GETOBJ?obj=foo But I don't particularly like that. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue May 2 12:43:58 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 2 12:44:30 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060502163110.GA25858@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> Message-ID: <20060502164357.GB25858@sildin.med.yale.edu> Daniel Chudnov wrote, on Tue, May 02, 2006 at 12:31:11PM -0400: > Xiaoming Liu wrote, on Tue, May 02, 2006 at 08:59:18AM -0600: > > On Tue, 2 May 2006, Daniel Chudnov wrote: > > >- Change param name from "uri" to "id" > > > > Perhaps we should just re-use "unapi", as you implied later? "id" is > > indeed confusing because we are not even talk about "identifier" here. The more I think about it, the more I like "just class='uri'". If the uid microformat moves forward, then people wanting both can choose class='uri uid'. There's nothing wrong with a unAPI service being hit with URIs it has to 404. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Tue May 2 12:45:23 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 2 12:45:56 2006 Subject: [gcs-pcs-list] Re: unAPI issue: add back "docs" attr In-Reply-To: <20060501162751.GF20857@sildin.med.yale.edu> References: <20060501032129.GI22732@sildin.med.yale.edu> <20060501034128.GJ22732@sildin.med.yale.edu> <23b83f160605010614u16ba0bb4t4b08d3804132c31a@mail.gmail.com> <20060501145925.GB20857@sildin.med.yale.edu> <23b83f160605010907hc8c003fhb1930758fccfcb57@mail.gmail.com> <20060501162751.GF20857@sildin.med.yale.edu> Message-ID: <20060502164522.GC25858@sildin.med.yale.edu> Daniel Chudnov wrote, on Mon, May 01, 2006 at 12:27:52PM -0400: > Before we spin out of control on identifiers... this thread is about > the "docs" attribute issue. Let's close on that first Having heard several +1s, and no dissent, let's call it closed: we add back an optional "docs" attribute. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Tue May 2 12:46:31 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 2 12:47:21 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060502163110.GA25858@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> Message-ID: On Tue, 2 May 2006, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Tue, May 02, 2006 at 08:59:18AM -0600: >> On Tue, 2 May 2006, Daniel Chudnov wrote: >>> - Change param name from "uri" to "id" >> >> Perhaps we should just re-use "unapi", as you implied later? "id" is >> indeed confusing because we are not even talk about "identifier" here. > > I see your point, but, this is awkward: > > UNAPI?unapi=foo > > Don't you think? After all, it's the name of the spec/convention, > not really a descriptor. > > I don't have a better answer. The best alternative I can come up with > off the top of my head is to rename unAPI to "getobj", call the class > "getobj", and call the parameter "obj", e.g.: > > GETOBJ?obj=foo > > But I don't particularly like that. Notice UNAPI is just a virtual name in the request (to be replaced by real URL), I don't think you need to rename unAPI, but "obj" seems more meaningful. so you will have: http://opa.onebiglibrary.net/?obj=foo does this sound better? xiaoming From daniel.chudnov at yale.edu Tue May 2 12:56:22 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 2 12:56:56 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? Message-ID: <20060502165622.GD25858@sildin.med.yale.edu> It was suggested offline to consider changing the value of the unAPI LINK element's rel attribute from "meta" to something more specific like "unapi.server", e.g.: I'm not sure what the right thing or best practice w/r/to rel types not in the HTML spec is. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Tue May 2 14:45:38 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 2 14:46:26 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060502164357.GB25858@sildin.med.yale.edu> References: <20060405070139.GA14541@sildin.med.yale.edu> <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060502164357.GB25858@sildin.med.yale.edu> Message-ID: On Tue, 2 May 2006, Daniel Chudnov wrote: > Daniel Chudnov wrote, on Tue, May 02, 2006 at 12:31:11PM -0400: > > The more I think about it, the more I like "just class='uri'". > > If the uid microformat moves forward, then people wanting both can > choose class='uri uid'. > > There's nothing wrong with a unAPI service being hit with URIs it > has to 404. > IMHO, either approach (class='uri' or class='unapi') is better than "unapi-uri", I am glad this discussion finally makes clear what the differences are. So the problem becomes which message we really want to convey: (1) a narrowly defined unAPI which hopefully works well with future "uid uri or else" microformats, or, (2) a self-complete specification with a strong emphasis on uri. regards, xiaoming From leftwing at alumni.rutgers.edu Tue May 2 16:20:32 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Tue May 2 16:22:08 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <20060502165622.GD25858@sildin.med.yale.edu> References: <20060502165622.GD25858@sildin.med.yale.edu> Message-ID: <22dbc4ae0605021320g3c26e952ic1b366391878d0be@mail.gmail.com> On 5/2/06, Daniel Chudnov wrote: > > It was suggested offline to consider changing the value of the unAPI > LINK element's rel attribute from "meta" to something more specific like > "unapi.server", e.g.: > > > > I'm not sure what the right thing or best practice w/r/to rel types not > in the HTML spec is. Me neither, and the closest I can find is the microformats FAQ: http://microformats.org/wiki/rel-faq At any rate, I rather like the more explanatory "unapi.server". It seems to fit the purpose of link @rel as stated in the FAQ. Additionally, " unapi.server" is less likely to conflict with other link @rel values (a risk mentioned in Microformats in Context[1]). +1 (though am not wedded to the value being "unapi.server") -Mike 1. http://www.xml.com/pub/a/2006/04/26/microformats-grddl-rdfa-nvdl.html?page=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060502/90163a0f/attachment.htm From daniel.chudnov at yale.edu Wed May 3 11:27:47 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed May 3 11:28:23 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060502164357.GB25858@sildin.med.yale.edu> Message-ID: <20060503152746.GC26675@sildin.med.yale.edu> Xiaoming Liu wrote, on Tue, May 02, 2006 at 12:45:38PM -0600: > >Daniel Chudnov wrote, on Tue, May 02, 2006 at 12:31:11PM -0400: > > > >The more I think about it, the more I like "just class='uri'". > > > >If the uid microformat moves forward, then people wanting both can > >choose class='uri uid'. > > > >There's nothing wrong with a unAPI service being hit with URIs it > >has to 404. > > IMHO, either approach (class='uri' or class='unapi') is better than > "unapi-uri", I am glad this discussion finally makes clear what the > differences are. So the problem becomes which message we really want to > convey: (1) a narrowly defined unAPI which hopefully works well with > future "uid uri or else" microformats, or, (2) a self-complete > specification with a strong emphasis on uri. (1) is overwhelmingly better. But, there just isn't an extant microformat to lean on yet, so we have to define it ourselves for now, right? I was hoping that the "allow bare identifiers" crowd would speak up again now. Please make your case! You're almost out of time. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From azaroth at liverpool.ac.uk Wed May 3 13:26:48 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Wed May 3 12:30:42 2006 Subject: [gcs-pcs-list] Identifiers Message-ID: <1146677208.2817.80.camel@helmsdeep> My opinion on identifiers vs URIs hasn't changed, please see previous lengthy discussion on it. I mean really... what are you going to do if you get something you recognise as an identifier that doesn't happen to be in the form of a URI... reject it because the specification says URI only? No software on the client end is going to validate for URIness, they'll just pass it through. So for all intents and purposes, URI-ness is unenforcable anyway and if I have to implement unAPI, you can be certain that I'll just put in my internal identifier without the meaningless tag:// prefix. At no point does URI-ness or lack thereof actually matter. It's just an opaque character string that uniquely identifies an object to be returned. If it happens to be globally unique, infinitely persistent identifier, then congratulations. But until we can start handing out ISSNs to blogs, this is going to be the trivial minority of cases. In the mean time, the rest of the world has OAI, SRU, OpenSearch and OpenURL which exist, can perform exactly the same actions as unapi, and don't require URIs for identifiers. Yet the 'braindead simple' spec requires them needlessly. YMWTFV. 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 May 3 13:35:23 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed May 3 13:35:55 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: <1146677208.2817.80.camel@helmsdeep> References: <1146677208.2817.80.camel@helmsdeep> Message-ID: <20060503173522.GD26675@sildin.med.yale.edu> Rob Sanderson wrote, on Wed, May 03, 2006 at 05:26:48PM +0000: > > No software on the client end is going to validate for URIness, they'll > just pass it through. So for all intents and purposes, URI-ness is > unenforcable anyway and if I have to implement unAPI, you can be certain > that I'll just put in my internal identifier without the meaningless > tag:// prefix. What specific change would you propose? Should we just use class='uid'? And maybe add an informative recommendation to "considering using a persistent URI structure, ideally accessible as http URLs?" -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Wed May 3 14:21:30 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed May 3 14:22:02 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> Message-ID: <20060503182129.GE26675@sildin.med.yale.edu> Xiaoming Liu wrote, on Tue, May 02, 2006 at 10:46:31AM -0600: > Notice UNAPI is just a virtual name in the request (to be replaced by > real URL), I don't think you need to rename unAPI, but "obj" seems more > meaningful. so you will have: > > http://opa.onebiglibrary.net/?obj=foo > > does this sound better? Ultimately, the param value has to be some sort of identifier, right? The class name and the param name should be the same thing. I concede Rob's point that saying "to implement unAPI you must first define and implement a URI-based identifier persistence strategy" contradicts the notion of "simple to implement". If enough people wanted to drop the URI requirement I'd be happy to go along with just using "class='uid'" and UNAPI?uid=foo. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Wed May 3 14:28:18 2006 From: eric at openly.com (Eric Hellman) Date: Wed May 3 14:30:07 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: <1146677208.2817.80.camel@helmsdeep> References: <1146677208.2817.80.camel@helmsdeep> Message-ID: It's always much easier to frame a question like this in terms of code. Consider: if the spec says that it's a uri, then what ought a client to do with the encoded ~ and the fragment? My interpretation of the present spec would be to ask for (note encoding) http://example.com/unapi/?uri=http%3A%2F%2Fwww.example.com%2F%7Eeric%233 and keep the fragment around in case I get back something where a fragment id makes sense. If the spec were to say that the title attribute is an opaque identifier, I would ask for http://example.com/unapi/?uri=http%3A%2F%2Fwww.example.com%2F%257Eeric%233 because nothing gives me any guidance on how to determine equivalence Obviously, this is a case where the URI-ness matters in code. Eric >My opinion on identifiers vs URIs hasn't changed, please see previous >lengthy discussion on it. > >I mean really... what are you going to do if you get something you >recognise as an identifier that doesn't happen to be in the form of a >URI... reject it because the specification says URI only? > >No software on the client end is going to validate for URIness, they'll >just pass it through. So for all intents and purposes, URI-ness is >unenforcable anyway and if I have to implement unAPI, you can be certain >that I'll just put in my internal identifier without the meaningless >tag:// prefix. > >At no point does URI-ness or lack thereof actually matter. It's just an >opaque character string that uniquely identifies an object to be >returned. If it happens to be globally unique, infinitely persistent >identifier, then congratulations. But until we can start handing out >ISSNs to blogs, this is going to be the trivial minority of cases. > >In the mean time, the rest of the world has OAI, SRU, OpenSearch and >OpenURL which exist, can perform exactly the same actions as unapi, and >don't require URIs for identifiers. Yet the 'braindead simple' spec >requires them needlessly. > >YMWTFV. > >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 -- 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 azaroth at liverpool.ac.uk Wed May 3 14:52:37 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed May 3 14:56:21 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: References: <1146677208.2817.80.camel@helmsdeep> Message-ID: Dan wrote: > What specific change would you propose? > Should we just use class='uid'? > And maybe add an informative recommendation to "considering using a > persistent URI structure, ideally accessible as http URLs?" Call it an 'identifier', and put in a recommendation that the following are desirable but not mandatory properties of identifiers: * Persistence over time * Global uniqueness * URI-ness The only mandatory property is that the server must be able to resolve the string to an object it can return, or fault the request. eg UNAPI?identifier=rob-house-pic-1&format=jpg Eric wrote: >It's always much easier to frame a question like this in terms of code. > >if the spec says that it's a uri, then what ought a client to do with >the encoded ~ and the fragment? Re-re-encode them? I don't think that many people would want to give out identifiers that expect to be parsed to determine which parts should be URL encoded and which parts shouldn't. Most libraries that I know simply take a string and URL encode it via some fast and stupid algorithm, rather than trying to parse out that some of it is already encoded and some isn't. >My interpretation of the present spec would be to ask for (note encoding) >http://example.com/unapi/?uri=http%3A%2F%2Fwww.example.com%2F%7Eeric%233 >If the spec were to say that the title attribute is an opaque >identifier, I would ask for [...] Here reason number 1 why passing URIs in a URL is something which isn't to be taken lightly. They are NOT purely opaque identifiers and to implement things *properly* there are these annoyances that everyone will run into. Or some people who are aware of them will run into, find that most other implementations don't do it properly, sigh, and then 'fix' their own client/server to go along with the majority. In my opinion, it should be an opaque identifier to avoid this. If it happens to be also be a URI, then great. >Obviously, this is a case where the URI-ness matters in code. And is a very good argument against URIs, in my sometimes humble opinion. :) Rob From liu_x at lanl.gov Wed May 3 16:04:12 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed May 3 16:05:00 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: References: <1146677208.2817.80.camel@helmsdeep> Message-ID: On Wed, 3 May 2006, Robert Sanderson wrote: > > Dan wrote: > >> What specific change would you propose? >> Should we just use class='uid'? >> And maybe add an informative recommendation to "considering using a >> persistent URI structure, ideally accessible as http URLs?" If 'uid' here is re-using uid concept in microformats, I am afraid this won't work because 'uid' in microformats is defined as global unique identifier (at least for now). I think we need to try avoid namespace conflicts, otherwise there will be problems when unAPI/hcard/hcalendar co-exists in same page. > > Call it an 'identifier', This shall be something specific to unapi. Again for the reason of namespace conflicts in microformats. I agree its semantic is really: "The only mandatory property is that the server must be able to resolve the string to an object it can return, or fault the request." > and put in a recommendation that the following > are desirable but not mandatory properties of identifiers: > > * Persistence over time > * Global uniqueness > * URI-ness As discussed earlier, if it's a "uri" or "uid", I think it shall be marked as such in XHTML page, only this way it can be of useful to other purposes. So IMHO the informative parts should suggest additional markup if it fits well with other microformats specification. regards, xiaoming From azaroth at liverpool.ac.uk Wed May 3 16:09:25 2006 From: azaroth at liverpool.ac.uk (Robert Sanderson) Date: Wed May 3 16:14:10 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: References: <1146677208.2817.80.camel@helmsdeep> Message-ID: On Wed, 3 May 2006, Xiaoming Liu wrote: >As discussed earlier, if it's a "uri" or "uid", I think it shall be marked >as such in XHTML page, only this way it can be of useful to other >purposes. >So IMHO the informative parts should suggest additional markup if it fits >well with other microformats specification. Agreed! Rob From liu_x at lanl.gov Wed May 3 16:16:15 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed May 3 16:17:04 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060503182129.GE26675@sildin.med.yale.edu> References: <20060405195628.GF15372@sildin.med.yale.edu> <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> Message-ID: On Wed, 3 May 2006, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Tue, May 02, 2006 at 10:46:31AM -0600: >> Notice UNAPI is just a virtual name in the request (to be replaced by >> real URL), I don't think you need to rename unAPI, but "obj" seems more >> meaningful. so you will have: >> >> http://opa.onebiglibrary.net/?obj=foo >> >> does this sound better? > > Ultimately, the param value has to be some sort of identifier, right? > The class name and the param name should be the same thing. how about "unapi-id"? > > I concede Rob's point that saying "to implement unAPI you must first > define and implement a URI-based identifier persistence strategy" > contradicts the notion of "simple to implement". > I think the difficulty comes from we try to "kill two birds with one stone", maybe we can get unapi right this time and continue to push the a "uri/uid" microformats case. Once "uri/uid" microformats happends we will have the nice combination of unapi and "uri" microformats. xiaoming From daniel.chudnov at yale.edu Wed May 3 16:35:28 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Wed May 3 16:36:02 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> Message-ID: <20060503203528.GH26675@sildin.med.yale.edu> Xiaoming Liu wrote, on Wed, May 03, 2006 at 02:16:15PM -0600: > On Wed, 3 May 2006, Daniel Chudnov wrote: > > >Ultimately, the param value has to be some sort of identifier, right? > >The class name and the param name should be the same thing. > > how about "unapi-id"? I could see that. :) And, then, UNAPI?id=foo. > >I concede Rob's point that saying "to implement unAPI you must first > >define and implement a URI-based identifier persistence strategy" > >contradicts the notion of "simple to implement". > > I think the difficulty comes from we try to "kill two birds with one > stone", maybe we can get unapi right this time and continue to push the > a "uri/uid" microformats case. Once "uri/uid" microformats happends we > will have the nice combination of unapi and "uri" microformats. Right, then, we wouldn't have to change anything. I get it. Could more folks weigh in on this? This is pretty important and we're right up against our deadline of tomorrow. The rough proposal would need to (at least): - drop the implicit URI requirement - change the unapi class value pattern from "unapi-uri" to "unapi-id" - change the "uri" parameter name to "id" - change the formats response and its implied schema from "attribute uri { text }?" to "attribute id { text }?," <-- Ouch! we can't use an XML attribute named "id". Maybe "attribute unapi-id { text }?" instead then? /me pines for symmetry. Still... this is feeling closer. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Wed May 3 16:53:55 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Wed May 3 16:54:40 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060503203528.GH26675@sildin.med.yale.edu> References: <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> Message-ID: On Wed, 3 May 2006, Daniel Chudnov wrote: > "attribute uri { text }?" to "attribute id { text }?," > > <-- Ouch! we can't use an XML attribute named "id". Maybe > "attribute unapi-id { text }?" instead then? > I think Alf previously suggested dropping the attribute uri{text} [1], "particularly if you leave the URI out of the resposne (as it doesn't seem particularly useful - the client will already know which URI it asked for)." is this still on the table? I think it makes sense to drop the attribute. [1] http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-April/000732.html xiaoming From leftwing at alumni.rutgers.edu Wed May 3 17:44:56 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Wed May 3 17:46:31 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060503203528.GH26675@sildin.med.yale.edu> References: <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> Message-ID: <22dbc4ae0605031444w746d87a1mbd78bcd932a32dd@mail.gmail.com> On 5/3/06, Daniel Chudnov wrote: > > > I could see that. :) And, then, UNAPI?id=foo. Or UNAPI?unapi-id=foo as you suggest later. I too crave symmetry, and agree that moving away from URI (but allowing usage of URI for ambitious developers) will reduce adoption barriers. Could more folks weigh in on this? This is pretty important and we're > right up against our deadline of tomorrow. :) - drop the implicit URI requirement +1 - change the unapi class value pattern from "unapi-uri" to "unapi-id" +1 - change the "uri" parameter name to "id" Or to unapi-id? -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060503/a71923f4/attachment.htm From ehs at pobox.com Wed May 3 22:22:45 2006 From: ehs at pobox.com (Edward Summers) Date: Wed May 3 22:23:53 2006 Subject: [gcs-pcs-list] Identifiers In-Reply-To: References: <1146677208.2817.80.camel@helmsdeep> Message-ID: <3ECF46AC-F310-495C-B2FB-85026FA8C0EE@pobox.com> On May 3, 2006, at 3:04 PM, Xiaoming Liu wrote: > If 'uid' here is re-using uid concept in microformats, I am afraid > this > won't work because 'uid' in microformats is defined as global unique > identifier (at least for now). Good point Xiaoming. In practice I wonder how many of these UIDs are actually globally unique in vCard. It's really hard to defer to microformats.org/wiki/uid at this point since even a strawman proposal isn't there yet. //Ed From lists at hubmed.org Thu May 4 00:39:26 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 4 00:43:53 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <20060503203528.GH26675@sildin.med.yale.edu> References: <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> Message-ID: <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> On 03 May 2006, at 16:35, Daniel Chudnov wrote: >>> I concede Rob's point that saying "to implement unAPI you must first >>> define and implement a URI-based identifier persistence strategy" >>> contradicts the notion of "simple to implement". >> >> I think the difficulty comes from we try to "kill two birds with one >> stone", maybe we can get unapi right this time and continue to >> push the >> a "uri/uid" microformats case. Once "uri/uid" microformats >> happends we >> will have the nice combination of unapi and "uri" microformats. > > Right, then, we wouldn't have to change anything. I get it. > > Could more folks weigh in on this? This is pretty important and we're > right up against our deadline of tomorrow. It would be useful if people could describe the use cases they have in mind for unapi - then it would be easier to see how the reasoning for or against a requirement for URIs stands up. The use cases I have in mind, which I've already mentioned earlier - including exporting citation metadata to reference managers - all work fine with URIs, as far as I can see. I also think the likelihood of people for marking up pages with semantics that are generically useful ("uri", maybe "uid") is much higher than anything specific to unapi. Does that seem like a reasonable statement, or will people be happy to add extra markup everywhere for a specific use (otherwise it could become a chicken and egg scenario)? alf. From bdarcus.lists at gmail.com Thu May 4 09:40:10 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Thu May 4 09:41:55 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> Message-ID: On 5/4/06, Alf Eaton wrote: > It would be useful if people could describe the use cases they have > in mind for unapi - then it would be easier to see how the reasoning > for or against a requirement for URIs stands up. I was thinking the same. Intuitively, I find myself myself strongly disagreing with the argument against requiring uris, but I guess one's perspective depends on the uses one is imagining. For the example that Rob posted, "images/1234" is a valid uri, and I would really hate the circumstance where five different unapi services-- each of which could return book metadata by isbn -- .each used different ways of identification (some uri, and some not), when we have a registered urn. So I think if people are going to argue this, it'd be good to whip out some concrete use cases that would make requiring uris unacceptable. As an aside, I am strongly in favor of using uris to identify citation resources, and intend to get the OpenDocument spec to reflect that. One of the reasons is precisely to make the documents more portable. Bruce From ross.singer at library.gatech.edu Thu May 4 10:20:45 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu May 4 10:22:21 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> Message-ID: <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> On 5/4/06, Bruce D'Arcus wrote: > > So I think if people are going to argue this, it'd be good to whip out > some concrete use cases that would make requiring uris unacceptable. Ok, I'll take a stab at this one. I actually have a couple of use cases where using URIs would be awkward (or of questionable value). 1) unAPI on the OPAC -- in many cases, yes, we have standard identifier to work with (ISxN), but (in our case, at least) just as often, we don't (GovDocs, maps, Theses & Dissertations, DVDs, CDs) -- so why should expend the extra cycles trying to parse /every result/ for a registered, recognizable URI/N (and then, subsequently, have to account for a variety of URI/Ns as unapi-id argument as input to resolve) when I have a local identifier that easily and consistently return all the metadata I have about an object, including all of the URI/Ns I have? 2) unAPI on the Archives Finding Aids -- I don't even really know where to begin with this one... first, I don't really know what to use a URI and our finding aids point to digitized items (which, ideally, would also be referred to via unAPI). Yes, I realize URL could work here, but what's the real advantage? -Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060504/af6d96d2/attachment-0001.htm From bdarcus.lists at gmail.com Thu May 4 10:35:33 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Thu May 4 10:37:06 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> Message-ID: On 5/4/06, Ross Singer wrote: > 1) unAPI on the OPAC -- in many cases, yes, we have standard identifier to > work with (ISxN), but (in our case, at least) just as often, we don't > (GovDocs, maps, Theses & Dissertations, DVDs, CDs) -- so why should expend > the extra cycles trying to parse /every result/ for a registered, > recognizable URI/N (and then, subsequently, have to account for a variety of > URI/Ns as unapi-id argument as input to resolve) when I have a local > identifier that easily and consistently return all the metadata I have about > an object, including all of the URI/Ns I have? So here the use case is id is embedded in a web page, and the user clicks some link that requests the resource from self? The id is local. > 2) unAPI on the Archives Finding Aids -- I don't even really know where to > begin with this one... first, I don't really know what to use a URI and our > finding aids point to digitized items (which, ideally, would also be > referred to via unAPI). Yes, I realize URL could work here, but what's the > real advantage? Make it easier for people like me? I do some archival work, and I'd love to be able to cite those resources by stable uri --and in turn have tools grab the reelvant metadata -- rather than to invent my own local ids. My citation data is RDF, which requires uris for identification, but I rather think that a good thing because it means that as soon as I can use an id that others use, my data can be merged with that data. Let's get with the semantic web, which starts with uris :-) Bruce From daniel.chudnov at yale.edu Thu May 4 10:57:20 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 4 10:58:27 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> Message-ID: On May 4, 2006, at 10:35 AM, Bruce D'Arcus wrote: > On 5/4/06, Ross Singer wrote: > >> referred to via unAPI). Yes, I realize URL could work here, but >> what's the >> real advantage? > > Make it easier for people like me? I do some archival work, and I'd > love to be able to cite those resources by stable uri --and in turn > have tools grab the reelvant metadata -- rather than to invent my own > local ids. The insight that Rob finally managed to crowbar into my head is that we're not going to convince the world to start publishing and persisting URIs. If we require URIs in unAPI, we're not going to convince the world to start using unAPI. If the only people who use unAPI are the same people that use OAI and OpenURL, then, well, we might have made our own jobs slightly easier, but really only slightly (as has been pointed out here repeatedly). The real benefit of unAPI appears if people outside of our weird niche use it. Most of those people already have tons of identified content, much of which doesn't explicitly speak "persistent URI". So if you have your own URIs, great, please publish with them... indeed we can do more with reliable URIs. But if not, we still really want and need your data, and I still want it via unAPI. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Thu May 4 11:21:22 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu May 4 11:22:09 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> References: <20060405213925.GJ15372@sildin.med.yale.edu> <7B208632-5470-40A6-9F36-4ACD129FB557@hubmed.org> <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> Message-ID: On Thu, 4 May 2006, Alf Eaton wrote: > > It would be useful if people could describe the use cases they have in mind > for unapi - then it would be easier to see how the reasoning for or against a > requirement for URIs stands up. In copy/paste scenarios, it might be equally good to copy any records (bibtex, dc, mods) without mandating a URI. In an implementation of Microsoft liveclipboard, I imagine what's carrying on in the clipboard is a nake DC record (without unAPI header/format/id, etc), and therefore in a target site the unapi-id (uri) is not really visible. A URI microformats is all good, I think it should be a mandatory to mark any URI in HTML page, this certainly can at least make Google smarter. Having said that, I am now thinking unAPI and URI microformats are two problem domains. Clearly they share large common grounds, but they are not the same. xiaoming From lists at hubmed.org Thu May 4 11:27:07 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 4 11:31:02 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> Message-ID: <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> On 04 May 2006, at 10:57, Daniel Chudnov wrote: > The insight that Rob finally managed to crowbar into my head is > that we're not going to convince the world to start publishing and > persisting URIs. Ok, that might be a good point. I think I would like to try and convince the world to start publishing and persisting URIs, so if everyone agrees that that should definitively not be an aim of unapi then so be it and we can move on. However, I think that would make unapi less useful, for what might well be a minimal gain (that's just a random guess, Rob obviously has experience of difficulties...) in ease of adoption. If you have a local identifier, all you have to do is stick http:// yourdomain/ at the front of it and it's suddenly a URI. Is there something that makes that more difficult? Persistence over time, though, is a different - also important - issue. alf. From liu_x at lanl.gov Thu May 4 11:40:24 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu May 4 11:41:08 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: On Thu, 4 May 2006, Alf Eaton wrote: > > On 04 May 2006, at 10:57, Daniel Chudnov wrote: > >> The insight that Rob finally managed to crowbar into my head is that we're >> not going to convince the world to start publishing and persisting URIs. > > Ok, that might be a good point. I think I would like to try and convince the > world to start publishing and persisting URIs, so if everyone agrees that > that should definitively not be an aim of unapi then so be it and we can move > on. Since we don't know for sure if microformats.org is going to adopt a "uri" microformats. I am wondering if it makes sense to establish "uri" class by ROGUE process, so we can start to markup HTML/unAPI with "uri" class. If indeed one day microformats.org chooses "uri", I guess we can simply deprecate ROGUE "uri" class. I think (hope) this will be real easy case comparing to unAPI spec. xiaoming > However, I think that would make unapi less useful, for what might well > be a minimal gain (that's just a random guess, Rob obviously has experience > of difficulties...) in ease of adoption. > > If you have a local identifier, all you have to do is stick > http://yourdomain/ at the front of it and it's suddenly a URI. Is there > something that makes that more difficult? > > Persistence over time, though, is a different - also important - issue. > > alf. > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ehs at pobox.com Thu May 4 11:43:06 2006 From: ehs at pobox.com (Edward Summers) Date: Thu May 4 11:44:12 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: On May 4, 2006, at 10:27 AM, Alf Eaton wrote: > If you have a local identifier, all you have to do is stick http:// > yourdomain/ at the front of it and it's suddenly a URI. Is there > something that makes that more difficult? How is http://mydomain.com/123 more useful than 123 in the context of unAPI? //Ed From lists at hubmed.org Thu May 4 11:49:27 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 4 11:50:07 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: On 04 May 2006, at 11:43, Edward Summers wrote: > > On May 4, 2006, at 10:27 AM, Alf Eaton wrote: >> If you have a local identifier, all you have to do is stick http:// >> yourdomain/ at the front of it and it's suddenly a URI. Is there >> something that makes that more difficult? > > How is http://mydomain.com/123 more useful than 123 in the context > of unAPI? If you copy the object and paste it somewhere else, you'll want a URL to refer to, if possible, for things like live updates later. Admittedly, http://yourunapiserver?id=whatever would work for that, but if yourunapiserver disappears it would be nice to be able to get the information from somewhere else. alf. From ehs at pobox.com Thu May 4 11:53:45 2006 From: ehs at pobox.com (Edward Summers) Date: Thu May 4 11:54:51 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: On May 4, 2006, at 10:40 AM, Xiaoming Liu wrote: > Since we don't know for sure if microformats.org is going to adopt > a "uri" microformats. I am wondering if it makes sense to establish > "uri" class by ROGUE process, so we can start to markup HTML/unAPI > with "uri" class. If indeed one day microformats.org chooses "uri", > I guess we can simply deprecate ROGUE "uri" class. From my perspective the naming of 'uid' versus 'uri' is not really an issue...so I'm more interested in pursuing the microformats angle since they have a larger fan base. //Ed From eric at openly.com Thu May 4 12:15:27 2006 From: eric at openly.com (Eric Hellman) Date: Thu May 4 12:17:15 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: +1 composition of 2 specs - uri and unapi - is a better design. >On Thu, 4 May 2006, Alf Eaton wrote: > >> >>On 04 May 2006, at 10:57, Daniel Chudnov wrote: >> >>>The insight that Rob finally managed to crowbar into my head is >>>that we're not going to convince the world to start publishing and >>>persisting URIs. >> >>Ok, that might be a good point. I think I would like to try and >>convince the world to start publishing and persisting URIs, so if >>everyone agrees that that should definitively not be an aim of >>unapi then so be it and we can move on. > >Since we don't know for sure if microformats.org is going to adopt a >"uri" microformats. I am wondering if it makes sense to establish >"uri" class by ROGUE process, so we can start to markup HTML/unAPI >with "uri" class. If indeed one day microformats.org chooses "uri", >I guess we can simply deprecate ROGUE "uri" class. > >I think (hope) this will be real easy case comparing to unAPI spec. > >xiaoming -- 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 liu_x at lanl.gov Thu May 4 12:16:36 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu May 4 12:17:20 2006 Subject: uri discussion (Was [gcs-pcs-list] unAPI: rewrite attempt) In-Reply-To: References: <20060502163110.GA25858@sildin.med.yale.edu> <20060503182129.GE26675@sildin.med.yale.edu> <20060503203528.GH26675@sildin.med.yale.edu> <0C5B2892-B017-434C-B29A-7F61735C1152@hubmed.org> <23b83f160605040720i47c5b257n51c2dc9a38c67de8@mail.gmail.com> <3CDD0C17-D133-44E6-ABE2-C403ECE8AA73@hubmed.org> Message-ID: On Thu, 4 May 2006, Edward Summers wrote: > > On May 4, 2006, at 10:40 AM, Xiaoming Liu wrote: >> Since we don't know for sure if microformats.org is going to adopt a "uri" >> microformats. I am wondering if it makes sense to establish "uri" class by >> ROGUE process, so we can start to markup HTML/unAPI with "uri" class. If >> indeed one day microformats.org chooses "uri", I guess we can simply >> deprecate ROGUE "uri" class. > > From my perspective the naming of 'uid' versus 'uri' is not really an > issue...so I'm more interested in pursuing the microformats angle since they > have a larger fan base. I don't care much about the naming either, I am more concerned about the semantic carried in uid -- e.g. If I have an ISBN URI in hcalendar summary, am I allowed to mark it as uid? anyhow I feel quite uncertain which direction and how long it takes in microformats.org. In principle we are free to use whatever "class" we choose in HTML page, and it would be nice if we can start to use it now, and perhaps by this step we can learn more lessons as input to microformats.org xiaoming > > //Ed > _______________________________________________ > 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 Thu May 4 13:33:27 2006 From: azaroth at liverpool.ac.uk (Rob Sanderson) Date: Thu May 4 12:37:29 2006 Subject: [gcs-pcs-list] Re: Identifiers Message-ID: <1146764008.6101.72.camel@helmsdeep> To cut to the chase, here are the conclusions from my use cases for you to agree with or reject: * Ease of interface creation -- it's easier to allow any string, than to reject some strings. I'm going out on a limb here, but without checking, I'm fairly sure there isn't an HTTP status code for 'identifier given not a URI'. * Ease of UR[L|I] sustainability -- it's more likely people will use unAPI urls as a persistent URL if they can use their internal identifiers or human typable/readable identifiers. * Doesn't exclude people -- People who don't care about URIs, don't want to care about them, or otherwise only have a limited amount of time to spend on unAPI learning would prefer to see 'your identifier' not 'URI[1] formatted identifier' and have to go chase down how to format a URI as described by [1]. * Doesn't actually gain anything -- the people who would use URIs *will use them anyway*. I'm sure that most of the people here absolutely will use URIs. But most of the world is not on this list. Use cases: * Amazon has an electronic product and wants a massively cut down web service to allow access to that known object (as discovered via AWS, perhaps) Unlike their books, dvds, etc, there isn't an isbn/issn/whatever for it, so they'll doubtless use their product id. They /could/ turn that into a URI, but there's no reason to as everyone would need to do the mapping from the AWS response into the unAPI request. Replace Amazon with other big company with a database of objects that do not have URIs. (eg ... 99.999% of them) * Some database of objects can transform its constituents. A requirement is persistent URLs. Objects do not have natural URIs but do have natural identifiers. The interface designer is more likely to choose http://foo.com/data?id=myLocalId than http://foo.com/data?http:%XX%XXfoo.com%XXdata%XXmyLocalId because the second is Just Plain Ugly. [The main reason for unAPI's existence IMNSHO is that OpenURL is too complicated and Just Plain Ugly, otherwise we'd just use that] * New web geek has a database, wants to follow some easy to implement standard so they can blog about how kewl they are. They write some simple code like mysql_query("select * from table where id='$form['id']'") [ignoring the obvious injection attacks etc] and voila has unAPI without having to learn about URIs or tags or infos or why you might want embed http://host:port/path inside another URL. * Alf and Dan build a hoopy unAPI resolving network that finds and transforms neat stuff from huge databases. They use URIs for persistence and uniqueness. The book subset of stuff is then taken on by Bruce's citation stuff and imported directly into OpenDocuments, which are passed around between government agencies and ... blah blah blah insert more neat stuff here. Rest of the world says "Heh, that's cool" Some of the rest of the world follows suit. Other parts of the rest of the world don't really care if their identifiers are passed around because it's not in their business model, use cases, requirements or frankly [my dear] they just don't give a damn. Re semantic web: SW is a cool idea. It was also cool in 2001 when I heard Eric Miller talking about it at ECDL. It was also cool when I heard Norm Walsh talking about it at UC Berkeley in 2004. Now it's 2006, and it's still cool, and still not here. Like Microformats, unAPI should focus energies in one direction, not try to create energy for cool things. Let the cool things be built on top. Re EAD: EAD instances have an element which you would expect to use as an identifier for that instance. It's not [necessarily] a URI. Why should you meaninglessly add tag:// or http://blablabla/ in front of it? Repeat for all other data formats. 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 Thu May 4 12:52:54 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 4 12:53:37 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: <1146764008.6101.72.camel@helmsdeep> References: <1146764008.6101.72.camel@helmsdeep> Message-ID: <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> On 04 May 2006, at 13:33, Rob Sanderson wrote: > To cut to the chase, here are the conclusions from my use cases for > you > to agree with or reject: Ok, that all makes sense. The only alternative I can think of is the earlier suggestion to still have everything called URIs, but put '#' in front of it if it's local. Assuming that's still too complicated/ unnecessary, that leaves the following: 1. identifiers can be anything you want. 2. identifiers are only guaranteed to work with the unapi server linked in the head of the page. 3. identifiers can't be guaranteed to persist over time (how long... 1 minute... 1 day... 1 year?) 4. all identifiers have to be marked with class="unapi" (though they can still be "uri" as well). Still useful and adoptable? alf. From daniel.chudnov at yale.edu Thu May 4 21:04:26 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 4 21:06:05 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: On May 4, 2006, at 12:52 PM, Alf Eaton wrote: > > 1. identifiers can be anything you want. > 2. identifiers are only guaranteed to work with the unapi server > linked in the head of the page. > 3. identifiers can't be guaranteed to persist over time (how > long... 1 minute... 1 day... 1 year?) > 4. all identifiers have to be marked with class="unapi" (though > they can still be "uri" as well). > > Still useful and adoptable? I don't think we can say anything about "guarantees". Sites should be able to have stale references to discarded objects for which unAPI queries can correctly return 404. Also, I can live with class="unapi", but i'd still searching for something more symmetric (same class name as parameter name). Was my concern about using the attribute name "id" in xml mistaken? Seems I saw something about that today but I don't see it in the list archives. Maybe it was on-channel? If so please repeat here... -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Thu May 4 21:14:21 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 4 21:18:12 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: On 04 May 2006, at 21:04, Daniel Chudnov wrote: > On May 4, 2006, at 12:52 PM, Alf Eaton wrote: >> >> 1. identifiers can be anything you want. >> 2. identifiers are only guaranteed to work with the unapi server >> linked in the head of the page. >> 3. identifiers can't be guaranteed to persist over time (how >> long... 1 minute... 1 day... 1 year?) >> 4. all identifiers have to be marked with class="unapi" (though >> they can still be "uri" as well). >> >> Still useful and adoptable? > > I don't think we can say anything about "guarantees". Sites should > be able to have stale references to discarded objects for which > unAPI queries can correctly return 404. > > Also, I can live with class="unapi", but i'd still searching for > something more symmetric (same class name as parameter name). Was > my concern about using the attribute name "id" in xml mistaken? > Seems I saw something about that today but I don't see it in the > list archives. Maybe it was on-channel? If so please repeat here... Is it just xml:id that's reserved? I don't know whether these kinds of things apply to xml that doesn't have a namespace. http://www.w3.org/TR/xml-id/ What about class="identifier"? alf. From daniel.chudnov at yale.edu Thu May 4 21:32:09 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 4 21:33:50 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: On May 4, 2006, at 9:14 PM, Alf Eaton wrote: >> >> Also, I can live with class="unapi", but i'd still searching for >> something more symmetric (same class name as parameter name). Was >> my concern about using the attribute name "id" in xml mistaken? >> Seems I saw something about that today but I don't see it in the >> list archives. Maybe it was on-channel? If so please repeat here... > > Is it just xml:id that's reserved? I don't know whether these kinds > of things apply to xml that doesn't have a namespace. > http://www.w3.org/TR/xml-id/ Or is xml:id just a type declaration, leaving us free to use it as an attribute name if we want? See, now, this is why i wanted to just use json. :P > What about class="identifier"? If we can use "id" as an xml attribute name, and "id" as the unAPI parameter name, and "unapi-id" or "identifier" or "id" as the class name, I'll be happy. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu May 4 22:06:01 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 4 22:07:45 2006 Subject: [gcs-pcs-list] unAPI update. Message-ID: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> I don't know about you all, but I'm exhausted. :) The good news is that we're almost done. The bad news is that we're not done, and rev3 is due today. Here's what's still open: - class/param/identifier issue - change the 's @rel value? - consider changing from span to abbr It feels like we're gelling around a consensus of sorts on the class/ param/identifier thing, but I need to get a good night's sleep and re- read the past few days' threads on this before seeing through it all clearly again. There wasn't much feedback on the link @rel value thing. Please weigh in on that thread if you have an opinion. As for span vs. abbr: an "official" answer to this question, raised by Alf on uf-discuss, is here: http://microformats.org/discuss/mail/microformats-discuss/2006- April/003605.html ...which still leaves me not knowing which is better. Is it right to say that span works, but abbr is "better"? Or that they both work okay? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Thu May 4 22:16:44 2006 From: eric at openly.com (Eric Hellman) Date: Thu May 4 22:18:35 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: At 9:04 PM -0400 5/4/06, Daniel Chudnov wrote: >Also, I can live with class="unapi", but i'd still searching for >something more symmetric (same class name as parameter name). Was >my concern about using the attribute name "id" in xml mistaken? >Seems I saw something about that today but I don't see it in the >list archives. Maybe it was on-channel? If so please repeat here... nothing wrong with using an attribute named "id". perhaps the use of id in xhtml is what has confused you -- 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 May 4 22:36:39 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 4 22:38:23 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: On May 4, 2006, at 10:16 PM, Eric Hellman wrote: > At 9:04 PM -0400 5/4/06, Daniel Chudnov wrote: >> Also, I can live with class="unapi", but i'd still searching for >> something more symmetric (same class name as parameter name). Was >> my concern about using the attribute name "id" in xml mistaken? >> Seems I saw something about that today but I don't see it in the >> list archives. Maybe it was on-channel? If so please repeat here... > > nothing wrong with using an attribute named "id". perhaps the use > of id in xhtml is what has confused you Okay, then: What about just using "id" for everything? Class name, parameter name, and formats response attribute name? Doesn't clash with "uid" or "uri", each of which might be used also, or not. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Thu May 4 23:24:23 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu May 4 23:25:06 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> Message-ID: On Thu, 4 May 2006, Daniel Chudnov wrote: > > As for span vs. abbr: an "official" answer to this question, raised by Alf > on uf-discuss, is here: > > http://microformats.org/discuss/mail/microformats-discuss/2006-April/003605.html > > ...which still leaves me not knowing which is better. Is it right to say > that span works, but abbr is "better"? Or that they both work okay? > Microformats defines general class types, and these class names can be applied in many different tags by HTML definition. I think we need to fix on one for easy implementation, if so I would vote for "abbr". xiaoming From lists at hubmed.org Fri May 5 01:26:57 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 01:27:58 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: On 04 May 2006, at 22:36, Daniel Chudnov wrote: > > On May 4, 2006, at 10:16 PM, Eric Hellman wrote: > >> At 9:04 PM -0400 5/4/06, Daniel Chudnov wrote: >>> Also, I can live with class="unapi", but i'd still searching for >>> something more symmetric (same class name as parameter name). >>> Was my concern about using the attribute name "id" in xml >>> mistaken? Seems I saw something about that today but I don't see >>> it in the list archives. Maybe it was on-channel? If so please >>> repeat here... >> >> nothing wrong with using an attribute named "id". perhaps the use >> of id in xhtml is what has confused you > > Okay, then: > > What about just using "id" for everything? Class name, parameter > name, and formats response attribute name? So what happens if, say, there's a web page with a list of items on it, one of which is a book that has Amazon identifier '4857632' and one of which is a photograph that has a local identifier '4857632'. If they're all marked up with class="id", how does the unapi server know which one you're asking for? alf. From lists at hubmed.org Fri May 5 01:31:01 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 01:32:08 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> Message-ID: On 04 May 2006, at 22:06, Daniel Chudnov wrote: > > As for span vs. abbr: an "official" answer to this question, > raised by Alf on uf-discuss, is here: > > http://microformats.org/discuss/mail/microformats-discuss/2006- > April/003605.html > > ...which still leaves me not knowing which is better. Is it right > to say that span works, but abbr is "better"? Or that they both > work okay? You can use either. If it's a span, the inner text is the value; if it's an abbr, the @title is the value. alf. From daniel.chudnov at yale.edu Fri May 5 08:27:55 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 5 08:28:27 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: <20060505122754.GB28801@sildin.med.yale.edu> Alf Eaton wrote, on Fri, May 05, 2006 at 01:26:57AM -0400: > On 04 May 2006, at 22:36, Daniel Chudnov wrote: > > > >What about just using "id" for everything? Class name, parameter > >name, and formats response attribute name? > > So what happens if, say, there's a web page with a list of items on > it, one of which is a book that has Amazon identifier '4857632' and > one of which is a photograph that has a local identifier '4857632'. > If they're all marked up with class="id", how does the unapi server > know which one you're asking for? It wouldn't, and the user would have to figure it out. We can't route around world-wide sloppiness. Though it would be better if the web page authors knew enough to scope at least one of those identifiers better. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri May 5 08:35:54 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 5 08:36:26 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> Message-ID: <20060505123554.GC28801@sildin.med.yale.edu> Xiaoming Liu wrote, on Thu, May 04, 2006 at 09:24:23PM -0600: > On Thu, 4 May 2006, Daniel Chudnov wrote: > > >As for span vs. abbr: an "official" answer to this question, raised by > >Alf on uf-discuss, is here: > > > >http://microformats.org/discuss/mail/microformats-discuss/2006-April/003605.html > > > >...which still leaves me not knowing which is better. Is it right to say > >that span works, but abbr is "better"? Or that they both work okay? > > > > Microformats defines general class types, and these class names can be > applied in many different tags by HTML definition. > > I think we need to fix on one for easy implementation, if so I would > vote for "abbr". I agree that we should pick just one to keep client implementations simple. It doesn't matter to me which we choose, though so many people preferred the option of displaying something "user-friendly" (or nothing) without css hacks early on, e.g.: ID value ...that maybe that's better for us? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From efc at umn.edu Fri May 5 09:34:45 2006 From: efc at umn.edu (Eric Celeste) Date: Fri May 5 09:39:07 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: > So what happens if, say, there's a web page with a list of items on > it, one of which is a book that has Amazon identifier '4857632' and > one of which is a photograph that has a local identifier '4857632'. > If they're all marked up with class="id", how does the unapi server > know which one you're asking for? Note: > 2. identifiers are only guaranteed to work with the unapi server > linked in the head of the page. If this is true, then the fact that you are mixing amazon and photo ids on a single page must mean that you have a single resolver that can deal with both sets of objects. That resolver would have to be able to make the distinction, and I bet the way the managers of that resolver do this is by adding extra info to the identifiers they resolve, perhaps making the Amazon ids all start with "a" (bad idea, but stick with me) and the photo ids all start with "p". Then their resolver will be able to tell the difference. In a way, this is the service I imagine DLF Aquifer could play for unapi. Aquifer could provide a single resolver to objects from many repositories. The unapi ids provided by Aquifer would probably differ slightly from the native ids of those resources, but that should not matter to an implementor as long as the Aquifer resolver can resolve them. Remember, "unapi ids are only guaranteed to work with the unapi server linked in the head of the page." ...Eric Eric Celeste / 612-624-4126 / efc@umn.edu Associate University Librarian for Information Technology University of Minnesota (Twin Cities) Libraries From ehs at pobox.com Fri May 5 11:44:56 2006 From: ehs at pobox.com (Edward Summers) Date: Fri May 5 11:46:07 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505123554.GC28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> Message-ID: <53D8A613-28EA-4A6D-87B5-447114E5F949@pobox.com> On May 5, 2006, at 7:35 AM, Daniel Chudnov wrote: > ID value > > ...that maybe that's better for us? +1 //Ed From lists at hubmed.org Fri May 5 11:53:07 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 11:56:59 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505123554.GC28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> Message-ID: <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> On 05 May 2006, at 08:35, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Thu, May 04, 2006 at 09:24:23PM -0600: >> On Thu, 4 May 2006, Daniel Chudnov wrote: >> >>> As for span vs. abbr: an "official" answer to this question, >>> raised by >>> Alf on uf-discuss, is here: >>> >>> http://microformats.org/discuss/mail/microformats-discuss/2006- >>> April/003605.html >>> >>> ...which still leaves me not knowing which is better. Is it >>> right to say >>> that span works, but abbr is "better"? Or that they both work okay? >>> >> >> Microformats defines general class types, and these class names >> can be >> applied in many different tags by HTML definition. >> >> I think we need to fix on one for easy implementation, if so I would >> vote for "abbr". > > I agree that we should pick just one to keep client implementations > simple. It doesn't matter to me which we choose, though so many > people > preferred the option of displaying something "user-friendly" (or > nothing) > without css hacks early on, e.g.: > > ID value Why do things differently to the way all the other microformats work? If you do ID value then I can't have an invisible element on the page, unless you say clients should use the inner text if there is any, and if there isn't use the @title. eg alf. From ehs at pobox.com Fri May 5 12:29:46 2006 From: ehs at pobox.com (Edward Summers) Date: Fri May 5 12:30:52 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> Message-ID: On May 5, 2006, at 10:53 AM, Alf Eaton wrote: > If you do > ID value > then I can't have an invisible element on the page, unless you say > clients should use the inner text if there is any, and if there > isn't use the @title. > > eg Good point I take back my +1 ... //Ed From daniel.chudnov at yale.edu Fri May 5 14:19:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 5 14:19:36 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> Message-ID: <20060505181903.GD28801@sildin.med.yale.edu> Alf Eaton wrote, on Fri, May 05, 2006 at 01:31:01AM -0400: > On 04 May 2006, at 22:06, Daniel Chudnov wrote: > > > >As for span vs. abbr: an "official" answer to this question, > >raised by Alf on uf-discuss, is here: > > > > http://microformats.org/discuss/mail/microformats-discuss/2006- > >April/003605.html > > > >...which still leaves me not knowing which is better. Is it right > >to say that span works, but abbr is "better"? Or that they both > >work okay? > > You can use either. If it's a span, the inner text is the value; if > it's an abbr, the @title is the value. Okay. But, wouldn't it be better (simpler) for unAPI to just pick one? -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri May 5 14:52:07 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 5 14:52:41 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> Message-ID: <20060505185206.GE28801@sildin.med.yale.edu> Alf Eaton wrote, on Fri, May 05, 2006 at 11:53:07AM -0400: > > Why do things differently to the way all the other microformats work? I don't understand the subleties of the way microformats work, so please spell this out. > If you do > ID value > then I can't have an invisible element on the page, unless you say > clients should use the inner text if there is any, and if there isn't > use the @title. > > eg Is not being able to elide text content an an effect of browser implementations or an explicit principle of microformats? My XML knowledge is obviously poor (so please correct me), but, afaict the XML DTD allows empty s. Imho it would be simplest if we just chose one required pattern (one element, id value in title attribute value) and made the text content optional. If microformats allow more flexibility than this, then we're not non-conforming, rather we're being stricter to simplify implementations. Or is there something wrong with that? General note to everybody: since pieces of this discussion are spanning other lists (uf-discuss) or the #code4lib channel, please be explicit and don't assume most of us will bring the same context you do to this or related issues. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ehs at pobox.com Fri May 5 15:33:59 2006 From: ehs at pobox.com (Edward Summers) Date: Fri May 5 15:35:06 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505185206.GE28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> Message-ID: On May 5, 2006, at 1:52 PM, Daniel Chudnov wrote: > Is not being able to elide text content an an effect of browser > implementations or an explicit principle of microformats? My XML > knowledge is obviously poor (so please correct me), but, afaict the > XML > DTD allows empty s. > http://microformats.org/wiki/abbr-design-pattern has some details: "Avoiding using the abbr-design-pattern to re-encode human text or to hide data" //Ed From liu_x at lanl.gov Fri May 5 16:00:22 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 5 16:01:04 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> Message-ID: On Fri, 5 May 2006, Edward Summers wrote: > On May 5, 2006, at 1:52 PM, Daniel Chudnov wrote: >> Is not being able to elide text content an an effect of browser >> implementations or an explicit principle of microformats? My XML >> knowledge is obviously poor (so please correct me), but, afaict the XML >> DTD allows empty s. >> > > http://microformats.org/wiki/abbr-design-pattern has some details: > > "Avoiding using the abbr-design-pattern to re-encode human text or to > hide data" read more from the wiki: "1. using ABBR to encode machine readable data around human readable data" does this apply to typical use case of unAPI? and "If someone is not willing to make some information visible, then we shouldn't be encouraging them to store that information invisibly, for all the same reasons that invisible metadata is bad/futile in the first place." I think this tells we shouldn't use hidden text. xiaoming > > //Ed > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From fawcett at uwindsor.ca Fri May 5 16:27:10 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Fri May 5 16:28:45 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> Message-ID: <445BB51E.7040903@uwindsor.ca> Xiaoming Liu wrote: > read more from the wiki: > > "1. using ABBR to encode machine readable data around human > readable data" > > does this apply to typical use case of unAPI? > > and > "If someone is not willing to make some information visible, then > we shouldn't be encouraging them to store that information invisibly, > for all the same reasons that invisible metadata is bad/futile in the > first place." > > I think this tells we shouldn't use hidden text. Just my two cents, but hidden text (rather, unapi identifiers embedded in a document, but not associated with a specific bit of text) seems a useful case, and one that would turn up relatively quickly in real-world use. (A gallery of book-cover images might have no text, but should be a valid unapi use-case, no?). The microformat abbr@title pattern discourages empty text because it suggests that the title should be a machine-readable version of the human-readable abbr text (and not, for example, a reference to an associated object in an external datasource). Canonically-formatted dates, names, locations, etc. make sense in this context, and empty abbr-text would be meaningless under the pattern (unless the title were an empty string, or the string-value "null" or "void"). If playing nicely with microformats is a long-term goal, and if microformats has claimed abbr@title as a means of providing machine-readable equivalents to human-readable text (which isn't unapi's goal), then I'd suggest that abbr@title is not the pattern to use for unapi. At any rate, at a purely semantic level, unapi identifiers aren't expansions of abbreviations. So why use abbr? I vote for span. Graham From lists at hubmed.org Fri May 5 16:51:51 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 16:52:32 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505185206.GE28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> Message-ID: <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> On 05 May 2006, at 14:52, Daniel Chudnov wrote: > Alf Eaton wrote, on Fri, May 05, 2006 at 11:53:07AM -0400: >> >> Why do things differently to the way all the other microformats work? > > I don't understand the subleties of the way microformats work, so > please > spell this out. The rule for microformat processors is to take the inner text of the element, unless it's an , in which case take the title element and ignore the inner text. In other words: DATA or anything tags are an exception though, because there you're getting the data from the href attribute. alf. From leftwing at alumni.rutgers.edu Fri May 5 16:55:42 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri May 5 16:57:17 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <445BB51E.7040903@uwindsor.ca> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <445BB51E.7040903@uwindsor.ca> Message-ID: <22dbc4ae0605051355u10a58190h9f974cea925192cb@mail.gmail.com> On 5/5/06, Graham Fawcett wrote: > > > At any rate, at a purely semantic level, unapi identifiers aren't > expansions of abbreviations. So why use abbr? > > I vote for span. Are there any arguments against span other than that the microformati tend to use abbr? If not, +1 to span, -1 to abbr. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060505/ce1096a5/attachment.htm From lists at hubmed.org Fri May 5 17:03:17 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 17:03:59 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> Message-ID: <788EDB2E-45FF-4C03-AA94-2AD5260AB5AD@hubmed.org> On 05 May 2006, at 09:34, Eric Celeste wrote: >> So what happens if, say, there's a web page with a list of items >> on it, one of which is a book that has Amazon identifier '4857632' >> and one of which is a photograph that has a local identifier >> '4857632'. If they're all marked up with class="id", how does the >> unapi server know which one you're asking for? > > Note: > >> 2. identifiers are only guaranteed to work with the unapi server >> linked in the head of the page. > > If this is true, then the fact that you are mixing amazon and photo > ids on a single page must mean that you have a single resolver that > can deal with both sets of objects. That resolver would have to be > able to make the distinction, and I bet the way the managers of > that resolver do this is by adding extra info to the identifiers > they resolve, perhaps making the Amazon ids all start with "a" (bad > idea, but stick with me) and the photo ids all start with "p". Then > their resolver will be able to tell the difference. I see what you're saying - maybe the classname should be more explicit then: 'local-id' or 'copy-id', perhaps? alf. From lists at hubmed.org Fri May 5 17:07:42 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 17:08:21 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <22dbc4ae0605051355u10a58190h9f974cea925192cb@mail.gmail.com> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <445BB51E.7040903@uwindsor.ca> <22dbc4ae0605051355u10a58190h9f974cea925192cb@mail.gmail.com> Message-ID: On 05 May 2006, at 16:55, Michael J. Giarlo wrote: > On 5/5/06, Graham Fawcett wrote: > At any rate, at a purely semantic level, unapi identifiers aren't > expansions of abbreviations. So why use abbr? > > I vote for span. > > Are there any arguments against span other than that the > microformati tend to use abbr? > > If not, +1 to span, -1 to abbr. I say +1 to both, with the same processing instructions as for microformats. If you just use span, which is the identifier in these cases?: 123456 A book about aeroplanes 123456 alf. From leftwing at alumni.rutgers.edu Fri May 5 17:17:05 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri May 5 17:18:40 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <445BB51E.7040903@uwindsor.ca> <22dbc4ae0605051355u10a58190h9f974cea925192cb@mail.gmail.com> Message-ID: <22dbc4ae0605051417p4f9f6d14w46c25db58ecb0ffb@mail.gmail.com> On 5/5/06, Alf Eaton wrote: > > > If you just use span, which is the identifier in these cases?: > > 123456 > > A book about aeroplanes > > 123456 > > If we roll with the rev-2 status quo, as I understand it, @title gives you the identifier. The PCDATA is uninteresting to unAPI. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060505/f32a4ded/attachment.htm From liu_x at lanl.gov Fri May 5 17:18:56 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 5 17:19:37 2006 Subject: [gcs-pcs-list] Re: Identifiers In-Reply-To: <788EDB2E-45FF-4C03-AA94-2AD5260AB5AD@hubmed.org> References: <1146764008.6101.72.camel@helmsdeep> <247574A3-4EBE-4CD9-8E42-86452B681BEE@hubmed.org> <788EDB2E-45FF-4C03-AA94-2AD5260AB5AD@hubmed.org> Message-ID: On Fri, 5 May 2006, Alf Eaton wrote: > > On 05 May 2006, at 09:34, Eric Celeste wrote: > >>> So what happens if, say, there's a web page with a list of items on it, >>> one of which is a book that has Amazon identifier '4857632' and one of >>> which is a photograph that has a local identifier '4857632'. If they're >>> all marked up with class="id", how does the unapi server know which one >>> you're asking for? >> >> Note: >> >>> 2. identifiers are only guaranteed to work with the unapi server linked in >>> the head of the page. >> >> If this is true, then the fact that you are mixing amazon and photo ids on >> a single page must mean that you have a single resolver that can deal with >> both sets of objects. That resolver would have to be able to make the >> distinction, and I bet the way the managers of that resolver do this is by >> adding extra info to the identifiers they resolve, perhaps making the >> Amazon ids all start with "a" (bad idea, but stick with me) and the photo >> ids all start with "p". Then their resolver will be able to tell the >> difference. > > I see what you're saying - maybe the classname should be more explicit then: > 'local-id' or 'copy-id', perhaps? Though in a slightly different context, in order to avoid namespace conflict with other usage, I advocate using "unapi-id". 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 daniel.chudnov at yale.edu Fri May 5 17:33:27 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 5 17:34:00 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> Message-ID: <20060505213327.GG28801@sildin.med.yale.edu> Alf Eaton wrote, on Fri, May 05, 2006 at 04:51:51PM -0400: > On 05 May 2006, at 14:52, Daniel Chudnov wrote: > >Alf Eaton wrote, on Fri, May 05, 2006 at 11:53:07AM -0400: > >> > >>Why do things differently to the way all the other microformats work? > > > >I don't understand the subleties of the way microformats work, so > >please spell this out. > > The rule for microformat processors is to take the inner text of the > element, unless it's an , in which case take the title element > and ignore the inner text. > > In other words: > DATA > or > anything > > tags are an exception though, because there > you're getting the data from the href attribute. Okay, thanks for this. Much like we're not doing OpenURL, nor OAI-PMH, unAPI isn't itself a microformat. Microformats and their patterns are about recognizing and processing what's in front of you... unAPI is about getting disseminations for objects whose in-hand representation is not one-to-one equivalent with the unknown, possibly diverse disseminations/representations available for it. We want downstreams to make their own decisions about how to parse whatever disseminations are available for identified objects. But to get to those, we want those apps to have to do as little work as possible to find the identified objects. If enough people voted for the span+abbr combo, that could be good, since we'd be emulating microformats' approach. But then we'd be adding this minor addition of parsing complexity (having to look in two places, and handling each slightly differently, instead of just one). Granted, that's not *really* complex. But, are people who are developing microformat-consuming apps going to add callback mechanisms to their microformat recognizers just so they can also layer in callbacks for unAPI class matches? I'd guess not - if unAPI is really simple, they can (and would more likely) just run a separate unAPI identifer xpath over the data and then do unAPI format calls in a separate loop or UI component. I think unAPI -- since it's about the API, not the microformat per se -- would be simpler if we just picked one: identifer in the @title, and optional human-display info in the text content, and only one of span/abbr. But, I'll go along with either approach if enough people weigh in one way or the other. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Fri May 5 17:06:02 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 5 17:42:37 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <445BB51E.7040903@uwindsor.ca> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <445BB51E.7040903@uwindsor.ca> Message-ID: On Fri, 5 May 2006, Graham Fawcett wrote: > > > Just my two cents, but hidden text (rather, unapi identifiers embedded in a > document, but not associated with a specific bit of text) seems a useful > case, and one that would turn up relatively quickly in real-world use. (A > gallery of book-cover images might have no text, but should be a valid unapi > use-case, no?). agree this is a valid use case. Glad that microformats said "encouraging", I think it's still ok to use empty "abbr", but not encouraged. > > If playing nicely with microformats is a long-term goal, and if microformats > has claimed abbr@title as a means of providing machine-readable equivalents > to human-readable text (which isn't unapi's goal), then I'd suggest that I am mostly thinking about a use case such as: ISBN 1234567 In those cases I think "urn:isbn:1234567" is a "machine-readable equivalents" to "ISBN 1234567". Clearly not all use cases are like this, such as your image gallery examples. > abbr@title is not the pattern to use for unapi. > At any rate, at a purely semantic level, unapi identifiers aren't expansions > of abbreviations. So why use abbr? > > I vote for span. span has its own problem, microformats uses a practice like (my understanding, Perhaps someone with better microformats knowledge can correct me): urn:isbn:1234567 But we may not want the "urn:isbn:1234567" visible to user. And in your example of image, there might be its own problem: Not sure if this is the case you intend, but I feel it's difficult to process as it stands now. So I think I understand your use case, but still seems like abbr is less evil than span. regards, xiaoming From liu_x at lanl.gov Fri May 5 19:37:45 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 5 19:38:27 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505213327.GG28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> Message-ID: sorry for going back and forth on this, as I originally suggested using "abbr". I think the discussion is not limited to span/abbr, Alf's proposal about "sth is not a trivial use case, we will end up with embarrassed case with span/abbr + href: sth or sth or other variants, clearly the neat case is still: sth and Michael J. Giarlo's use case perhaps better solved by: , though I am not sure what's best practice about img in Microformats. I also checked some microformats client library, and they are handling some of these complexities, e.g. by xpath: document.evaluate("//*[contains(@class, '"+formats[j].className+"')]", since unapi-id is a very basic descriptor of data, I imagine many use cases are possible to take advantage of these variants. This adds a layer of complexity to application development, but seems doable by microformats experience. And since "unapi-id" or "id" has to play well with other microformats such as "uri","url", it seems like a good practice to make "unapi-id" follow microformats practice. As my position is to make life easier for publisher, I would prefer we defer "id" or "unapi-id" usage to microformats, perhaps http://microformats.org/wiki/class-design-pattern ? and makes service do extra works. xiaoming On Fri, 5 May 2006, Daniel Chudnov wrote: > > Okay, thanks for this. > > Much like we're not doing OpenURL, nor OAI-PMH, unAPI isn't itself a > microformat. Microformats and their patterns are about recognizing and > processing what's in front of you... unAPI is about getting disseminations > for objects whose in-hand representation is not one-to-one equivalent with > the unknown, possibly diverse disseminations/representations available > for it. > > We want downstreams to make their own decisions about how to parse > whatever disseminations are available for identified objects. But to > get to those, we want those apps to have to do as little work as > possible to find the identified objects. > > If enough people voted for the span+abbr combo, that could be good, > since we'd be emulating microformats' approach. But then we'd be adding > this minor addition of parsing complexity (having to look in two places, > and handling each slightly differently, instead of just one). > > Granted, that's not *really* complex. But, are people who are developing > microformat-consuming apps going to add callback mechanisms to their > microformat recognizers just so they can also layer in callbacks for > unAPI class matches? I'd guess not - if unAPI is really simple, they can > (and would more likely) just run a separate unAPI identifer xpath over the > data and then do unAPI format calls in a separate loop or UI component. > > I think unAPI -- since it's about the API, not the microformat per se > -- would be simpler if we just picked one: identifer in the @title, > and optional human-display info in the text content, and only one of > span/abbr. But, I'll go along with either approach if enough people > weigh in one way or the other. > > -Dan > > > -- Xiaoming From lists at hubmed.org Fri May 5 19:55:08 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 19:58:57 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> Message-ID: <7F205078-0F3C-4C3E-85E5-EEC4F1D8A582@hubmed.org> On 05 May 2006, at 19:37, Xiaoming Liu wrote: > sorry for going back and forth on this, as I originally suggested > using "abbr". > > I think the discussion is not limited to span/abbr, Alf's proposal > about "sth is > not a trivial use case, we will end up with embarrassed case with > span/abbr + href: > > href="http://www.example.com">sth > > or > href="http://www.example.com">sth > > or other variants, clearly the neat case is still: > sth > > and Michael J. Giarlo's use case perhaps better solved by: > title="urn:isbn:..."/>, though I am not sure what's best practice > about img in Microformats. So the choice is really 'simple' vs 'microformats'. I'm happy to go with 'simple' if it's what people prefer - I can see how it would be easier. a picture Of course, you'd have to position the span to make it clear that it was associated with that particular image, if a client script inserted a button or something into the span. Just to rule out the option that was suggested a while ago, now that we're not using URIs, might this be acceptable again?: alf. From liu_x at lanl.gov Fri May 5 20:39:50 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 5 20:40:33 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <7F205078-0F3C-4C3E-85E5-EEC4F1D8A582@hubmed.org> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <7F205078-0F3C-4C3E-85E5-EEC4F1D8A582@hubmed.org> Message-ID: On Fri, 5 May 2006, Alf Eaton wrote: > > So the choice is really 'simple' vs 'microformats'. I'm happy to go with > 'simple' if it's what people prefer - I can see how it would be easier. > > a picture title="123456"/> I think the title@span pattern is not suggested by microformats? > > > > Just to rule out the option that was suggested a while ago, now that we're > not using URIs, might this be acceptable again?: > > I think , and now you can do UNAPI?id=http://blog/001 it's a valid use case in microformats. I am not sure about , can you elaborate more? 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 lists at hubmed.org Fri May 5 21:57:27 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 5 21:58:07 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <7F205078-0F3C-4C3E-85E5-EEC4F1D8A582@hubmed.org> Message-ID: On 05 May 2006, at 20:39, Xiaoming Liu wrote: > On Fri, 5 May 2006, Alf Eaton wrote: > >> >> So the choice is really 'simple' vs 'microformats'. I'm happy to >> go with 'simple' if it's what people prefer - I can see how it >> would be easier. >> >> a picture > class="copy-id" title="123456"/> > > I think the title@span pattern is not suggested by microformats? Sorry, I wasn't clear. That example was the 'simple' option, not the microformats one. >> Just to rule out the option that was suggested a while ago, now >> that we're not using URIs, might this be acceptable again?: >> >> > > I think , and now you can do > UNAPI?id=http://blog/001 > > it's a valid use case in microformats. > > I am not sure about , > can you elaborate more? Ignoring microformats and ignoring URIs, if your unapi server is at http://www.example.com/unapi then, instead of doing throughout the page, you could just have actual links: etc. alf. From fawcett at uwindsor.ca Sat May 6 10:42:52 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Sat May 6 10:44:36 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <445BB51E.7040903@uwindsor.ca> Message-ID: <445CB5EC.2050707@uwindsor.ca> Xiaoming Liu wrote: >> abbr@title is not the pattern to use for unapi. At any rate, at a >> purely semantic level, unapi identifiers aren't expansions of >> abbreviations. So why use abbr? >> >> I vote for span. > > > span has its own problem, microformats uses a practice like (my > understanding, Perhaps someone with better microformats knowledge can > correct me): > > urn:isbn:1234567 > > But we may not want the "urn:isbn:1234567" visible to user. I see. But wouldn't that only conflict for spans that have class="id"? I'm not a microformats expert, but surely they cannot have pwned all spans, and left none for us to play with! :-) > And in your example of image, there might be its own problem: > > > > Not sure if this is the case you intend, but I feel it's difficult to > process as it stands now. That's close. (I admit that the image-gallery was a bit of a straw man, but I could see things like that happening, as well as other kinds of content. UnAPI for applets, anyone?) But rather than your example, I would see: ...... where "..." is zero or more arbitrary child nodes. In other words, the identifier is always in the title. It's just easier. The redundant case urn:isbn:1234567 seems a reasonable price to pay for consistency. :-) Graham From fawcett at uwindsor.ca Sat May 6 11:26:50 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Sat May 6 11:28:29 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505213327.GG28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> Message-ID: <445CC03A.7090403@uwindsor.ca> Daniel Chudnov wrote: >I think unAPI -- since it's about the API, not the microformat per se >-- would be simpler if we just picked one: identifer in the @title, >and optional human-display info in the text content, and only one of >span/abbr. > Exactly right. The format discussion has been interesting to follow, but it does seem a bit tangential; the interesting stuff is in the services, not the microformat. Almost any of the proposed ideas would work, and none is particularly harmful. Graham From mrylander at gmail.com Sat May 6 13:23:46 2006 From: mrylander at gmail.com (Mike Rylander) Date: Sat May 6 13:25:22 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <20060505213327.GG28801@sildin.med.yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> Message-ID: On 5/5/06, Daniel Chudnov wrote: [snip] > > I think unAPI -- since it's about the API, not the microformat per se > -- would be simpler if we just picked one: identifer in the @title, > and optional human-display info in the text content, and only one of > span/abbr. But, I'll go along with either approach if enough people > weigh in one way or the other. I've stayed out of this thread mainly because I don't have any strong feelings about how the unAPI tag is built, but after absorbing everything here it seems to me that there's a clear winner based on current implementation (hidden unAPI content, use of the @title attr) and microformat recommendations (s should use text content instead of @title, and the opposite is true of ). My gut tells me that the best plan is to use an tag with the unAPI ID in the @title, a @class of (at least) 'unapi' or equivalent, and to wrap that around any text meant for human consumption (but not require any). That's a mild abuse of the semantics of , but it accomplishes the same thing as our current , and it meshes better with existing microformats, and it also allows completely hidden unAPI content without resorting to CSS hiding (by way of an empty ). So, +1 for optional text from me... > > -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- Mike Rylander mrylander@gmail.com GPLS -- PINES Development Database Developer http://open-ils.org From liu_x at lanl.gov Sat May 6 18:43:06 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Sat May 6 18:43:48 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <445CC03A.7090403@uwindsor.ca> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> Message-ID: On Sat, 6 May 2006, Graham Fawcett wrote: > Daniel Chudnov wrote: > >> I think unAPI -- since it's about the API, not the microformat per se >> -- would be simpler if we just picked one: identifer in the @title, >> and optional human-display info in the text content, and only one of >> span/abbr. > Exactly right. > > The format discussion has been interesting to follow, but it does seem a bit > tangential; the interesting stuff is in the services, not the microformat. > > Almost any of the proposed ideas would work, and none is particularly > harmful. I would consider title@span is harmful, because it doesn't play well with other microformats. e.g. we may choose to use following format in unAPI: bar When indeed "uri" is adopted, I have difficulties of combining "unapi" and "uri" bar Now in different contexts an application may either consider "foo" or "bar" is intended value, the only way out is to make foo=bar. I think this is bad pattern. Anyhow, defering to microformats completely is my first choice, because it gives us flexibility and knowledge of microformats. I would be happy to go with one of suggested pattern of microformats if there is a consensus for simplicity here; but a pattern not supported by microformats is problematic to me. xiaoming From daniel.chudnov at yale.edu Mon May 8 13:12:29 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 8 13:14:09 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> Message-ID: <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> On May 6, 2006, at 6:43 PM, Xiaoming Liu wrote: > On Sat, 6 May 2006, Graham Fawcett wrote >> >> Almost any of the proposed ideas would work, and none is >> particularly harmful. > > I would consider title@span is harmful, because it doesn't play > well with other microformats. > > e.g. we may choose to use following format in unAPI: > > bar > > When indeed "uri" is adopted, I have difficulties of combining > "unapi" and "uri" > > bar > > Now in different contexts an application may either consider "foo" > or "bar" is intended value, the only way out is to make foo=bar. I > think this is bad pattern. I don't understand this example. Shouldn't your application know enough not to add a "uri" class value if it's not a URI? If your ids are URIs, this works, and "foo" is the URI. If they're not, don't call them URIs. If they're not, and you still call "foo" a URI, and your server can still recognized "id=foo" correctly, it can still work. What am I missing? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Mon May 8 13:15:30 2006 From: lists at hubmed.org (Alf Eaton) Date: Mon May 8 13:25:04 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> Message-ID: <445F7CB2.1010200@hubmed.org> Daniel Chudnov wrote: > On May 6, 2006, at 6:43 PM, Xiaoming Liu wrote: >> On Sat, 6 May 2006, Graham Fawcett wrote >>> >>> Almost any of the proposed ideas would work, and none is particularly >>> harmful. >> >> I would consider title@span is harmful, because it doesn't play well >> with other microformats. >> >> e.g. we may choose to use following format in unAPI: >> >> bar >> >> When indeed "uri" is adopted, I have difficulties of combining "unapi" >> and "uri" >> >> bar >> >> Now in different contexts an application may either consider "foo" or >> "bar" is intended value, the only way out is to make foo=bar. I think >> this is bad pattern. > > I don't understand this example. Shouldn't your application know enough > not to add a "uri" class value if it's not a URI? > > If your ids are URIs, this works, and "foo" is the URI. If they're not, > don't call them URIs. If they're not, and you still call "foo" a URI, > and your server can still recognized "id=foo" correctly, it can still > work. What am I missing? Same as before: in bar, 'bar' is the URI for a microformats processor. It would mean you couldn't do an invisible element that's compatible with both microformats and unAPI. Although I haven't seen any real objections to using , I agree with Mike and Xiaoming, just using seems easy and most compatible. alf. From liu_x at lanl.gov Mon May 8 13:43:15 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon May 8 13:43:50 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> Message-ID: On Mon, 8 May 2006, Daniel Chudnov wrote: > > I don't understand this example. Shouldn't your application know enough not > to add a "uri" class value if it's not a URI? admits it's a bad example. > > If your ids are URIs, this works, and "foo" is the URI. If they're not, > don't call them URIs. If they're not, and you still call "foo" a URI, and > your server can still recognized "id=foo" correctly, it can still work. What > am I missing? Let me try again, with unapi spec v2, we will have ISBN: 1234567 with "uid" or other microformats classes, we will have urn:isbn:1234567x Now if we want to say "urn:isbn:1234567x" is both an "unapi-id" and "uid", we will have: urn:isbn:1234567x I think this is bad pattern because: (1) the title and enclosed text must be the same, e.g. the information is repeated, remember "Don't Repeat Yourself" (2) In my code I need use different logic for different "class names". (3) There is no convenient way of adding human-readable text now. (4) say if I am trying to hack the microformats firefox plug-in to support unAPI, it may become more difficult because we are using a completely different logic. So with title@span we make it difficult to re-mix with other microformats, and I think "multi-class" is a rather core to microformats approach [1]. [1]http://microformats.org/wiki/class-design-pattern regards, xiaoming From fawcett at uwindsor.ca Mon May 8 13:52:45 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Mon May 8 13:55:47 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <445F7CB2.1010200@hubmed.org> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> <445F7CB2.1010200@hubmed.org> Message-ID: <445F856D.3040101@uwindsor.ca> On 5/8/2006 1:15 PM, Alf Eaton wrote: > > Although I haven't seen any real objections to using , I agree with > Mike and Xiaoming, just using seems easy and most compatible. +1. I thought the microformats folk would complain about empty abbr's, but if that's not true, then it seems the easiest answer. Graham From liu_x at lanl.gov Mon May 8 14:00:44 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon May 8 14:01:20 2006 Subject: [gcs-pcs-list] unAPI update. In-Reply-To: <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> References: <2370B003-5C15-4200-91DB-C0A498445A88@yale.edu> <20060505123554.GC28801@sildin.med.yale.edu> <4AAE2275-C9CA-409D-9F0D-F8D194932906@hubmed.org> <20060505185206.GE28801@sildin.med.yale.edu> <42D72E35-05F4-4BD0-90C2-8183405D3929@hubmed.org> <20060505213327.GG28801@sildin.med.yale.edu> <445CC03A.7090403@uwindsor.ca> <2C03B050-6C65-4D91-B573-5047DB4F758B@yale.edu> Message-ID: Another nice writing about why multi-classes by Tantek, from [1] Starting of copied text ----------------------- The redundancy in XML (and other formats as well) comes from the fact that an element can have only one element name. Since microformats use attributes which take space separated sets (class, rel, rev), more than one "element name" can be given to the same piece of data, thus avoiding the need to repeat that data just because of a limitation of the syntax of the underlying metaformat. [snip] The more I switch back and forth between marking things up with microformats, and using POX (plain old XML) practices, the more I have found this problem, and am convinced that the whole "one name per element" was actually a mistake in XML (or perhaps SGML), but I'm certainly not going to attempt to "fix" either of those, preferring to instead just "Get Things Done(tm)" with microformats. end of copied test ------------------ My comment: This nice pattern can only work if we play the rule of Microformats. [1] http://microformats.org/discuss/mail/microformats-discuss/2006-April/003931.html xiaoming From daniel.chudnov at yale.edu Mon May 8 20:38:20 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon May 8 20:40:19 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr Message-ID: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> This sounds a lot like consensus. Everybody in favor of: - change from SPAN to ABBR - ABBR @title gets identifier value - ABBR text content gets optional human-display stuff (links, images, nothing, whathaveyou) - basically, there's still only "one unAPI way to do it" ...please raise your hand. If we agree on this, the rest gets easy quickly. -Dan From ross.singer at library.gatech.edu Mon May 8 22:38:15 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon May 8 22:39:50 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: <23b83f160605081938h348ff8d0k780e831882da0311@mail.gmail.com> I am fine with this. +1 On 5/8/06, Daniel Chudnov wrote: > This sounds a lot like consensus. Everybody in favor of: > > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, > images, nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" > > ...please raise your hand. If we agree on this, the rest gets easy > quickly. > > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > From ehs at pobox.com Mon May 8 23:06:17 2006 From: ehs at pobox.com (Edward Summers) Date: Mon May 8 23:07:23 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: On May 8, 2006, at 7:38 PM, Daniel Chudnov wrote: > This sounds a lot like consensus. Everybody in favor of: > > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, > images, nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" -1 I would prefer to align more closely to the uf-way myself...for better or worse. //Ed From ehs at pobox.com Mon May 8 23:23:35 2006 From: ehs at pobox.com (Edward Summers) Date: Mon May 8 23:24:40 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: <221F728A-1EE7-42F6-B23D-79C30A379B6F@pobox.com> On May 8, 2006, at 10:06 PM, Edward Summers wrote: > > -1 > > I would prefer to align more closely to the uf-way myself...for > better or worse. I don't know what I was thinking: +1 This proposal seems to be keeping the spirit of the abbr microformat just fine. My concentration is obviously failing...my apologies. //Ed From ross.singer at library.gatech.edu Mon May 8 23:30:11 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon May 8 23:31:46 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <221F728A-1EE7-42F6-B23D-79C30A379B6F@pobox.com> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> <221F728A-1EE7-42F6-B23D-79C30A379B6F@pobox.com> Message-ID: <23b83f160605082030u3b8c7b34s816153c5b50d2f65@mail.gmail.com> Remember kids: unAPI says, 'Don't do drugs' -Ross. On 5/8/06, Edward Summers wrote: > On May 8, 2006, at 10:06 PM, Edward Summers wrote: > > > > -1 > > > > I would prefer to align more closely to the uf-way myself...for > > better or worse. > > I don't know what I was thinking: > > +1 > > This proposal seems to be keeping the spirit of the abbr microformat > just fine. My concentration is obviously failing...my apologies. > > //Ed > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > From mrylander at gmail.com Mon May 8 23:59:36 2006 From: mrylander at gmail.com (Mike Rylander) Date: Tue May 9 00:01:17 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: On 5/8/06, Daniel Chudnov wrote: > This sounds a lot like consensus. Everybody in favor of: > > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, > images, nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" > > ...please raise your hand. If we agree on this, the rest gets easy > quickly. +1 > > > -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 Tue May 9 00:06:55 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 9 00:07:30 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: On Mon, 8 May 2006, Daniel Chudnov wrote: > This sounds a lot like consensus. Everybody in favor of: > > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, images, > nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" > > ...please raise your hand. If we agree on this, the rest gets easy quickly. +1 except the third item looks dubious if written into spec, I see no harm of padding "img/link" into "abbr", but perhaps should not be encouraged either. I guess individual implementation can find its own best way. xiaoming From arhyno at uwindsor.ca Tue May 9 00:20:27 2006 From: arhyno at uwindsor.ca (arhyno@uwindsor.ca) Date: Tue May 9 00:22:45 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, > images, nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" +1 art -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060509/2cff8a30/attachment.htm From leftwing at alumni.rutgers.edu Tue May 9 01:20:51 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Tue May 9 01:22:08 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <23b83f160605082030u3b8c7b34s816153c5b50d2f65@mail.gmail.co m> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> <221F728A-1EE7-42F6-B23D-79C30A379B6F@pobox.com> <23b83f160605082030u3b8c7b34s816153c5b50d2f65@mail.gmail.com> Message-ID: <6.0.1.1.2.20060508221851.068fbc60@pop.gmail.com> At 20:30 PT, 05/08/2006, Ross Singer wrote: > >Remember kids: unAPI says, 'Don't do drugs' > -1 -- unAPI is supposed to be -easy- to implement > [dchud's proposal] +1 -Mike From fawcett at uwindsor.ca Tue May 9 09:17:24 2006 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Tue May 9 09:18:21 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: <44609664.8090108@uwindsor.ca> On 08/05/2006 8:38 PM, Daniel Chudnov wrote: > This sounds a lot like consensus. Everybody in favor of: > > - change from SPAN to ABBR > - ABBR @title gets identifier value > - ABBR text content gets optional human-display stuff (links, images, > nothing, whathaveyou) > - basically, there's still only "one unAPI way to do it" +1. Graham From daniel.chudnov at yale.edu Tue May 9 09:33:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Tue May 9 09:33:41 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> Message-ID: <20060509133304.GB31672@sildin.med.yale.edu> Xiaoming Liu wrote, on Mon, May 08, 2006 at 10:06:55PM -0600: > On Mon, 8 May 2006, Daniel Chudnov wrote: > > >This sounds a lot like consensus. Everybody in favor of: > > > >- change from SPAN to ABBR > >- ABBR @title gets identifier value > >- ABBR text content gets optional human-display stuff (links, images, > >nothing, whathaveyou) > > except the third item looks dubious if written into spec, I see no harm > of padding "img/link" into "abbr", but perhaps should not be encouraged > either. I guess individual implementation can find its own best way. What should it say exactly? The current rev3 draft reads: Publishers may place anything, or nothing, inside the span. For example, a reference to the book with ISBN 123456789X might be published with a human-readable string "ISBN 123456789X" inside the span: http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html I would just replace "span" with "abbr" in this sentence. Is this problematic? -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Tue May 9 09:47:17 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Tue May 9 09:48:53 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <20060509133304.GB31672@sildin.med.yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> <20060509133304.GB31672@sildin.med.yale.edu> Message-ID: <23b83f160605090647n11f5ed48j82f56203cc4905e8@mail.gmail.com> On 5/9/06, Daniel Chudnov wrote: > > > What should it say exactly? The current rev3 draft reads: > > Publishers may place anything, or nothing, inside the span. For example, > a reference to the book with ISBN 123456789X might be published with > a human-readable string "ISBN 123456789X" inside the span: > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > I would just replace "span" with "abbr" in this sentence. Is this > problematic? I feel this is fine. -Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060509/913230ea/attachment-0001.htm From liu_x at lanl.gov Tue May 9 10:45:06 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Tue May 9 10:45:42 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: <20060509133304.GB31672@sildin.med.yale.edu> References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> <20060509133304.GB31672@sildin.med.yale.edu> Message-ID: On Tue, 9 May 2006, Daniel Chudnov wrote: > Xiaoming Liu wrote, on Mon, May 08, 2006 at 10:06:55PM -0600: >> except the third item looks dubious if written into spec, I see no harm >> of padding "img/link" into "abbr", but perhaps should not be encouraged >> either. I guess individual implementation can find its own best way. > > What should it say exactly? The current rev3 draft reads: > > Publishers may place anything, or nothing, inside the span. For example, > a reference to the book with ISBN 123456789X might be published with > a human-readable string "ISBN 123456789X" inside the span: > > http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html > > I would just replace "span" with "abbr" in this sentence. Is this > problematic? This looks fine to me. xiaoming From ehs at pobox.com Thu May 11 06:45:01 2006 From: ehs at pobox.com (Edward Summers) Date: Thu May 11 06:46:19 2006 Subject: [gcs-pcs-list] citation metadata w/ context objects Message-ID: <49B52230-E29C-476D-A042-7AEECB846575@pobox.com> Perhaps this has been there for a while but Ann Apps just mentioned over on dc-general [1] that there are now guidelines for using context objects in XHTML to provide machine parsable citations [2]. The pages itself has been available for a while, but I think these details are pretty new. //Ed [1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0605&L=dc- general&T=0&P=1128 [2] http://dublincore.org/documents/dc-citation-guidelines/ From jeremy.frumkin at oregonstate.edu Thu May 11 12:12:02 2006 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Thu May 11 12:13:49 2006 Subject: [gcs-pcs-list] Google Notebook Message-ID: Something to keep an eye on, from a recent Google press release ( http://www.google.com/intl/en/press/pressrel/new_tech.html): Google Notebook from Google Labs Google Notebook is a simple way for users to save and organize their thoughts when conducting research online. This personal browser tool permits users to clip text, images, and links from the pages they're browsing, save them to an online "notebook" that is accessible from any computer, and share them with others. Google Notebook is an interactive scratch pad for every website a user visits, offering a single online location to collect web findings without having to leave the browser window. For example, if a user were planning a vacation, she could clip the most relevant materials on the pages she visits and add personal notes to help organize all of her research. Users can make their Google Notebook public and share the notes they've taken with others. As a result, the time and effort put into their research can be harnessed by the online community as a whole. Google Notebook will be available next week from Google Labs at http://www.google.com/notebook. -- jaf =============================================== Jeremy Frumkin The Gray Chair for Innovative Library Services 121 The Valley Library, Oregon State University Corvallis OR 97331-4501 Jeremy.Frumkin@oregonstate.edu 541.737.9928 541.737.3453 (Fax) 541.230.4483 (Cell) =============================================== " Without ambition one starts nothing. Without work one finishes nothing. " - Emerson From yee at berkeley.edu Thu May 11 12:17:37 2006 From: yee at berkeley.edu (Raymond Yee) Date: Thu May 11 12:21:24 2006 Subject: [gcs-pcs-list] Google Notebook In-Reply-To: References: Message-ID: <446363A1.4080704@berkeley.edu> I'll be curious to see what APIs will be available to push and pull information in and out of the Notebooks. -Raymond Jeremy Frumkin wrote: > Something to keep an eye on, from a recent Google press release ( > http://www.google.com/intl/en/press/pressrel/new_tech.html): > > Google Notebook from Google Labs > Google Notebook is a simple way for users to save and organize their > thoughts when conducting research online. This personal browser tool permits > users to clip text, images, and links from the pages they're browsing, save > them to an online "notebook" that is accessible from any computer, and share > them with others. > > Google Notebook is an interactive scratch pad for every website a user > visits, offering a single online location to collect web findings without > having to leave the browser window. For example, if a user were planning a > vacation, she could clip the most relevant materials on the pages she visits > and add personal notes to help organize all of her research. > > Users can make their Google Notebook public and share the notes they've > taken with others. As a result, the time and effort put into their research > can be harnessed by the online community as a whole. > > Google Notebook will be available next week from Google Labs at > http://www.google.com/notebook. > > > > -- jaf > > =============================================== > Jeremy Frumkin > The Gray Chair for Innovative Library Services > 121 The Valley Library, Oregon State University > Corvallis OR 97331-4501 > > Jeremy.Frumkin@oregonstate.edu > > 541.737.9928 > 541.737.3453 (Fax) > 541.230.4483 (Cell) > =============================================== > " Without ambition one starts nothing. Without work one finishes nothing. " > - Emerson > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > -- -- Raymond Yee 2195 Hearst (250-22) Technology Architect UC Berkeley Interactive University Project Berkeley, CA 94720-3810 yee@uclink.berkeley.edu 510-642-0476 (work) http://iu.berkeley.edu/rdhyee 413-541-5683 (fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3166 bytes Desc: S/MIME Cryptographic Signature Url : http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060511/8912fb27/smime.bin From daniel.chudnov at yale.edu Thu May 11 13:19:49 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 11 13:21:57 2006 Subject: [gcs-pcs-list] unAPI issue vote: span vs. abbr In-Reply-To: References: <2E1A93F7-A237-4F8F-913F-3238D20B9ECA@yale.edu> <20060509133304.GB31672@sildin.med.yale.edu> Message-ID: On May 9, 2006, at 10:45 AM, Xiaoming Liu wrote: > On Tue, 9 May 2006, Daniel Chudnov wrote: > >> Xiaoming Liu wrote, on Mon, May 08, 2006 at 10:06:55PM -0600: >>> except the third item looks dubious if written into spec, I see >>> no harm >>> of padding "img/link" into "abbr", but perhaps should not be >>> encouraged >>> either. I guess individual implementation can find its own best way. >> >> What should it say exactly? The current rev3 draft reads: >> >> Publishers may place anything, or nothing, inside the span. For >> example, >> a reference to the book with ISBN 123456789X might be published with >> a human-readable string "ISBN 123456789X" inside the span: >> >> http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html >> >> I would just replace "span" with "abbr" in this sentence. Is this >> problematic? > > This looks fine to me. Okay, then, let us consider this issue closed for rev3. I've rewritten the rewrite to accomodate this. http://curtis.med.yale.edu/dchud/unapi/unapi-rev3-rewrite.html ...which leads to the last two open issues. -Dan From daniel.chudnov at yale.edu Thu May 11 13:29:04 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 11 13:31:09 2006 Subject: [gcs-pcs-list] unAPI issue vote: class name "unapi-id" Message-ID: <6F80ED83-1E55-443B-BD79-C8835828580C@yale.edu> Rewriting the spec required a choice on the new class name. For now, it uses Xiaoming's suggested "unapi-id". Please vote class="unapi-id" up or down. Thanks, -Dan From daniel.chudnov at yale.edu Thu May 11 13:33:24 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 11 13:35:25 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <20060502165622.GD25858@sildin.med.yale.edu> References: <20060502165622.GD25858@sildin.med.yale.edu> Message-ID: <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> On May 2, 2006, at 12:56 PM, Daniel Chudnov wrote: > It was suggested offline to consider changing the value of the unAPI > LINK element's rel attribute from "meta" to something more specific > like > "unapi.server", e.g.: > > > > I'm not sure what the right thing or best practice w/r/to rel types > not > in the HTML spec is. This received only one comment. If I'm not mistaken, to follow the HTML spec's "SHOULD" suggestion, to use anything not backed by a profile wouldn't be quite up to snuff. On the other hand, it doesn't say "MUST". Our choices, then, are: link rel="meta" (as at present) link rel="unapi" (more specific) link rel="unapi-server" (even more specific) link rel="unapi1" (allows for both possible growth and more typos :) I can see the value of rel="unapi[something|nothing]" but any of these options should work. Given the lack of previous responses, please speak up now if you prefer anything other than "meta". -Dan From leftwing at alumni.rutgers.edu Thu May 11 13:35:57 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Thu May 11 13:37:30 2006 Subject: [gcs-pcs-list] unAPI issue vote: class name "unapi-id" In-Reply-To: <6F80ED83-1E55-443B-BD79-C8835828580C@yale.edu> References: <6F80ED83-1E55-443B-BD79-C8835828580C@yale.edu> Message-ID: <22dbc4ae0605111035p2c76fedau7017833d335b24bd@mail.gmail.com> On 5/11/06, Daniel Chudnov wrote: > > Rewriting the spec required a choice on the new class name. For now, > it uses Xiaoming's suggested "unapi-id". > > Please vote class="unapi-id" up or down. +1 -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060511/b0165964/attachment.htm From leftwing at alumni.rutgers.edu Thu May 11 13:39:32 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Thu May 11 13:41:07 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> References: <20060502165622.GD25858@sildin.med.yale.edu> <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> Message-ID: <22dbc4ae0605111039v2a60f939g2bbc575b18865fb2@mail.gmail.com> On 5/11/06, Daniel Chudnov wrote: > > I can see the value of rel="unapi[something|nothing]" but any of > these options should work. Given the lack of previous responses, > please speak up now if you prefer anything other than "meta". As the sole voter last time, I'll be sticking with my previous vote of a +1 for "unapi.server". I would have trouble defending that choice against the others, though. -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060511/68b126e1/attachment-0001.htm From lists at hubmed.org Thu May 11 13:46:26 2006 From: lists at hubmed.org (Alf Eaton) Date: Thu May 11 13:50:18 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> References: <20060502165622.GD25858@sildin.med.yale.edu> <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> Message-ID: <686A0900-2919-489E-83E4-ACB4A01A88E8@hubmed.org> On 11 May 2006, at 13:33, Daniel Chudnov wrote: > On May 2, 2006, at 12:56 PM, Daniel Chudnov wrote: > >> It was suggested offline to consider changing the value of the unAPI >> LINK element's rel attribute from "meta" to something more >> specific like >> "unapi.server", e.g.: >> >> >> >> I'm not sure what the right thing or best practice w/r/to rel >> types not >> in the HTML spec is. > > This received only one comment. If I'm not mistaken, to follow the > HTML spec's "SHOULD" suggestion, to use anything not backed by a > profile wouldn't be quite up to snuff. On the other hand, it > doesn't say "MUST". > > Our choices, then, are: > > link rel="meta" (as at present) > link rel="unapi" (more specific) > link rel="unapi-server" (even more specific) > link rel="unapi1" (allows for both possible growth and more typos :) Don't forget if it's "meta" there'll be a "type" in there as well, which could be something like "application/unapi+xml". alf. From ross.singer at library.gatech.edu Thu May 11 13:55:13 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu May 11 13:56:49 2006 Subject: [gcs-pcs-list] Google Notebook In-Reply-To: <446363A1.4080704@berkeley.edu> References: <446363A1.4080704@berkeley.edu> Message-ID: <23b83f160605111055l60a6ba4g89434224d541b0a0@mail.gmail.com> I imagine they will be using gData. -Ross. On 5/11/06, Raymond Yee wrote: > > I'll be curious to see what APIs will be available to push and pull > information in and out of the Notebooks. > > -Raymond > > Jeremy Frumkin wrote: > > Something to keep an eye on, from a recent Google press release ( > > http://www.google.com/intl/en/press/pressrel/new_tech.html): > > > > Google Notebook from Google Labs > > Google Notebook is a simple way for users to save and organize their > > thoughts when conducting research online. This personal browser tool > permits > > users to clip text, images, and links from the pages they're browsing, > save > > them to an online "notebook" that is accessible from any computer, and > share > > them with others. > > > > Google Notebook is an interactive scratch pad for every website a user > > visits, offering a single online location to collect web findings > without > > having to leave the browser window. For example, if a user were planning > a > > vacation, she could clip the most relevant materials on the pages she > visits > > and add personal notes to help organize all of her research. > > > > Users can make their Google Notebook public and share the notes they've > > taken with others. As a result, the time and effort put into their > research > > can be harnessed by the online community as a whole. > > > > Google Notebook will be available next week from Google Labs at > > http://www.google.com/notebook. > > > > > > > > -- jaf > > > > =============================================== > > Jeremy Frumkin > > The Gray Chair for Innovative Library Services > > 121 The Valley Library, Oregon State University > > Corvallis OR 97331-4501 > > > > Jeremy.Frumkin@oregonstate.edu > > > > 541.737.9928 > > 541.737.3453 (Fax) > > 541.230.4483 (Cell) > > =============================================== > > " Without ambition one starts nothing. Without work one finishes > nothing. " > > - Emerson > > > > _______________________________________________ > > gcs-pcs-list mailing list > > gcs-pcs-list@cipolo.med.yale.edu > > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > > -- > -- > Raymond Yee 2195 Hearst (250-22) > Technology Architect UC Berkeley > Interactive University Project Berkeley, CA 94720-3810 > yee@uclink.berkeley.edu 510-642-0476 (work) > http://iu.berkeley.edu/rdhyee 413-541-5683 (fax) > > > > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060511/7aa35928/attachment.htm From daniel.chudnov at yale.edu Thu May 11 13:58:34 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 11 14:00:50 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <686A0900-2919-489E-83E4-ACB4A01A88E8@hubmed.org> References: <20060502165622.GD25858@sildin.med.yale.edu> <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> <686A0900-2919-489E-83E4-ACB4A01A88E8@hubmed.org> Message-ID: <1BBF71D4-502B-4E40-A942-A3FA7051EC1B@yale.edu> On May 11, 2006, at 1:46 PM, Alf Eaton wrote: > On 11 May 2006, at 13:33, Daniel Chudnov wrote: >> On May 2, 2006, at 12:56 PM, Daniel Chudnov wrote: >> >>> It was suggested offline to consider changing the value of the unAPI >>> LINK element's rel attribute from "meta" to something more >>> specific like >>> "unapi.server", e.g.: >>> >>> >>> >>> I'm not sure what the right thing or best practice w/r/to rel >>> types not >>> in the HTML spec is. >> >> This received only one comment. If I'm not mistaken, to follow >> the HTML spec's "SHOULD" suggestion, to use anything not backed by >> a profile wouldn't be quite up to snuff. On the other hand, it >> doesn't say "MUST". >> >> Our choices, then, are: >> >> link rel="meta" (as at present) >> link rel="unapi" (more specific) >> link rel="unapi-server" (even more specific) >> link rel="unapi1" (allows for both possible growth and more typos :) > > Don't forget if it's "meta" there'll be a "type" in there as well, > which could be something like "application/unapi+xml". The current spec indicates 'type="application/xml"'. I'm not suggesting that we change that. Something I found with developing against another newish something +xml media type recently was that browsers may ask how to display it. By just using application/xml, browsers should be able to figure it out and render it nicely, and we don't have to take extra steps to "manage" a new mimetype. -Dan From liu_x at lanl.gov Thu May 11 14:57:03 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Thu May 11 14:57:33 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> References: <20060502165622.GD25858@sildin.med.yale.edu> <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> Message-ID: On Thu, 11 May 2006, Daniel Chudnov wrote: > On May 2, 2006, at 12:56 PM, Daniel Chudnov wrote: > >> It was suggested offline to consider changing the value of the unAPI >> LINK element's rel attribute from "meta" to something more specific like >> "unapi.server", e.g.: >> >> >> >> I'm not sure what the right thing or best practice w/r/to rel types not >> in the HTML spec is. > > This received only one comment. If I'm not mistaken, to follow the HTML > spec's "SHOULD" suggestion, to use anything not backed by a profile wouldn't > be quite up to snuff. On the other hand, it doesn't say "MUST". > > Our choices, then, are: > > link rel="meta" (as at present) > link rel="unapi" (more specific) > link rel="unapi-server" (even more specific) > link rel="unapi1" (allows for both possible growth and more typos :) > > I can see the value of rel="unapi[something|nothing]" but any of these > options should work. Given the lack of previous responses, please speak up > now if you prefer anything other than "meta". > With link rel="meta" we have to use "title" to identify "unAPI", which resonates same problem in title@span, in HTML, title@link is defined as: The title attribute may be set for both A and LINK to add information about the nature of a link. This information may be spoken by a user agent, rendered as a tool tip, cause a change in cursor image, etc. so it seems like a good practice to avoid using "rel=meta &title=unAPI". The suggestion of "unapi.server" or "unapi-server" looks good to me, and I think we should use same style for id too. Since microformats uses a "-" style [1], I like the idea of using "unapi-server" and "unapi-id" respectively. xiaoming [1] http://microformats.org/wiki/existing-classes From daniel.chudnov at yale.edu Thu May 11 15:03:38 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 11 15:05:46 2006 Subject: [gcs-pcs-list] unAPI issue: change link @rel value? In-Reply-To: References: <20060502165622.GD25858@sildin.med.yale.edu> <6C1598CA-CC1D-4F88-A899-A07FCC787E84@yale.edu> Message-ID: <956AFD1E-06B5-4965-8CBD-B4F20C1EC118@yale.edu> On May 11, 2006, at 2:57 PM, Xiaoming Liu wrote: > The suggestion of "unapi.server" or "unapi-server" looks good to > me, and I think we should use same style for id too. Since > microformats uses a "-" style [1], I like the idea of using "unapi- > server" and "unapi-id" respectively. Sounds good to me. -Dan From daniel.chudnov at yale.edu Thu May 18 20:41:28 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 18 20:43:06 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). Message-ID: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> So it's, um, a month late. But, here's unAPI revision 3: http://unapi.info/specs/unapi-revision-3.html With no further comments on the last issues, they're now closed, as is the whole revision 3 issue list. (!). I have not yet changed the page at unapi.info, or posted a link at unapi.info/news. Please take a look at the link above and review that the changes we agreed to are properly reflected in the new revision. Since the last draft/rewrite update, changes include: - Added Godmar Back and Eric Celeste to the list of Contributors (Note to all - the intention and goal is that *everyone* who has ever contributed to the unAPI development discussion on gcs-pcs-list should be listed on the document as a contributor. If anyone feels an additional name should be added, or if your name is there and you would like it to be changed or removed, please let me know.) - Changed link[@rel='meta'] to link[@rel='unapi-server'] throughout - Added links to previous versions (fulfilling another to-do/issue) - Minor formatting tweaks I'll wait for at least 2-3 folks to confirm that it looks correct and is ready to go before updating the home page and the links, and before posting a news item. Many thanks to everyone who has contributed to this project! It's been a long couple of months, but, if you compare the latest version to its predecessors, you'll surely agree that it's come a long way and is much better for everyone's participation. -Dan From ross.singer at library.gatech.edu Thu May 18 22:37:38 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Thu May 18 22:39:15 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> Message-ID: <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> I realize that it's closed for discussion, but the microformat example in that doc looks so semantically wrong. Honestly, it seems that the title and the innerHTML are reversed. Does anybody else share this feeling? Or am I off-base in my interpretation of the ABBR tag? I am asking that in a "I don't really care how microformats.org handles the situation; more how the W3C views it" way. -Ross On 5/18/06, Daniel Chudnov wrote: > So it's, um, a month late. But, here's unAPI revision 3: > > http://unapi.info/specs/unapi-revision-3.html > > With no further comments on the last issues, they're now closed, as > is the whole revision 3 issue list. (!). > > I have not yet changed the page at unapi.info, or posted a link at > unapi.info/news. Please take a look at the link above and review > that the changes we agreed to are properly reflected in the new > revision. > > Since the last draft/rewrite update, changes include: > > - Added Godmar Back and Eric Celeste to the list of Contributors > > (Note to all - the intention and goal is that *everyone* who has > ever contributed to the unAPI development discussion on gcs-pcs-list > should be listed on the document as a contributor. If anyone feels > an additional name should be added, or if your name is there and you > would like it to be changed or removed, please let me know.) > > - Changed link[@rel='meta'] to link[@rel='unapi-server'] throughout > > - Added links to previous versions (fulfilling another to-do/issue) > > - Minor formatting tweaks > > > I'll wait for at least 2-3 folks to confirm that it looks correct and > is ready to go before updating the home page and the links, and > before posting a news item. > > > Many thanks to everyone who has contributed to this project! It's > been a long couple of months, but, if you compare the latest version > to its predecessors, you'll surely agree that it's come a long way > and is much better for everyone's participation. > > -Dan > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > > From daniel.chudnov at yale.edu Thu May 18 23:50:30 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu May 18 23:52:05 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> Message-ID: <72B93048-1261-442F-86BB-F19C26F18895@yale.edu> On May 18, 2006, at 10:37 PM, Ross Singer wrote: > I realize that it's closed for discussion, but the microformat example > in that doc looks so semantically wrong. Honestly, it seems that the > title and the innerHTML are reversed. > > Does anybody else share this feeling? Or am I off-base in my > interpretation of the ABBR tag? I am asking that in a "I don't really > care how microformats.org handles the situation; more how the W3C > views it" way. It does look kind of screwy, but, a lot of people have headed toward this approach, so, for this revision, it's what it is. At present the only real open issue for the final version is Phillip/ Alf's "why don't we just use regular anchor links?" We can still consider that as another option. For now, though, this revision, at least, is done. -Dan From leftwing at alumni.rutgers.edu Fri May 19 02:02:22 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri May 19 02:03:55 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> Message-ID: <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> At 17:41 PT, 05/18/2006, Daniel Chudnov wrote: > >So it's, um, a month late. But, here's unAPI revision 3: [...] >I have not yet changed the page at unapi.info, or posted a link at >unapi.info/news. Please take a look at the link above and review >that the changes we agreed to are properly reflected in the new >revision. > Looks like you got it all, Dan. dchud++ -Mike From lists at hubmed.org Fri May 19 11:20:31 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 19 11:31:24 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <72B93048-1261-442F-86BB-F19C26F18895@yale.edu> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> <72B93048-1261-442F-86BB-F19C26F18895@yale.edu> Message-ID: <446DE23F.5040605@hubmed.org> Daniel Chudnov wrote: > At present the only real open issue for the final version is > Phillip/Alf's "why don't we just use regular anchor links?" We can > still consider that as another option. > I think I've argued myself out of this now. I can't remember exactly what the arguments were, but I know I was convinced at the time :-) Also, a processor can insert an anchor link if it wants to anyway. alf. From daniel.chudnov at yale.edu Fri May 19 12:22:48 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 19 12:23:21 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> Message-ID: <20060519162248.GF7253@sildin.med.yale.edu> Based on this and private comments, unAPI revision 3 is live: http://unapi.info/ http://unapi.info/specs/ http://unapi.info/news/archives/12 Thanks again, everyone! Now, time to update that code... :) -Dan Michael J. Giarlo wrote, on Thu, May 18, 2006 at 11:02:22PM -0700: > At 17:41 PT, 05/18/2006, Daniel Chudnov wrote: > > > >I have not yet changed the page at unapi.info, or posted a link at > >unapi.info/news. Please take a look at the link above and review > >that the changes we agreed to are properly reflected in the new > >revision. > > > > Looks like you got it all, Dan. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri May 19 13:57:22 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 19 14:07:48 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <20060519162248.GF7253@sildin.med.yale.edu> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> Message-ID: <446E0702.3030006@hubmed.org> Daniel Chudnov wrote: > Based on this and private comments, unAPI revision 3 is live: > > http://unapi.info/ > http://unapi.info/specs/ > http://unapi.info/news/archives/12 > > Thanks again, everyone! Now, time to update that code... :) I've got this working on HubMed now: the base URL is http://www.hubmed.org/unapi.cgi and it takes ids in the form info:pmid/1234567 Only one implementation question came up, which is: When a request is made for an id in a format which is not available, and the status returned is '406 Not Acceptable', should the server return a list of formats that are available for that id? alf. From leftwing at alumni.rutgers.edu Fri May 19 14:22:32 2006 From: leftwing at alumni.rutgers.edu (Michael J. Giarlo) Date: Fri May 19 14:24:59 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <446E0702.3030006@hubmed.org> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> <446E0702.3030006@hubmed.org> Message-ID: <22dbc4ae0605191122t530375e5s9b48d1651714100e@mail.gmail.com> On 5/19/06, Alf Eaton wrote: > > > I've got this working on HubMed now: the base URL is > http://www.hubmed.org/unapi.cgi > Ditto on the unAPI WordPress plug-in: http://staff.washington.edu/leftwing/wordpress/2006/05/19/unapi-revision-3-plug-in-for-wordpress/ Base URL is http://staff.washington.edu/leftwing/wordpress/unapi.php -Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060519/c78f3f1a/attachment.htm From daniel.chudnov at yale.edu Fri May 19 14:40:44 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 19 14:41:16 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <446E0702.3030006@hubmed.org> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> <446E0702.3030006@hubmed.org> Message-ID: <20060519184043.GH7253@sildin.med.yale.edu> Alf Eaton wrote, on Fri, May 19, 2006 at 01:57:22PM -0400: > > I've got this working on HubMed now: the base URL is > http://www.hubmed.org/unapi.cgi > and it takes ids in the form info:pmid/1234567 Cool - the id requests seem to be returning format lists, but I'm getting server errors when I pass in formats, too. Is application/mods+xml an approved mime type? Or do mime types even get "approved"? > Only one implementation question came up, which is: > > When a request is made for an id in a format which is not available, and > the status returned is '406 Not Acceptable', should the server return a > list of formats that are available for that id? A similar question was discussed in the context of 404 responses (should they return an empty formats list?). Thread starts here: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-March/000635.html It didn't lead to much deep discussion, and we defaulted to specifying nothing for the time being. I'll these to the list of open questions for the final version. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri May 19 14:39:52 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 19 14:49:48 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <20060519184043.GH7253@sildin.med.yale.edu> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> <446E0702.3030006@hubmed.org> <20060519184043.GH7253@sildin.med.yale.edu> Message-ID: <446E10F8.7030903@hubmed.org> Daniel Chudnov wrote: > Alf Eaton wrote, on Fri, May 19, 2006 at 01:57:22PM -0400: >> I've got this working on HubMed now: the base URL is >> http://www.hubmed.org/unapi.cgi >> and it takes ids in the form info:pmid/1234567 > > Cool - the id requests seem to be returning format lists, but I'm > getting server errors when I pass in formats, too. That might have just been temporary, I've been breaking things. > Is application/mods+xml an approved mime type? Or do mime types > even get "approved"? They do get approved (they can be application/x-whatever until then), but I might have just made mods+xml up, I can't find a reference to it anywhere official. alf. From liu_x at lanl.gov Fri May 19 14:59:50 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Fri May 19 15:00:11 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <446E10F8.7030903@hubmed.org> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> <446E0702.3030006@hubmed.org> <20060519184043.GH7253@sildin.med.yale.edu> <446E10F8.7030903@hubmed.org> Message-ID: On Fri, 19 May 2006, Alf Eaton wrote: > >> Is application/mods+xml an approved mime type? Or do mime types >> even get "approved"? > > They do get approved (they can be application/x-whatever until then), but I > might have just made mods+xml up, I can't find a reference to it anywhere > official. > The offical mimetype registry is under http://www.iana.org/assignments/media-types/ I don't think mods is in the list. xiaoming From daniel.chudnov at yale.edu Fri May 19 15:28:43 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri May 19 15:29:14 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <22dbc4ae0605191122t530375e5s9b48d1651714100e@mail.gmail.com> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <6.0.1.1.2.20060518230142.045c5e50@pop.gmail.com> <20060519162248.GF7253@sildin.med.yale.edu> <446E0702.3030006@hubmed.org> <22dbc4ae0605191122t530375e5s9b48d1651714100e@mail.gmail.com> Message-ID: <20060519192842.GL7253@sildin.med.yale.edu> Michael J. Giarlo wrote, on Fri, May 19, 2006 at 11:22:32AM -0700: > Ditto on the unAPI WordPress plug-in: > > http://staff.washington.edu/leftwing/wordpress/2006/05/19/unapi-revision-3-plug-in-for-wordpress/ > > Base URL is http://staff.washington.edu/leftwing/wordpress/unapi.php I've installed this updated wordpress plugin at http://unapi.info/news/. http://unapi.info/news/archives/13 ...which is a blog posting about the plugin, which is followed by another blog entry about HubMed's implementation. :) OPA is updated, as well: http://opa.onebiglibrary.net/?id=urn:isbn:0521660653 Update your code, win a blog entry at unapi.info! :P -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Fri May 19 19:45:54 2006 From: lists at hubmed.org (Alf Eaton) Date: Fri May 19 19:49:43 2006 Subject: [gcs-pcs-list] Retrieving citation data for URIs Message-ID: <41A3C049-C8E2-4F89-85E7-F393E102361D@hubmed.org> Connotea developer Ben Lund gave a talk at XTech recently and basically described one of the main uses for unAPI (without mentioning it by name) - and asked for a citation microformat too: http://blogs.nature.com/wp/nascent/Ben-Lund-XTech-2006-Slides.pdf I set up a small wiki a few weeks ago to investigate the existing methods of retrieving citation metadata for an identifier. If anyone can add to it, that would be great: http://metamine.jot.com/ alf. From liu_x at lanl.gov Sat May 20 00:34:15 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Sat May 20 00:36:04 2006 Subject: [gcs-pcs-list] unAPI revision 3. (!). In-Reply-To: <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> References: <80384010-2BE9-4DC4-AF72-582055EFD94C@yale.edu> <23b83f160605181937p516fa936v6e4ccacef27ea49@mail.gmail.com> Message-ID: <446E9C47.50907@lanl.gov> Ross Singer wrote: > I realize that it's closed for discussion, but the microformat example > in that doc looks so semantically wrong. Honestly, it seems that the > title and the innerHTML are reversed. > > Does anybody else share this feeling? Or am I off-base in my > interpretation of the ABBR tag? I am asking that in a "I don't really > care how microformats.org handles the situation; more how the W3C > views it" way. The uf list just happens to have a discussion of RDFa [1], which actually proposes using "meta" tag to solve same issue of embedding machine-readable data: May 8th at 10am More details are available in uf list [2]. IMO the usage of "abbr" is indeed a stretch of W3C definition, however within the existing framework microformats has chosen a reasonably good approach. [1] http://www.w3.org/TR/2006/WD-xhtml-rdfa-primer-20060516/ [2] http://microformats.org/discuss/mail/microformats-discuss/2006-May/004142.html xiaoming > > -Ross > > On 5/18/06, Daniel Chudnov wrote: >> So it's, um, a month late. But, here's unAPI revision 3: >> >> http://unapi.info/specs/unapi-revision-3.html >> >> With no further comments on the last issues, they're now closed, as >> is the whole revision 3 issue list. (!). >> >> I have not yet changed the page at unapi.info, or posted a link at >> unapi.info/news. Please take a look at the link above and review >> that the changes we agreed to are properly reflected in the new >> revision. >> >> Since the last draft/rewrite update, changes include: >> >> - Added Godmar Back and Eric Celeste to the list of Contributors >> >> (Note to all - the intention and goal is that *everyone* who has >> ever contributed to the unAPI development discussion on gcs-pcs-list >> should be listed on the document as a contributor. If anyone feels >> an additional name should be added, or if your name is there and you >> would like it to be changed or removed, please let me know.) >> >> - Changed link[@rel='meta'] to link[@rel='unapi-server'] throughout >> >> - Added links to previous versions (fulfilling another to-do/issue) >> >> - Minor formatting tweaks >> >> >> I'll wait for at least 2-3 folks to confirm that it looks correct and >> is ready to go before updating the home page and the links, and >> before posting a news item. >> >> >> Many thanks to everyone who has contributed to this project! It's >> been a long couple of months, but, if you compare the latest version >> to its predecessors, you'll surely agree that it's come a long way >> and is much better for everyone's participation. >> >> -Dan >> _______________________________________________ >> 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 daniel.chudnov at yale.edu Sun May 21 10:33:21 2006 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun May 21 10:36:07 2006 Subject: [gcs-pcs-list] Retrieving citation data for URIs In-Reply-To: <41A3C049-C8E2-4F89-85E7-F393E102361D@hubmed.org> References: <41A3C049-C8E2-4F89-85E7-F393E102361D@hubmed.org> Message-ID: <230B8FFD-F5AB-46B4-9AD3-FC02D937C072@yale.edu> On May 19, 2006, at 7:45 PM, Alf Eaton wrote: > Connotea developer Ben Lund gave a talk at XTech recently and > basically described one of the main uses for unAPI (without > mentioning it by name) - and asked for a citation microformat too: > http://blogs.nature.com/wp/nascent/Ben-Lund-XTech-2006-Slides.pdf Looks like a great talk. Perhaps someone from NPG subscribed to this list might consider telling us whether they feel unAPI might or might not serve the purpose described, and if not, why not. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From liu_x at lanl.gov Mon May 22 12:52:23 2006 From: liu_x at lanl.gov (Xiaoming Liu) Date: Mon May 22 12:52:50 2006 Subject: [gcs-pcs-list] a wiki page for existing formats in unAPI Message-ID: following an earlier thread [1], I created a wiki page to list existing formats used by unAPI services: http://unapi.stikipad.com welcome to update the page. [1] http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/2006-May/000806.html -- Xiaoming