From daniel.chudnov at yale.edu Thu Dec 1 17:37:31 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Dec 1 17:37:38 2005 Subject: [gcs-pcs-list] Fyi: Code4lib 2006 Call for Proposals Message-ID: <20051201223731.GE25219@curtis.med.yale.edu> Fyi. Ideally, a perfect place to discuss the kinds of things we discuss here. -Dan ----- Forwarded message from Jeremy Frumkin ----- Date: Thu, 01 Dec 2005 13:50:36 -0800 From: Jeremy Frumkin Subject: Code4lib 2006 Call for Proposals Call for proposals - Code4lib 2006 We are now accepting proposals for prepared talks for Code4lib 2006. [1] Code4lib 2006 is a loosely structured conference for library technologists to commune, gather/create/share ideas and software, be inspired, and forge collaborations. It is also an outgrowth of the Access HackFest, wrapped into a conference-ish format. It is *the* event for technologists building digital libraries and digital information systems, tools, and software. At least six time slots will be available for prepared talks. We will choose from among the proposals based on diversity of topics, usefulness, wow factor, and potential impact. Proposals of 75 words or less are being accepted for review now. Please send your name, email address, and proposal to code4libcon. [2] We cannot accept every prepared talk proposal, but multiple lightning talk sessions will provide everyone who wishes to present with ample opportunity to show off. The proposal deadline is January 2, 2006, and proposers will be notified by January 9, 2006. Prepared Talk Information Prepared talks are 20 minutes, and must center on "tools" (some cool new software, software library or integration platform), "specs" (how to get the most out of some protocols, or proposals for new ones), or "challenges" (One or more big problems we should collectively address). We will evaluate proposals on criteria of usefulness, newness, geekiness, and diversity of topics. [1] http://www.code4lib.org/2006 [2] https://lists.gatech.edu/sympa/info/code4libcon Again, proposals should be sent to [2]. ----- End forwarded message ----- -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Dec 2 15:16:53 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Dec 2 15:16:58 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI Message-ID: <20051202201653.GM25219@curtis.med.yale.edu> I keep getting stuck on the COinS-PMH requirements of COinS (OpenURL) and OAI-PMH. I think these will keep it from succeeding at all. What I want is a way that *anybody* can implement the following functions quickly, in javascript/dhtml or any other language: - for identified content items on any HTML page, - find out what kinds of "records" are available for one or more of them, and - get one or more of those record kinds for one or more of the items. If we simplified unAPI further, it might look like: - "identified" items are those with "class='identifier'" elements on them; the content of the element with that attribute/value pair is the identifier for that item. - we retain the link tag, but specify "unapi" and a base url of "http://blah.blah.blah/blah/blah/unapi" *instead* of "COinS-PMH" and a pseudo-or-real OAI-PMH service that supports ListMetadataFormats and GetRecord. - /unapi URIs must respond to several kinds of GETs: - /unapi/formats (formats supported site-wide) - /unapi/identifier/formats (formats for a given item) - /unapi/identifier/format (a specific record format for that iitem) Then we specify a number of "bindings", i.e. ways to implement unapi using different underlying tools/protocols: - COinS/OAI-PMH: as before, with the differences that COinS also get a class='identifier' around the actual identifier, and the unapi calls map to OAI-PMH calls that filter out the OAI wrapper stuff and just return metadata - Atom: the element from hAtom that gets the id attribute also gets a class='attribute'. then the unapi calls just map to the same responses you'd get from Atom calls to GET that identifier, with the atom wrapper stuff elided. - SRW/U: the listformats/getrecord bit is implemented using SRW/U with SRW/u wrapper bits elided and formats list from the explain response; the get calls are searches by identifier with wrapper stuff elided. - OpenSearch: similar to SRW/U in that the formats list comes from the opensearch description response and the getrecords just search on identifier and strip response RSS wrapper bits. I think this might scale to World Domination (tm). -dchud -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Dec 2 15:22:12 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Dec 2 15:22:16 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: <20051202202212.GN25219@curtis.med.yale.edu> Daniel Chudnov wrote, on Fri, Dec 02, 2005 at 03:16:53PM -0500: > Then we specify a number of "bindings", i.e. ways to implement unapi > using different underlying tools/protocols: Ach. Did I say "specify"? I meant "suggest." Really, I did. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Fri Dec 2 16:04:33 2005 From: eric at openly.com (Eric Hellman) Date: Fri Dec 2 16:04:40 2005 Subject: [gcs-pcs-list] OpenURL Referrer an Firefox 1..5 Message-ID: the changes to the install and update files needed to convince Firefox 1.5 to run OpenURL Referrer have been made and are available now at http://www.openly.com/openurlref/ -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From eric at openly.com Fri Dec 2 16:14:22 2005 From: eric at openly.com (Eric Hellman) Date: Fri Dec 2 16:14:33 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: Dan, Have you looked at the "by-reference" metadata capability in OpenURL 1.0? Unless I'm missing something, it seems that *all* of what you're trying to do in unAPI could be accomplished with OpenURL. The advantage, of course, is that OpenURL is easier to transport, and has an established base of support. The disadvantage, of course, is that OpenURL gets ugly, and many resolvers don't support by-reference metadata. Eric -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From jeremy.frumkin at oregonstate.edu Fri Dec 2 16:24:22 2005 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Fri Dec 2 16:24:28 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: Dan - So, If I'm understanding you correctly, you are suggesting we need to abstract the COinS / OAI-COinS implementations so that the functionality you describe isn't limited to COinS and OAI-COinS. In other words, COinS is defined more like a protocol implemented in HTML, and OAI-COinS is also defined as a specific protocol. What we need is a more abstract reference model, under which COinS and OAI-COinS are compliant, but are not the only potential implementations of said reference model. Do I hear an 'Oy!' on the above? -- jf On 12/2/05 12:16 PM, "Daniel Chudnov" wrote: > I keep getting stuck on the COinS-PMH requirements of COinS (OpenURL) > and OAI-PMH. I think these will keep it from succeeding at all. > > What I want is a way that *anybody* can implement the following functions > quickly, in javascript/dhtml or any other language: > > - for identified content items on any HTML page, > - find out what kinds of "records" are available for one or more of > them, and > - get one or more of those record kinds for one or more of the items. > > If we simplified unAPI further, it might look like: > > - "identified" items are those with "class='identifier'" elements > on them; the content of the element with that attribute/value > pair is the identifier for that item. > > - we retain the link tag, but specify "unapi" and a base url of > "http://blah.blah.blah/blah/blah/unapi" *instead* of "COinS-PMH" > and a pseudo-or-real OAI-PMH service that supports > ListMetadataFormats and GetRecord. > > - /unapi URIs must respond to several kinds of GETs: > - /unapi/formats (formats supported site-wide) > - /unapi/identifier/formats (formats for a given item) > - /unapi/identifier/format (a specific record format for that iitem) > > Then we specify a number of "bindings", i.e. ways to implement unapi > using different underlying tools/protocols: > > - COinS/OAI-PMH: as before, with the differences that COinS also > get a class='identifier' around the actual identifier, and the > unapi calls map to OAI-PMH calls that filter out the OAI wrapper > stuff and just return metadata > > - Atom: the element from hAtom that gets the id attribute also > gets a class='attribute'. then the unapi calls just map to the > same responses you'd get from Atom calls to GET that identifier, > with the atom wrapper stuff elided. > > - SRW/U: the listformats/getrecord bit is implemented using SRW/U > with SRW/u wrapper bits elided and formats list from the explain > response; the get calls are searches by identifier with wrapper > stuff elided. > > - OpenSearch: similar to SRW/U in that the formats list comes from > the opensearch description response and the getrecords just > search on identifier and strip response RSS wrapper bits. > > > I think this might scale to World Domination (tm). > > -dchud > -- jf =============================================== Jeremy Frumkin The Gray Chair for Innovative Library Services 121 The Valley Library, Oregon State University Corvallis OR 97330-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 daniel.chudnov at yale.edu Fri Dec 2 16:29:46 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Dec 2 16:29:55 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: <20051202212946.GO25219@curtis.med.yale.edu> Eric Hellman wrote, on Fri, Dec 02, 2005 at 04:14:22PM -0500: > > Have you looked at the "by-reference" metadata capability in OpenURL > 1.0? Unless I'm missing something, it seems that *all* of what you're > trying to do in unAPI could be accomplished with OpenURL. The > advantage, of course, is that OpenURL is easier to transport, and has > an established base of support. The disadvantage, of course, is that > OpenURL gets ugly, and many resolvers don't support by-reference > metadata. Yes, Ross pointed that out early on, and I can't argue that you're wrong. It's clearly a great technical solution. But, with all due respect, nobody outside of our little world understands Z39.88. So if we try to force the world to use it, nobody will use it. But, if we make it easy for people to implement as they see fit, maybe it will stand a chance. A straight Z39.88 implementation might be yet-another implementation choice behind the unAPI facade. Seriously. You know how much I love OpenURL -- you and I, personally, have been talking about it in one way or another for, like, seven years! But, I can't possibly imagine it catching on widely within a matter of weeks. This, *maybe*, could. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Fri Dec 2 16:38:29 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Fri Dec 2 16:38:34 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: <20051202213829.GP25219@curtis.med.yale.edu> Jeremy Frumkin wrote, on Fri, Dec 02, 2005 at 01:24:22PM -0800: > > So, If I'm understanding you correctly, you are suggesting we need to > abstract the COinS / OAI-COinS implementations so that the functionality you > describe isn't limited to COinS and OAI-COinS. Yes, I meant exactly that. :) > In other words, COinS is > defined more like a protocol implemented in HTML, and OAI-COinS is also > defined as a specific protocol. What we need is a more abstract reference > model, under which COinS and OAI-COinS are compliant, but are not the only > potential implementations of said reference model. Hrm, not quite what I meant. I didn't mean to say anything about COinS, which I think still makes sense, if perhaps only within our community. What I think we need is a *braindead-simple* protocol that anybody could implement in 5-10 minutes. And that anybody could implement it in those 5-10 minutes by using COinS and OAI, or Atom, or OpenSearch, or straight Z39.88, or Fedora dissemination URLs, etc. So easy that a group like the folks building flock might just build it right in to see what happens. And then suddenly there's something cool we could all do immediately with our test instances and weblogs and catalogs and faux-amazoogr proxies. > Do I hear an 'Oy!' on the above? Isn't that how *you* pronounce "OAI"? :P -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From jyoung at oclc.org Fri Dec 2 16:48:59 2005 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Fri Dec 2 16:49:05 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI Message-ID: This sounds similar to what I'm trying to do with WikiD. For example, this URL: http://alcme.oclc.org/wikid/info:sid/localhost:CollectionGsafd:GSAFD0000 01?action=raw gets transformed immediately into an OpenURL ContextObject and processed by an embedded OpenURL Resolver. In this case, the Referent is info:sid/localhost:CollectionGsafd:GSAFD000001 (or in theory any other URI) and the Service Type (private data) is "action=raw". It's like a wiki API on top of an OpenURL resolver. Jeff > What I think we need is a *braindead-simple* protocol that anybody could > implement in 5-10 minutes. And that anybody could implement it in those > 5-10 minutes by using COinS and OAI, or Atom, or OpenSearch, or straight > Z39.88, or Fedora dissemination URLs, etc. So easy that a group like the > folks building flock might just build it right in to see what happens. > And then suddenly there's something cool we could all do immediately with > our test instances and weblogs and catalogs and faux-amazoogr proxies. > > > > Do I hear an 'Oy!' on the above? > > Isn't that how *you* pronounce "OAI"? :P > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ehs at pobox.com Fri Dec 2 16:55:30 2005 From: ehs at pobox.com (Ed Summers) Date: Fri Dec 2 16:55:34 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: On 12/2/05, Daniel Chudnov wrote: > - /unapi URIs must respond to several kinds of GETs: > - /unapi/formats (formats supported site-wide) > - /unapi/identifier/formats (formats for a given item) > - /unapi/identifier/format (a specific record format for that iitem) I really like where you are going with this, especially because it leverages the Microformat/ REST ideas that are getting quite a bit of attention. So, if I'm understanding right if I have an HTML page at http://www.example.com/ : ... 123 ... I can infer that I can GET the following URLs http://www.example.com/unapi/formats http://www.example.com/unapi/123456/formats http://www.example.com/unapi/123456/dc Assuming that 'dc' is somehow indicated to be a valid format in the /unapi/123456/formats response? //Ed From klong at delos.lib.sfu.ca Sat Dec 3 02:33:09 2005 From: klong at delos.lib.sfu.ca (Kristina Long) Date: Sat Dec 3 14:18:34 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: <200512030733.jB37X9Q27742@delos.lib.sfu.ca> Nice and simple. I like it. If a more inclusive, simplified version is what it takes to see this in wider implementation then that is enough, I think. One question, instead of '123' one could also have '', right? This would be when I don't want '123' as part of the text. Also how would one handle the case where the resource that contains marked up identifiers does not have the metadata for some or all of the identifiers it is marking up. I'm assuming this is something one might want to do. For instance, you have a database of book reviews. Included in the text are ISBNs that you mark up using 'class=isbn'. You don't actually have the metadata for those books, only the book reviews. So do you have a link element at the top of your page that points elsewhere (say some unapi service running off a big union catalogue) or do you leave this for the application processing the identified items (ie. the ISBNs). Perhaps I'm missing something and this second question does not make sense, but I thought I'd ask anyways. In terms of what one does with the metadata once you have it from an unapi implementation, one service I would like to see is a metadata enhancer which would be run before you do something more interesting with the data (ie. connect to your link resolver, save to your link tracker, whatever). This would only work for items for which there are many copies of metadata (eg. books) for a given identifier. This enhancer would make up for the limited metadata that will be sent back by some unapi implementations (or OpenURL links or COins for that matter). There could be a threshold where you only go to a secondary or tertiary, etc metadata source if necessary. Kristina > If we simplified unAPI further, it might look like: > > - "identified" items are those with "class='identifier'" elements > on them; the content of the element with that attribute/value > pair is the identifier for that item. > > - we retain the link tag, but specify "unapi" and a base url of > "http://blah.blah.blah/blah/blah/unapi" *instead* of "COinS-PMH" > and a pseudo-or-real OAI-PMH service that supports > ListMetadataFormats and GetRecord. > > - /unapi URIs must respond to several kinds of GETs: > - /unapi/formats (formats supported site-wide) > - /unapi/identifier/formats (formats for a given item) > - /unapi/identifier/format (a specific record format for that iitem) > > Then we specify a number of "bindings", i.e. ways to implement unapi > using different underlying tools/protocols: > > - COinS/OAI-PMH: as before, with the differences that COinS also > get a class='identifier' around the actual identifier, and the > unapi calls map to OAI-PMH calls that filter out the OAI wrapper > stuff and just return metadata > > - Atom: the element from hAtom that gets the id attribute also > gets a class='attribute'. then the unapi calls just map to the > same responses you'd get from Atom calls to GET that identifier, > with the atom wrapper stuff elided. > > - SRW/U: the listformats/getrecord bit is implemented using SRW/U > with SRW/u wrapper bits elided and formats list from the explain > response; the get calls are searches by identifier with wrapper > stuff elided. > > - OpenSearch: similar to SRW/U in that the formats list comes from > the opensearch description response and the getrecords just > search on identifier and strip response RSS wrapper bits. > > > I think this might scale to World Domination (tm). > > -dchud > > > -- > 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 > -- Kristina Long Phone: 604-291-3037 Systems Consultant Fax: 604-291-3023 Library Systems Internet: klong@sfu.ca Simon Fraser University From eric at openly.com Sat Dec 3 21:10:42 2005 From: eric at openly.com (Eric Hellman) Date: Sat Dec 3 21:10:56 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202212946.GO25219@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> <20051202212946.GO25219@curtis.med.yale.edu> Message-ID: At 4:29 PM -0500 12/2/05, Daniel Chudnov wrote: >Seriously. You know how much I love OpenURL -- you and I, personally, >have been talking about it in one way or another for, like, seven years! >But, I can't possibly imagine it catching on widely within a matter >of weeks. This, *maybe*, could. 6 year, 7 months, exactly. Which is why I'm paying attention, even though I haven't grokked what you want to do with unapi. Let me step back and reframe the problem, forgetting about openurl and unapi You have 1. somebody with a lot of item-oriented metadata that wants to let people make use of it and has the means to do so. 2. identifiers for the items. 3. people who have motivation and means to cite the items in ways that let other people add services to them. 4. users who need added services for the cited items. 5. people who have motivation and need to work to meet the needs in (4) Do we need something to make things work better? to make this concrete.. 1. Pubmed 2. pubmed ids 3. we see pubmid id based linking in things like wikipedia, infopoems, etc. 4. primary need seems to be fulltext 5. A large number of solutions have stepped to the plate to meet this set of needs, including linkout, linkservers, things like Hubmed, other things you've done, etc., all based on xml web services provided by Pubmed. Can we generalize what has happened for pubmed to all cases where we have conditions 1,2,3,4,5? lets look at the barriers associated with each essential component: 1. making metadata available has been limited by the technical competence or business timidity of organizations that have large stores of metadata. Library catalogs have not had usable web services (Z39.50 is a web-disservice if you ask me). If you ever tried to digest Onix feeds from book publishers, you'll understand that NCBI and Amazon are not playing in the same league as most of the candidates for #1. This is changing. Slowly. OAI-PMH implementations, etc. 2. We have a surfeit of identifiers and a deficit of web services to reconcile and connect them. This may be changing, if I have anything to do with it. 3. Motiving the masses to associate items with identifer-based metadata records seems to me an almost impossible task. The ISBN is almost ubiquitous, yet the fraction of web pages that provide ISBN based links is equal, to within 1%, to the fraction of web pages that provide amazon links or affiliation based links. In other words, people only use isbn reliably if someone is paying for it. This may be changing. 4. This seems to be the key to me. What does a user really need? In this thread people mentioned bibliographic export- this function seems not to need any new API, as the functionality is appearing everywhere. Fulltext services, doc-delivery, ILL- users need these, but do we need unapi for that? Sometimes the need for a service only becomes manifest once a service becomes available- I didn't know I couldn't live without WiFi or an MP3 player before I got may airport router and iPod. But I can't think of any service that would need to be provided via unapi that people wouldn't be able to live without. 5. The existence of the gcs-pcs list is evidence that #5 is not a bottleneck. -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Sat Dec 3 22:49:19 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sat Dec 3 22:49:25 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: Message-ID: <8264E6AE-A1A7-4CDE-9DBA-4C37520A8559@yale.edu> On Dec 2, 2005, at 4:48 PM, Young,Jeff (OR) wrote: > It's like a wiki API on top of an OpenURL resolver. I *think* I understand. :) I suppose the main difference between the goals for unAPI and what wikiD does internally is that unAPI is intended primarily for external rewiring of applications. If I really do understand, since wikiD provides all those Z39.88 functions under the hood, it would be easy both to add an unAPI layer internal to wikid, or for an external app to proxy its Z39.88 functions with its own unAPI mappings. Is that close to correct? -Dan From daniel.chudnov at yale.edu Sat Dec 3 22:55:06 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sat Dec 3 22:55:16 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: On Dec 2, 2005, at 4:55 PM, Ed Summers wrote: > leverages the Microformat/ REST ideas that are getting quite a bit of > attention. Right, exactly what I'm aiming for. > I can infer that I can GET the following URLs > > http://www.example.com/unapi/formats > http://www.example.com/unapi/123456/formats > http://www.example.com/unapi/123456/dc > > Assuming that 'dc' is somehow indicated to be a valid format in the > /unapi/123456/formats response? Yes. The path doesn't even really need to include "unapi", it could be anywhere, I suppose, so long as it's specified in the href attribute of the link tag with the "unapi" title. I guess we need to specify a response format for the "formats" functions. How about "one format per line, in a text/plain response body"? e.g. """ dc """ or """ dc mods marcxml """ or """ dc info:some.wacky.registered:format/with/unintelligible:identifier/ 23t8239898j.2004 foo """ That might work... and it couldn't be much simpler. -Dan From daniel.chudnov at yale.edu Sat Dec 3 23:13:28 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sat Dec 3 23:13:36 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <200512030733.jB37X9Q27742@delos.lib.sfu.ca> References: <200512030733.jB37X9Q27742@delos.lib.sfu.ca> Message-ID: <1A0A73F7-36BF-445B-8C43-842137510B7C@yale.edu> On Dec 3, 2005, at 2:33 AM, Kristina Long wrote: > > One question, instead of '123' one > could also have > '', right? This would be > when I don't want '123' as part of the text. I'd intended that the identifier itself would be the textnode content of the surrounding element. If I understand the microformats strategy correctly there are more benefits to keeping the data human- visible than hiding it. Although you always could hide it with a css property or somesuch, they seem to frown on this. Search "uf-discuss invisible metadata" for recent discussions thereof. Something tells me that their possible collective interest in a spec like this is the single most important gauge we have for whether this could work. Maybe that's foolish, I don't know. > For instance, you have a database of book reviews. Included in the > text are > ISBNs that you mark up using 'class=isbn'. You don't actually have > the > metadata for those books, only the book reviews. So do you have a > link > element at the top of your page that points elsewhere (say some > unapi service > running off a big union catalogue) or do you leave this for the > application > processing the identified items (ie. the ISBNs). This gets right at the kind of service I've been thinking about too, as do your later points. I'm imagining that particular users and particular applications have diverse unAPI targets they can (the people or the software) might query in various contexts. In this case, if the review were an hReview, it could intermingle the identifier with an info:isbn:blahblahblahX value in there. Perhaps the service itself wouldn't know anything else about the isbn references, but your browser or Collector's Box application or whatnot could query amazon or LoC for the data and, perhaps, intermingle it inline. Or save the two (the review and the isbn metadata) in some combined package (DIDL or METS bundle?) on some third site. Fyi, hReview lives at: http://microformats.org/wiki/hreview (note that that document punts on the notion of a "universal object identifier", which is what i'm trying to address. or, at least, how to publish the identifier, not an identifer solution per se.) > This would only work for items for which there are many copies of > metadata > (eg. books) for a given identifier. This enhancer would make up > for the > limited metadata that will be sent back by some unapi > implementations (or OpenURL > links or COins for that matter). There could be a threshold where > you only > go to a secondary or tertiary, etc metadata source if necessary. Yes, okay, sign me up, I want one too. :) Some time ago in #code4lib we were talking about a "restoring metadata" service like this, akin to "restoring logic" in circuit design. I don't know where else I've heard this concept in the winds recently but it's been there. Not to mention that our catalog records get similar "augmentation" treatment at large, distributed scales already, just in batches, not in real-time. -Dan From daniel.chudnov at yale.edu Sat Dec 3 23:26:18 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sat Dec 3 23:26:28 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> <20051202212946.GO25219@curtis.med.yale.edu> Message-ID: <8FD3A839-A891-4852-8018-9E3395A29B2A@yale.edu> On Dec 3, 2005, at 9:10 PM, Eric Hellman wrote: > > 1. making metadata available has been limited by the technical > competence or business timidity of organizations that have large > stores of metadata. Library catalogs have not had usable web > services (Z39.50 is a web-disservice if you ask me). If you ever > tried to digest Onix feeds from book publishers, you'll understand > that NCBI and Amazon are not playing in the same league as most of > the candidates for #1. This is changing. Slowly. OAI-PMH > implementations, etc. I suspect widespread adoption of atom in weblog engines and other large-scale type-specific media service providers will (or already has?) changed things quickly. > 3. Motiving the masses to associate items with identifer-based > metadata records seems to me an almost impossible task. Well, sure, if they have to know how to do that themselves. :) If the backends do it for them, then, it's no problem! > 4. This seems to be the key to me. What does a user really need? As far as I can tell, the more-general-than-library-scenarios requirement of being able to "take something you see at one place and put it somewhere else" with some useful degree of mechanical reliability is already nearing global proportions. > 5. The existence of the gcs-pcs list is evidence that #5 is not a > bottleneck. As impressive and diverse in talent and experience as the present group might be (and it's *quite* impressive and diverse!), the volume of developers who might do unanticipatedly cool things with a basic structure like this is several orders greater than our numbers. I have no sense of whether unAPI will be that structure, but there will be something, and it will be this simple. Maybe instead of stuffing atom and everything else inside of unAPI we'll end up stuffing all our other stuff inside of atom, who knows. The "unAPI" meme lends itself to defining additional functions, though, so it seems to be a bit more fertile of a place to start. -Dan From lists at hubmed.org Sun Dec 4 01:08:10 2005 From: lists at hubmed.org (Alf Eaton) Date: Sun Dec 4 01:08:27 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051202201653.GM25219@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> Message-ID: <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> If I understand it correctly, what you're trying to do with unAPI is have a page structured like: IDENTIFIER1 IDENTIFIER2 ... IDENTIFIER10 But what you're really saying is that the URI for each of those items is http://example.com/unapi/IDENTIFIER1 http://example.com/unapi/IDENTIFIER2 ... http://example.com/unapi/IDENTIFIER10 so why not use [1], let the web do its natural thing and make a normal HTTP request to each of those URLs, ask for whatever media type it prefers using Accept headers (application/rdf+xml;application/mods +xml;text/html;whatever) and collect the data that way? alf. PS I hope this isn't just spans versus anchors again - I don't think the same restrictions apply in this case as for COinS. [1] and inside for an alternate view of all the items on the page at once. From daniel.chudnov at yale.edu Sun Dec 4 01:37:40 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Dec 4 01:37:51 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: On Dec 4, 2005, at 1:08 AM, Alf Eaton wrote: > But what you're really saying is that the URI for each of those > items is > > http://example.com/unapi/IDENTIFIER1 > http://example.com/unapi/IDENTIFIER2 > ... > http://example.com/unapi/IDENTIFIER10 > > so why not use [1], let the web do its natural thing and make a > normal HTTP request to each of those URLs, ask for whatever media > type it prefers using Accept headers (application/rdf > +xml;application/mods+xml;text/html;whatever) and collect the data > that way? Because there might be additional services available for that same content item from arbitrary third-party providers, to be requested or automatically mixed in at the user's discretion. One case where the above breaks is Kristina's example of a review where a published page describes something (say, a book) for which the publisher cannot provide additional metadata/disseminations itself. So, if the identifier is an ISBN, example.com might not able to respond usefully to a normal HTTP request for http://example.com/ unapi/THE-ISBN-VALUE, but some remote site might be able to respond usefully to http://remotesite.com/unapi/THE-ISBN-VALUE. Another case where the above would work but potentially complicate app remixing is where example.com can provide useful information from that URL but there is additional information to be had elsewhere. Using an ISBN again, http://example.com/unapi/THE-ISBN-VALUE might provide useful metadata for the ISBN. But the third party to be called to provide additional information for THE-ISBN-VALUE should get its request at http://thirdparty.com/unapi/THE-ISBN-VALUE, rather than http://thirdparty.com/unapi/http://example.com/unapi/THE-ISBN- VALUE. (or maybe s#THE-ISBN-VALUE#info:isbn/THE-ISBN-VALUE# etc.) The assumption I'm making, then, is that identifiers should not be assumed to be tied to identifier resolution. They could be, but they might not be. If they are not, their "pure" form should be deterministically parseable for easy service remixing. I've been frustrated by fighting that "not-tied-to-resolution" battle for years. Maybe it's foolish to think things might change now. Good point about Accept headers; I'm not sure if that solves the format problem or not. I suspect you might want to be able to accept some format you didn't know about before, if only to pass it through to some other service. But, I'm just guessing. > PS I hope this isn't just spans versus anchors again - I don't > think the same restrictions apply in this case as for COinS. I don't think so either... this is mostly separate from COinS (which is part of why a name without "COinS" in it made sense). -Dan From jeremy.frumkin at oregonstate.edu Sun Dec 4 01:47:21 2005 From: jeremy.frumkin at oregonstate.edu (Jeremy Frumkin) Date: Sun Dec 4 01:47:25 2005 Subject: [gcs-pcs-list] Understanding unapi In-Reply-To: <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: So, here?s how I am viewing unapi (much of this is based on an off-list conversation I had with Dan): Unapi has 2 components: 1. An identifier of a resource, embedded in HTML via the mechanism. 2. A REST-full protocol that provides OAI-PMH-Like functionality, but is less awkward when viewed by the general REST community. If one of the major goals here is to create something that is adoptable by the general world, and not just the library community, then it is important to get away from OAI-PMH as a protocol. OAI-PMH is a great protocol; it does a great job of allowing digital library metadata collections to be harvested. It also was created before standard practices on creating REST-full services came into being. And it requires Dublin Core. It would probably allow for better buy-in to create a protocol which is similar to OAI-PMH, but somewhat simpler, more standard in the general web world, and not tied to a specific metadata scheme. To me, the big advantage of unapi over COinS/COinS-PMH is that COinS/COinS-PMH is very library community specific, while unapi can work for a variety of communities, library and non-library. -- jf =============================================== Jeremy Frumkin The Gray Chair for Innovative Library Services 121 The Valley Library, Oregon State University Corvallis OR 97330-4501 Jeremy.Frumkin@oregonstate.edu 541.737.9928 541.737.3453 (Fax) 541.230.4483 (Cell) =============================================== " Without ambition one starts nothing. Without work one finishes nothing. " - Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20051203/87405e25/attachment.htm From lists at hubmed.org Sun Dec 4 01:58:34 2005 From: lists at hubmed.org (Alf Eaton) Date: Sun Dec 4 01:58:46 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: On 04 Dec 2005, at 01:37, Daniel Chudnov wrote: > On Dec 4, 2005, at 1:08 AM, Alf Eaton wrote: > >> But what you're really saying is that the URI for each of those >> items is >> >> http://example.com/unapi/IDENTIFIER1 >> http://example.com/unapi/IDENTIFIER2 >> ... >> http://example.com/unapi/IDENTIFIER10 >> >> so why not use [1], let the web do its natural thing and make a >> normal HTTP request to each of those URLs, ask for whatever media >> type it prefers using Accept headers (application/rdf >> +xml;application/mods+xml;text/html;whatever) and collect the data >> that way? > > Because there might be additional services available for that same > content item from arbitrary third-party providers, to be requested > or automatically mixed in at the user's discretion. > > One case where the above breaks is Kristina's example of a review > where a published page describes something (say, a book) for which > the publisher cannot provide additional metadata/disseminations > itself. So, if the identifier is an ISBN, example.com might not > able to respond usefully to a normal HTTP request for http:// > example.com/unapi/THE-ISBN-VALUE, but some remote site might be > able to respond usefully to http://remotesite.com/unapi/THE-ISBN- > VALUE. > > Another case where the above would work but potentially complicate > app remixing is where example.com can provide useful information > from that URL but there is additional information to be had > elsewhere. Using an ISBN again, http://example.com/unapi/THE-ISBN- > VALUE might provide useful metadata for the ISBN. But the third > party to be called to provide additional information for THE-ISBN- > VALUE should get its request at http://thirdparty.com/unapi/THE- > ISBN-VALUE, rather than http://thirdparty.com/unapi/http:// > example.com/unapi/THE-ISBN-VALUE. > > (or maybe s#THE-ISBN-VALUE#info:isbn/THE-ISBN-VALUE# etc.) Right - I was using the unalog example before, where the thing had a local identifier, but there's no reason you shouldn't do Well, depending on things like and anyway... alf. From ross.singer at library.gatech.edu Sun Dec 4 10:35:35 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sun Dec 4 10:36:10 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: <7dc6741691f936cec926be6e30cb78db@library.gatech.edu> On Dec 4, 2005, at 1:58 AM, Alf Eaton wrote: > Right - I was using the unalog example before, where the thing had a > local identifier, but there's no reason you shouldn't do > The only problem I see with this is that it requires an "actionable element" (an anchor tag) in the page that leads to some sort of ugly non-html interface (xml or whatever). I suppose (like COinS) they could be suppressed via CSS, but this seems to be more obtrusive than some empty inline element sitting there. -Ross. From ross.singer at library.gatech.edu Sun Dec 4 10:48:48 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sun Dec 4 10:49:29 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: On Dec 4, 2005, at 1:37 AM, Daniel Chudnov wrote: > unapi/THE-ISBN-VALUE might provide useful metadata for the ISBN. But > the third party to be called to provide additional information for > THE-ISBN-VALUE should get its request at > http://thirdparty.com/unapi/THE-ISBN-VALUE, rather than > http://thirdparty.com/unapi/http://example.com/unapi/THE-ISBN-VALUE. > > (or maybe s#THE-ISBN-VALUE#info:isbn/THE-ISBN-VALUE# etc.) > When this thread started the other day, I was prepared to shelve my constant braying about the importance of identifier context. I was willing to say, "the context of the container will be enough". However, Kristina's point strengthens my original resolve on this topic. I hadn't thought about the scenario that the "indentifying service" has only minimal (or alternative) metadata about a given object. At this point, it's really damn important that this identifier be easily resolvable (or figure-outable) in some way. It's important to be able to quickly and efficiently "know" what some sort of identifier is and then "know" how to find more metadata about the object. -Ross. From jyoung at oclc.org Sun Dec 4 11:54:17 2005 From: jyoung at oclc.org (Young,Jeff (OR)) Date: Sun Dec 4 11:54:24 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI Message-ID: That's the general idea. I don't think the services provided by WikiD are limited to internal functions and data, though. Since it is an OpenURL resolver under the hood, I can use it as a linking service to external applications. For example, I can imagine passing in an ISBN (perhaps something like http://alcme.oclc.org/wikid/urn:isbn:0123456789?action=openworldcat, and have it perform an HTTP redirect to Open WorldCat for that item. On a side note, I can almost imagine OCLC's OpenURL gateway fitting in here somewhere (http://www.oclc.org/productworks/urlresolver.htm). Right now this service is focused on conventional applications of OpenURL 0.1, but I am trying to convince them to broaden their horizons to accommodate arbitrary 1.0 capabilities. In essence, I want them to make it a full-fledged OpenURL resolver that connects to other OpenURL resovlers rather than a simpleminded OpenURL gateway triggered by IP address. I need to reread this thread to learn what unAPI is trying to solve that OpenURL doesn't, but if it is a question of simplifying the URL structure, something like a WikiD interface on top of a broader-minded OCLC OpenURL gateway service might help in that regard. Jeff > -----Original Message----- > From: Daniel Chudnov [mailto:daniel.chudnov@yale.edu] > Sent: Saturday, December 03, 2005 10:49 PM > To: Young,Jeff (OR) > Cc: gcs-pcs-list@cipolo.med.yale.edu > Subject: Re: [gcs-pcs-list] quick thought experiment re: unAPI > > On Dec 2, 2005, at 4:48 PM, Young,Jeff (OR) wrote: > > > It's like a wiki API on top of an OpenURL resolver. > > I *think* I understand. :) > > I suppose the main difference between the goals for unAPI and what > wikiD does internally is that unAPI is intended primarily for > external rewiring of applications. If I really do understand, since > wikiD provides all those Z39.88 functions under the hood, it would be > easy both to add an unAPI layer internal to wikid, or for an external > app to proxy its Z39.88 functions with its own unAPI mappings. > > Is that close to correct? > > -Dan From eric at openly.com Sun Dec 4 13:58:08 2005 From: eric at openly.com (Eric Hellman) Date: Sun Dec 4 13:58:31 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <8FD3A839-A891-4852-8018-9E3395A29B2A@yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> <20051202212946.GO25219@curtis.med.yale.edu> <8FD3A839-A891-4852-8018-9E3395A29B2A@yale.edu> Message-ID: At 11:26 PM -0500 12/3/05, Daniel Chudnov wrote: >On Dec 3, 2005, at 9:10 PM, Eric Hellman wrote: >> >>1. making metadata available has been limited by the technical >>competence or business timidity of organizations that have large >>stores of metadata. Library catalogs have not had usable web >>services (Z39.50 is a web-disservice if you ask me). If you ever >>tried to digest Onix feeds from book publishers, you'll understand >>that NCBI and Amazon are not playing in the same league as most of >>the candidates for #1. This is changing. Slowly. OAI-PMH >>implementations, etc. > >I suspect widespread adoption of atom in weblog engines and other >large-scale type-specific media service providers will (or already >has?) changed things quickly. assuming that the metadata associated with these service providers makes something larger possible... >>3. Motiving the masses to associate items with identifer-based >>metadata records seems to me an almost impossible task. > >Well, sure, if they have to know how to do that themselves. :) If >the backends do it for them, then, it's no problem! The only backend that really motivates people is a kick in the... but really, the backend then has to be motivated. > > >>4. This seems to be the key to me. What does a user really need? > >As far as I can tell, the more-general-than-library-scenarios >requirement of being able to "take something you see at one place >and put it somewhere else" with some useful degree of mechanical >reliability is already nearing global proportions. So we're talking about, for example, a super-bookmarker that helps people store, process and generate references of all types. I'm with you here. And this argues for something that can handle the citation of a blog entry in the same way it handles a scholarly reference. Having thought a bit about this particular application, it seems to me that unapi would be really handy, but is in no way necessary for the application. A track-back url is all the handle an app really needs to get a hold of the needed metadata, I think (wouldn't know for sure without actually writing code). What unapi could bring to the table is capability to do the same for other classes of metadata. An alternate way of accomplishing the same thing would be to package the metadata sources as atom feeds. -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From daniel.chudnov at yale.edu Sun Dec 4 15:30:37 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Sun Dec 4 15:30:42 2005 Subject: [gcs-pcs-list] Understanding unapi In-Reply-To: References: Message-ID: <4BFB4A4D-74AA-40F2-A66E-D3BB1C43EFBB@yale.edu> On Dec 4, 2005, at 1:47 AM, Jeremy Frumkin wrote: > To me, the big advantage of unapi over COinS/COinS-PMH is that > COinS/COinS-PMH is very library community specific, while unapi can > work for a variety of communities, library and non-library. Just to clarify, I agree with most everything here except the inclusion of "COinS" in this sentence. All the reasons COinS is a good idea still hold, and I'm still totally for it. unAPI doesn't "compete with" or "replace" COinS... it "replaces" COinS-PMH. So if COinS is a pseudo-microformat for ContextObjects, unAPI is a pseudo-microprotocol for OAI-PMH. They can be complementary. (Or, at least, so far that's all unAPI is... there's more we can do with it but that can wait.) As an aside, I'm working on sample code to support general-purpose unAPI id resolver services: http://curtis.med.yale.edu/dchud/log/project/rogue/opa OPA ("Ostensible Proxy to APIs", maybe? Think flaming saganaki) in this embryonic form lets you specify an identifier in the info sid and pmid namespaces; sids from amazon.com and flickr.com photo ids are supported. From the commandline you can specify an info URI for any of these three, and an output format, and it will respond with the specified record. Just a start, but, it works. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Mon Dec 5 10:22:14 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Dec 5 10:22:57 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> Message-ID: <20051205152211.GB13115@curtis.med.yale.edu> Ross Singer wrote, on Sun, Dec 04, 2005 at 10:48:48AM -0500: > At this point, it's really damn important that this identifier be > easily resolvable (or figure-outable) in some way. It's important to > be able to quickly and efficiently "know" what some sort of identifier > is and then "know" how to find more metadata about the object. Agreed. But, our systems should still be smart enough to make reasonable guesses when there's no context. "Be liberal in what you accept" and all that. -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From ross.singer at library.gatech.edu Mon Dec 5 10:33:27 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Dec 5 10:33:00 2005 Subject: [Possible Spam]::Re: [gcs-pcs-list] quick thought experiment re: unAPI In-Reply-To: <20051205152211.GB13115@curtis.med.yale.edu> References: <20051202201653.GM25219@curtis.med.yale.edu> <522DF776-81BA-482B-A1EA-E5ADEE9B3AE3@hubmed.org> <20051205152211.GB13115@curtis.med.yale.edu> Message-ID: <43945DC7.2090007@library.gatech.edu> Dan, I live in Georgia. Even the most "liberal" would be considered "conservative" in Connecticut. Obviously, systems can take into account major, easy to parse identifiers (DOI, ISxN, etc.), but if the info uri could be easily integrated, I would strive for that, rather than trying to account for possibilities on the backend. -Ross. Daniel Chudnov wrote: >Ross Singer wrote, on Sun, Dec 04, 2005 at 10:48:48AM -0500: > > >>At this point, it's really damn important that this identifier be >>easily resolvable (or figure-outable) in some way. It's important to >>be able to quickly and efficiently "know" what some sort of identifier >>is and then "know" how to find more metadata about the object. >> >> > >Agreed. But, our systems should still be smart enough to make reasonable >guesses when there's no context. "Be liberal in what you accept" and >all that. > > -Dan > > > > From klong at delos.lib.sfu.ca Mon Dec 5 17:54:50 2005 From: klong at delos.lib.sfu.ca (Kristina Long) Date: Mon Dec 5 18:04:55 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI - identifier visibility In-Reply-To: Message-ID: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> > On Dec 3, 2005, at 2:33 AM, Kristina Long wrote: > > > > One question, instead of '123' one > > could also have > > '', right? This would be > > when I don't want '123' as part of the text. > > I'd intended that the identifier itself would be the textnode content > of the surrounding element. If I understand the microformats > strategy correctly there are more benefits to keeping the data human- > visible than hiding it. Although you always could hide it with a css > property or somesuch, they seem to frown on this. > > Search "uf-discuss invisible metadata" for recent discussions thereof. Although I agree with many of the comments made in these 'invisible metadata' discussions I still see a need to have the hidden metadata. The main problem I see is that one often doesn't have control over what appears on the screen of many of the resources to which we might want to add unapi. It is often the decision of other people who may not be too keen on this metadata being visible. For instance, I was thinking on Friday of what would be needed to add unapi to the public interface for our ILS. The identifier I would want to use is the III 'b number' since it uniquely identifies the records (our catalogue in some cases has one record for print, one for electronic format so ISSN/ISBN would not be unique). I'm unlikley to convice any reference librarian that '.b1220677' is something they want anywhere on the OPAC screens. As you point out I can get around this using CSS, but that is one more step and I know your aim is to make this really simple. Any reason the unapi spec couldn't have both versions? Kristina -- Kristina Long 604-291-3037 Systems Consultant 604-291-3023 (fax) Library Systems klong@sfu.ca Simon Fraser University http://researcher.sfu.ca/ From ehs at pobox.com Mon Dec 5 18:30:29 2005 From: ehs at pobox.com (Ed Summers) Date: Mon Dec 5 18:30:31 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI - identifier visibility In-Reply-To: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> References: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> Message-ID: On 12/5/05, Kristina Long wrote: > I'm unlikley to convice any reference librarian that '.b1220677' is something > they want anywhere on the OPAC screens. Well perhaps you should try to convince them and see if they really do care :-) If they do you can hide it with CSS :-) The reason for wanting to keep it visible is to leverage unapi's identifier handling as a microformat [1]. "design for humans first, machines second" //Ed [1] http://microformats.org/about/ From lists at hubmed.org Mon Dec 5 18:38:54 2005 From: lists at hubmed.org (Alf Eaton) Date: Mon Dec 5 18:39:04 2005 Subject: [gcs-pcs-list] Identifiers in HTML Message-ID: <76322264-2024-4E11-BE9D-54F84BB9FAB1@hubmed.org> To summarise my part of a discussion with Dan C. earlier today: 1) COinS is nice and works well. 2) Sometimes (often?) people don't want to have to create a whole ContextObject and would prefer just to use a single identifier. 3) Agents need to be able to recognise that identifier. 4) The hReview microformat uses to signify an identifier (the author or subject of the review, for example). 5) Many (most?) things - eg cars, restaurants, genes - are offline and don't have a resolvable URL, so need to use a URN (URLs and URNs are subsets of URIs), eg urn:isbn:12345678 6) Can't use book, as the resulting link produces a browser error when it's clicked. 7) Suggestion: use urn:isbn:12345678 (for a visible identifier) or (for an invisible identifier). 8) Alternative suggestion: use instead of "identifier", to make it clearer what kind of identifier is expected. Does that make any sense? alf. From Peter.Binkley at ualberta.ca Mon Dec 5 19:14:00 2005 From: Peter.Binkley at ualberta.ca (Binkley, Peter) Date: Mon Dec 5 19:14:44 2005 Subject: [gcs-pcs-list] Identifiers in HTML Message-ID: <908893006339C0409519E4065DF3B24901570EB5@mailserver.ualibrary.ualberta.ca> makes it click for me, and should make it easier for folks in the wider web world to see what this is for immediately. And I like the visible and invisible choices. Peter > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Alf Eaton > Sent: Monday, December 05, 2005 04:39 PM > To: GCS-PCS list > Subject: [gcs-pcs-list] Identifiers in HTML > > To summarise my part of a discussion with Dan C. earlier today: > > 1) COinS is nice and works well. > 2) Sometimes (often?) people don't want to have to create a > whole ContextObject and would prefer just to use a single identifier. > 3) Agents need to be able to recognise that identifier. > 4) The hReview microformat uses to signify an identifier (the > author or subject of the review, for example). > 5) Many (most?) things - eg cars, restaurants, genes - are > offline and don't have a resolvable URL, so need to use a URN > (URLs and URNs are subsets of URIs), eg urn:isbn:12345678 > 6) Can't use href="urn:isbn:12345678">book, as the resulting link > produces a browser error when it's clicked. > 7) Suggestion: use urn:isbn:12345678 > (for a visible identifier) or title="urn:isbn:12345678"> (for an invisible identifier). > 8) Alternative suggestion: use instead of > "identifier", to make it clearer what kind of identifier is expected. > > Does that make any sense? > > alf. > > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > From eric at openly.com Mon Dec 5 19:55:34 2005 From: eric at openly.com (Eric Hellman) Date: Mon Dec 5 19:55:44 2005 Subject: [gcs-pcs-list] Identifiers in HTML Message-ID: it seems we're 2/3 of the way to reinventing RDF. once we have associated an identifier with some chunk of html, there arises the need to specify, what, exactly, this association is supposed to assert. I.E., the elementary particle of knowledge representation is a subject-object-predicate triple. >To summarise my part of a discussion with Dan C. earlier today: > >1) COinS is nice and works well. >2) Sometimes (often?) people don't want to have to create a whole >ContextObject and would prefer just to use a single identifier. >3) Agents need to be able to recognise that identifier. >4) The hReview microformat uses href="http://www.example.com/12345678"> to signify an identifier >(the author or subject of the review, for example). >5) Many (most?) things - eg cars, restaurants, genes - are offline >and don't have a resolvable URL, so need to use a URN (URLs and URNs >are subsets of URIs), eg urn:isbn:12345678 >6) Can't use book, as >the resulting link produces a browser error when it's clicked. >7) Suggestion: use urn:isbn:12345678 >(for a visible identifier) or title="urn:isbn:12345678"> (for an invisible identifier). >8) Alternative suggestion: use instead of >"identifier", to make it clearer what kind of identifier is expected. > >Does that make any sense? > >alf. -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From lists at hubmed.org Mon Dec 5 20:04:10 2005 From: lists at hubmed.org (Alf Eaton) Date: Mon Dec 5 20:04:21 2005 Subject: [gcs-pcs-list] Identifiers in HTML In-Reply-To: References: Message-ID: <1613C65D-CCB9-4797-A536-E89138EC8CD8@hubmed.org> I was just starting to write this in a separate message :-) - yes, the problem being solved here is similar to that being solved by RDF, in many ways. So, the other difficult problem is how to say which part of the whole document contains the object to which the identifier is attached. One possibility is to say that the parent chunk of HTML containing the human-readable description of the object should share a classname with the identifier span. For example, in a page of book search results, you would have:

stuff about the book

uri:isbn:12345678

stuff about another book

uri:isbn: 87654321
A concern is that this could make conflicts with CSS a bit too complicated, but maybe that wouldn't be a problem. alf. On 05 Dec 2005, at 19:55, Eric Hellman wrote: > it seems we're 2/3 of the way to reinventing RDF. once we have > associated an identifier with some chunk of html, there arises the > need to specify, what, exactly, this association is supposed to > assert. I.E., the elementary particle of knowledge representation > is a subject-object-predicate triple. > > >> To summarise my part of a discussion with Dan C. earlier today: >> >> 1) COinS is nice and works well. >> 2) Sometimes (often?) people don't want to have to create a whole >> ContextObject and would prefer just to use a single identifier. >> 3) Agents need to be able to recognise that identifier. >> 4) The hReview microformat uses to signify an identifier (the author or >> subject of the review, for example). >> 5) Many (most?) things - eg cars, restaurants, genes - are offline >> and don't have a resolvable URL, so need to use a URN (URLs and >> URNs are subsets of URIs), eg urn:isbn:12345678 >> 6) Can't use book, as >> the resulting link produces a browser error when it's clicked. >> 7) Suggestion: use urn:isbn:12345678> span> (for a visible identifier) or > title="urn:isbn:12345678"> (for an invisible identifier). >> 8) Alternative suggestion: use instead of >> "identifier", to make it clearer what kind of identifier is expected. >> >> Does that make any sense? >> >> alf. > > -- > > Eric Hellman, President Openly > Informatics, Inc. > eric@openly.com 2 Broad St., 2nd > Floor > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ > 07003 > http://www.openly.com/1cate/ 1 Click Access To Everything > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list From ross.singer at library.gatech.edu Mon Dec 5 22:55:44 2005 From: ross.singer at library.gatech.edu (Ross Singer) Date: Mon Dec 5 22:56:12 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI - identifier visibility In-Reply-To: References: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> Message-ID: <18727e4b956882088c0df6238edd6ac1@library.gatech.edu> On Dec 5, 2005, at 6:30 PM, Ed Summers wrote: > On 12/5/05, Kristina Long wrote: >> I'm unlikley to convice any reference librarian that '.b1220677' is >> something >> they want anywhere on the OPAC screens. > > Well perhaps you should try to convince them and see if they really do > care :-) If they do you can hide it with CSS :-) The reason for > wanting to keep it visible is to leverage unapi's identifier handling > as a microformat [1]. > > "design for humans first, machines second" Ugly identifiers are for humans? It seems like this whole concept is for machines. -Ross. From ehs at pobox.com Mon Dec 5 23:00:20 2005 From: ehs at pobox.com (Edward Summers) Date: Mon Dec 5 23:00:17 2005 Subject: [gcs-pcs-list] quick thought experiment re: unAPI - identifier visibility In-Reply-To: <18727e4b956882088c0df6238edd6ac1@library.gatech.edu> References: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> <18727e4b956882088c0df6238edd6ac1@library.gatech.edu> Message-ID: <07AA4569-C0E2-4248-BC6E-76296F2D6D15@pobox.com> On Dec 5, 2005, at 9:55 PM, Ross Singer wrote: > Ugly identifiers are for humans? It seems like this whole concept > is for machines. Go to Amazon - do you see an ISBN in the page? Is this ugly? //Ed From daniel.chudnov at yale.edu Mon Dec 5 23:06:20 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Dec 5 23:06:24 2005 Subject: [gcs-pcs-list] Re: identifier visibility (was Quick thought experiment...) In-Reply-To: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> References: <200512052254.jB5Mspj17324@delos.lib.sfu.ca> Message-ID: <528192CE-5E54-43E2-8CBA-56DBF781B5E2@yale.edu> On Dec 5, 2005, at 5:54 PM, Kristina Long wrote: > > As you point out I can get around this using CSS, but that is one > more step and I know your aim is to make this really simple. > > Any reason the unapi spec couldn't have both versions? I haven't necessarily drank all the microformats punch yet, but there's a lot of wisdom wrapped in their attitudes. :) What worries me is optionality, as having one way to do it is simpler. What about this: the "spec" becomes . Then whether you put anything in the span is up to you (it could also be the uri, or it could be something human- friendlier (e.g. "ISBN: 123456789X")), and there's only one query to process to find uris. Well, then, the pop-up "hint" behavior in contemporary browsers will then show the ugly string. Which I could live with, but... Consider too how this might work with COinS: maybe the uri but maybe not :) ...as opposed to the required-visible version: the- uri I'm not sure what's best. I do like "uri" instead of "identifier", though, too. When I was a kid I had a friend named Uri, he was nice, and he sometimes pointed out unique things. :P -dc -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From lists at hubmed.org Mon Dec 5 23:15:03 2005 From: lists at hubmed.org (Alf Eaton) Date: Mon Dec 5 23:15:18 2005 Subject: [gcs-pcs-list] Identifiers in HTML In-Reply-To: <1613C65D-CCB9-4797-A536-E89138EC8CD8@hubmed.org> References: <1613C65D-CCB9-4797-A536-E89138EC8CD8@hubmed.org> Message-ID: <1E45BB9B-3649-4B69-BA71-8FFD328C5DFD@hubmed.org> On 05 Dec 2005, at 20:04, Alf Eaton wrote: > > So, the other difficult problem is how to say which part of the > whole document contains the object to which the identifier is > attached. One possibility is to say that the parent chunk of HTML > containing the human-readable description of the object should > share a classname with the identifier span. > > For example, in a page of book search results, you would have: > > > >
>

stuff about the book

> > uri:isbn:12345678 >
> >
>

stuff about another book

> > uri:isbn: 87654321 >
> > > > A concern is that this could make conflicts with CSS a bit too > complicated, but maybe that wouldn't be a problem. Actually thinking about this more, it might be make more sense to use . Then a parser that finds the identifier could move through parent nodes until it finds a node with class="book", and a parser that extracts the
could move through child nodes until it finds an identifier node with class="for-book". Or is all this really unnecessary? alf. From T.Hammond at nature.com Tue Dec 6 04:42:09 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Tue Dec 6 04:42:14 2005 Subject: [gcs-pcs-list] Identifiers in HTML Message-ID: <125F7834E11A5741A7D79412EE3504F91D08CC76@UK1APPS2.mpl.root-domain.org> Hi Alf: Will assume you meant: > urn:isbn:12345678 i.e. 'urn' not 'uri'. Cheers, Tony > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Alf Eaton > Sent: 06 December 2005 01:04 > To: GCS-PCS list > Subject: Re: [gcs-pcs-list] Identifiers in HTML > > > I was just starting to write this in a separate message :-) - yes, > the problem being solved here is similar to that being solved > by RDF, > in many ways. > > So, the other difficult problem is how to say which part of > the whole > document contains the object to which the identifier is > attached. One > possibility is to say that the parent chunk of HTML containing the > human-readable description of the object should share a classname > with the identifier span. > > For example, in a page of book search results, you would have: > > > >
>

stuff about the book

> > uri:isbn:12345678 >
> >
>

stuff about another book

> > uri:isbn: 87654321 >
> > > > A concern is that this could make conflicts with CSS a bit too > complicated, but maybe that wouldn't be a problem. > > alf. > > > On 05 Dec 2005, at 19:55, Eric Hellman wrote: > > > it seems we're 2/3 of the way to reinventing RDF. once we have > > associated an identifier with some chunk of html, there arises the > > need to specify, what, exactly, this association is supposed to > > assert. I.E., the elementary particle of knowledge representation > > is a subject-object-predicate triple. > > > > > >> To summarise my part of a discussion with Dan C. earlier today: > >> > >> 1) COinS is nice and works well. > >> 2) Sometimes (often?) people don't want to have to create a whole > >> ContextObject and would prefer just to use a single identifier. > >> 3) Agents need to be able to recognise that identifier. > >> 4) The hReview microformat uses to signify an identifier (the > author or > >> subject of the review, for example). > >> 5) Many (most?) things - eg cars, restaurants, genes - are > offline > >> and don't have a resolvable URL, so need to use a URN (URLs and > >> URNs are subsets of URIs), eg urn:isbn:12345678 > >> 6) Can't use book, as > >> the resulting link produces a browser error when it's clicked. > >> 7) Suggestion: use urn:isbn:12345678 >> span> (for a visible identifier) or >> title="urn:isbn:12345678"> (for an invisible identifier). > >> 8) Alternative suggestion: use instead of > >> "identifier", to make it clearer what kind of identifier > is expected. > >> > >> Does that make any sense? > >> > >> alf. > > > > -- > > > > Eric Hellman, President Openly > > Informatics, Inc. > > eric@openly.com 2 Broad > St., 2nd > > Floor > > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ > > 07003 > > http://www.openly.com/1cate/ 1 Click Access To Everything > > _______________________________________________ > > 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 > ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** From lists at hubmed.org Wed Dec 7 10:32:15 2005 From: lists at hubmed.org (Alf Eaton) Date: Wed Dec 7 10:32:25 2005 Subject: [gcs-pcs-list] Firefox Scholar Message-ID: <22C5E5D8-E04D-44FE-8C15-DB5CF5DD576A@hubmed.org> Not sure what this will offer that existing tools don't, but it might be a good incentive for library/archive sites to improve the markup of their pages... From Open Access News: Jeffrey Young, Browser-Based Software Will Help Scholars Organize Information Found Online, Researchers Say, Chronicle of Higher Education, December 6, 2005 (accessible only to subscribers). Excerpt: The Web browser has become an essential tool for many academics, a versatile window into books, journal articles, blogs, and other research materials. Why not create a customized browser with professors' needs in mind? That is the logic behind Firefox Scholar, a software package under development by researchers at George Mason University that will help users organize and cite materials they have found online. The open-source software, which developers plan to release free sometime next year, will plug into the popular Firefox browser, which is also open source. "A good way of thinking about it is incredibly smart bookmarking," says Daniel J. Cohen, an assistant professor of history at George Mason who is working on the project. "You're not just bookmarking the page, but you're automatically [capturing] author, title, all that info that scholars want to save."...For the browser-based software to work fully, however, digital archives must format their books and articles in a way that lets it sort out where elements like title, author, and other bibliographic information reside. Some digital collections already do that, and others could make minor adjustments to comply, says Mr. Cohen. Roy Rosenzweig, a professor of history and new media at the university, says the new browser would also allow researchers to automatically save a copy of an online article or Web page and make annotations on those saved pages. That's better than a shoebox full of notecards and photocopied articles, says Mr. Rosenzweig....A beta version of the software is expected by summer or later next year through the center's Web site. From daniel.chudnov at yale.edu Mon Dec 12 12:52:38 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Mon Dec 12 12:52:44 2005 Subject: [gcs-pcs-list] info URI scheme and identifiers Message-ID: <20051212175237.GB22742@curtis.med.yale.edu> Apparently I've completely misunderstood what the info:sid namespace was for; seems it's about identifying collections for OpenURL rfr.sid values, and *only* collections. I was under the mistaken impression that you could use it for stuff like this: info:sid/myblog.example.com:entry:2345 I realize there's a "tag" uri scheme for this but I tend to agree with the reasons articulated here...: http://info-uri.info/registry/docs/misc/faq.html#use_tag ...for not wanting to use it for this purpose, primarily the dereferencing thing. My use case is unAPI; I want arbitrary sites to be able to specify a single-string URI for individual content items that themselves might be online or offline. And this needs to work for identifiers either within or outside of the OpenURL resolution loop. In other words, a registered namespace prefix for unregistered namespaces, so community developers could work out their own agreements about what the private namespace part meant without having to register every darned one. In the COinS-PMH example stuff I've been using fake uris like oai:flickr.com:photo:12345 oai:unalog.com:person:dchud:entry:54321 i.e. oai:wherever:whatever But obviously "oai" is neither a URI scheme nor a URN namespace id. Hmm, folks in #code4lib just pointed out that the "tag" scheme is better than I realized, and indeed does not have a dereferencing implication: http://www.faqs.org/rfcs/rfc4151.html ...which means that what I should probably do is change my code and examples for unAPI to look more like: tag:flickr.com,2005:photo:12345 tag:unalog.com,2006:person:dchud:entry:54321 i.e. tag:wherever,somedate:whatever Do I understand this correctly now? I'd prefer not to go much further with such misapprehensions. :) Thanks, -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From eric at openly.com Mon Dec 12 13:16:02 2005 From: eric at openly.com (Eric Hellman) Date: Mon Dec 12 13:16:11 2005 Subject: [gcs-pcs-list] info URI scheme and identifiers In-Reply-To: <20051212175237.GB22742@curtis.med.yale.edu> References: <20051212175237.GB22742@curtis.med.yale.edu> Message-ID: the "referrer" is supposed to indicate the "author" of the ContextObject, which is why idendifying a particular page is inappropriate. You are trying to identify a referring entity, and it is entirely appropriate to use an http uri for this purpose. rfe_id=http://myblog.example.com/entry/2345 >Apparently I've completely misunderstood what the info:sid namespace >was for; seems it's about identifying collections for OpenURL rfr.sid >values, and *only* collections. I was under the mistaken impression >that you could use it for stuff like this: > > info:sid/myblog.example.com:entry:2345 > >I realize there's a "tag" uri scheme for this but I tend to agree with >the reasons articulated here...: > > http://info-uri.info/registry/docs/misc/faq.html#use_tag > >...for not wanting to use it for this purpose, primarily the >dereferencing thing. > >My use case is unAPI; I want arbitrary sites to be able to specify a >single-string URI for individual content items that themselves might >be online or offline. And this needs to work for identifiers either >within or outside of the OpenURL resolution loop. In other words, a >registered namespace prefix for unregistered namespaces, so community >developers could work out their own agreements about what the private >namespace part meant without having to register every darned one. > >In the COinS-PMH example stuff I've been using fake uris like > > oai:flickr.com:photo:12345 > oai:unalog.com:person:dchud:entry:54321 > i.e. oai:wherever:whatever > >But obviously "oai" is neither a URI scheme nor a URN namespace id. > >Hmm, folks in #code4lib just pointed out that the "tag" scheme is >better than I realized, and indeed does not have a dereferencing >implication: > > http://www.faqs.org/rfcs/rfc4151.html > >...which means that what I should probably do is change my code and >examples for unAPI to look more like: > > tag:flickr.com,2005:photo:12345 > tag:unalog.com,2006:person:dchud:entry:54321 > i.e. tag:wherever,somedate:whatever > >Do I understand this correctly now? I'd prefer not to go much further >with such misapprehensions. :) > >Thanks, -Dan > > >-- >Daniel Chudnov >Yale Center for Medical Informatics >(203) 737-5789 >_______________________________________________ >gcs-pcs-list mailing list >gcs-pcs-list@cipolo.med.yale.edu >http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list -- Eric Hellman, President Openly Informatics, Inc. eric@openly.com 2 Broad St., 2nd Floor tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything From lists at hubmed.org Mon Dec 12 21:25:32 2005 From: lists at hubmed.org (Alf Eaton) Date: Mon Dec 12 21:27:15 2005 Subject: [gcs-pcs-list] Identifiers in HTML In-Reply-To: <76322264-2024-4E11-BE9D-54F84BB9FAB1@hubmed.org> References: <76322264-2024-4E11-BE9D-54F84BB9FAB1@hubmed.org> Message-ID: <1D59DD4A-54DD-4B29-A6A3-064BB952DEC9@hubmed.org> On 05 Dec 2005, at 18:38, Alf Eaton wrote: > To summarise my part of a discussion with Dan C. earlier today: > > 1) COinS is nice and works well. > 2) Sometimes (often?) people don't want to have to create a whole > ContextObject and would prefer just to use a single identifier. > 3) Agents need to be able to recognise that identifier. > 4) The hReview microformat uses to signify an identifier (the author or > subject of the review, for example). > 5) Many (most?) things - eg cars, restaurants, genes - are offline > and don't have a resolvable URL, so need to use a URN (URLs and > URNs are subsets of URIs), eg urn:isbn:12345678 > 6) Can't use book, as > the resulting link produces a browser error when it's clicked. > 7) Suggestion: use urn:isbn:12345678 span> (for a visible identifier) or title="urn:isbn:12345678"> (for an invisible identifier). > 8) Alternative suggestion: use instead of > "identifier", to make it clearer what kind of identifier is expected An addendum: 9) If we were doing this the same way as the ?formats at microformats.org, it would be ISBN: 12345678, for example, rather than (see hCalendar[1] and hReview[2] for more ). 10) isn't allowed in Mediawiki (Wikipedia). Is this a problem, like it was for COINS? 11) There might be other problems with using ... alf. [1] http://microformats.org/wiki/hcalendar [2] http://microformats.org/wiki/hreview From T.Hammond at nature.com Tue Dec 13 06:06:23 2005 From: T.Hammond at nature.com (Hammond, Tony) Date: Tue Dec 13 06:06:28 2005 Subject: [gcs-pcs-list] info URI scheme and identifiers Message-ID: <125F7834E11A5741A7D79412EE3504F91D08CCCF@UK1APPS2.mpl.root-domain.org> Hi Dan: Should clarify a couple things: 1. The INFO FAQ. Since I authored it, I can confirm that we didn't update it yet and it still reflects thinking based on the -02 draft (rather than current -04 draft) in which we sought to outlaw derefence because of problems in defining a global resolution architecture (because we had hit a similar problem previously with the DOI Internet-Draft). Feedback received caused us to reconsider and to allow that namespace authorities may choose to disclose resolution methods in their registration records. Eg, NCBI could indicate how to query the Entrez database for a PubMed ID, etc. (We still need to revisit the earlier registation records to see what can be done here.) 2. You talk about 'fake' URIs. A string is a legitimate URI if it conforms to the generic URI syntax, is used in a URI context, and presumably with a URI intent. If it is not entered in the IANA registry then it will merely be unregistered and susceptible to name collisions. But it is still a URI for all that. The revised URI guidelines Internet-Draft (Hansen 2717/18-bis) - when it appears - should lower the barrier to entry for new schemes by providing for provisional registrations, alongside permanent registrations. 3. Something else that may be of interest. I have proposed (and there's a couple guys looking into this - Jeff Yound and Patrick Hochstenbach) that we should be able to build (and distribute) some standard library modules for INFO which, inter alia, could support methods for normalization, comnparison, dereference, as well as accessor methods to registation record fields. I would think we should be able to do something useful for Perl, Ruby, and maybe Java. Be interested to get any feedback on this from the list. Cheers, Tony > -----Original Message----- > From: gcs-pcs-list-bounces@cipolo.med.yale.edu > [mailto:gcs-pcs-list-bounces@cipolo.med.yale.edu] On Behalf > Of Daniel Chudnov > Sent: 12 December 2005 17:53 > To: gcs-pcs-list@cipolo.med.yale.edu > Subject: [gcs-pcs-list] info URI scheme and identifiers > > > Apparently I've completely misunderstood what the info:sid > namespace was for; seems it's about identifying collections > for OpenURL rfr.sid values, and *only* collections. I was > under the mistaken impression that you could use it for stuff > like this: > > info:sid/myblog.example.com:entry:2345 > > I realize there's a "tag" uri scheme for this but I tend to > agree with the reasons articulated here...: > > http://info-uri.info/registry/docs/misc/faq.html#use_tag > > ...for not wanting to use it for this purpose, primarily the > dereferencing thing. > > My use case is unAPI; I want arbitrary sites to be able to > specify a single-string URI for individual content items that > themselves might be online or offline. And this needs to > work for identifiers either within or outside of the OpenURL > resolution loop. In other words, a registered namespace > prefix for unregistered namespaces, so community developers > could work out their own agreements about what the private > namespace part meant without having to register every darned one. > > In the COinS-PMH example stuff I've been using fake uris like > > oai:flickr.com:photo:12345 > oai:unalog.com:person:dchud:entry:54321 > i.e. oai:wherever:whatever > > But obviously "oai" is neither a URI scheme nor a URN namespace id. > > Hmm, folks in #code4lib just pointed out that the "tag" > scheme is better than I realized, and indeed does not have a > dereferencing > implication: > > http://www.faqs.org/rfcs/rfc4151.html > > ...which means that what I should probably do is change my > code and examples for unAPI to look more like: > > tag:flickr.com,2005:photo:12345 > tag:unalog.com,2006:person:dchud:entry:54321 > i.e. tag:wherever,somedate:whatever > > Do I understand this correctly now? I'd prefer not to go > much further with such misapprehensions. :) > > Thanks, -Dan > > > -- > Daniel Chudnov > Yale Center for Medical Informatics > (203) 737-5789 > _______________________________________________ > gcs-pcs-list mailing list > gcs-pcs-list@cipolo.med.yale.edu > http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list > ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** From daniel.chudnov at yale.edu Thu Dec 15 10:44:31 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Dec 15 10:45:40 2005 Subject: [gcs-pcs-list] info URI scheme and identifiers In-Reply-To: <125F7834E11A5741A7D79412EE3504F91D08CCCF@UK1APPS2.mpl.root-domain.org> References: <125F7834E11A5741A7D79412EE3504F91D08CCCF@UK1APPS2.mpl.root-domain.org> Message-ID: <22BB73F2-04DB-403D-9DC9-A043433F3156@yale.edu> On Dec 13, 2005, at 6:06 AM, Hammond, Tony wrote: > > 2. You talk about 'fake' URIs. A string is a legitimate URI if it > conforms to the generic URI syntax, is used in a URI context, and > presumably > with a URI intent. If it is not entered in the IANA registry then > it will > merely be unregistered and susceptible to name collisions. But it > is still a > URI for all that. The revised URI guidelines Internet-Draft (Hansen > 2717/18-bis) - when it appears - should lower the barrier to entry > for new > schemes by providing for provisional registrations, alongside > permanent > registrations. Ah, okay, this is good to know. > 3. Something else that may be of interest. I have proposed (and > there's a couple guys looking into this - Jeff Yound and Patrick > Hochstenbach) that we should be able to build (and distribute) some > standard > library modules for INFO which, inter alia, could support methods for > normalization, comnparison, dereference, as well as accessor > methods to > registation record fields. I would think we should be able to do > something > useful for Perl, Ruby, and maybe Java. Be interested to get any > feedback on > this from the list. If and when you do move forward with this, please let us know somehow. Perhaps one or more of us could see about getting another P- language onto that short list. :) -Dan -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From daniel.chudnov at yale.edu Thu Dec 15 11:11:51 2005 From: daniel.chudnov at yale.edu (Daniel Chudnov) Date: Thu Dec 15 11:13:23 2005 Subject: [gcs-pcs-list] Fwd: seen unAPI? References: <43A04514.3080301@uwindsor.ca> Message-ID: Responses from a colleague and neighbor of Art R.'s at U. Windsor, who ok'd copying to this list (and who, I'm hoping, will have joined us here before this msg goes out :). The making links reference is to Art's ever-thoughtful recent post on unAPI here: http://makinglinks.uwindsor.ca:8087/mitas/sfxblog/1134163052 Welcome, Graham, and thanks! -Dan Begin forwarded message: > From: Graham Fawcett > Date: December 14, 2005 11:15:16 AM EST > To: daniel.chudnov@yale.edu > Subject: Re: seen unAPI? > > I just read the making-links page, as well as the very interesting > discussion on the gcs-pcs-list. I like the simplicity of the unAPI > proposal, and sticking within the microformats domain probably > increases the chance of wider adoption. > > With respect to choosing -- > > * Tantek's suggestion to use tags in microformats is > interesting, but I'm concerned with the semantics; I guess > "January 25" is sort of an abbreviation of "20050125", but I'm > not > convinced of it, and if I were parsing a page to discover its > abbreviations, I'd be annoyed if this one showed up on the list. > * Regarding and/or class="uri">the-identifier. It does seem a good idea to > have both, as long as the format spec clearly dictates that title > attributes take precedence over text content. I'm not super-keen > on CSS to hide "invisible metadata", more from an accessibility > point of view (not all text-based browsers support CSS), and also > that users of content-management systems cannot always control > the > CSS applied to their content. > * The only concern I can think of w.r.t. "invisible metadata > through > title attributes" is that some HTML transformers will drop empty > elements; Tidy, for example, might strip an empty right > out > of a document. So, would > potentially get lost in a Tidy-cleanup. Wish I had some > references > for you here. Of course, you would still be able to wrap the > around any of the content that appeared on the page, so > perhaps this is a minor detail. > * It did occur to me that you could use any tag at all, not just > s -- I mean, leave the choice open to the author -- and > your > parser would search for any elements with class="uri". So, images > could get unAPI refs as well. This is nice and generic, but I am > guessing that it's bad microformat practice. > * Regarding tags, keep in mind that XHTML 2.0 is planning to > make all element types actionable; i.e., a could be > clickable if it has an href attribute, and an would, in > theory, be non-clickable if it didn't. Can't remember where I > read > that. Anyway, it doesn't matter today, and tags are > definitely > a bad idea today for usability reasons. > * If you have an associated tag for a preferred resolver > service, shouldn't "uri" appear somewhere in the 's > attributes? The example I saw in the discussion used a different > title, which made sense semantically, but which was disassociated > syntactically from the unAPI s in the page. It would be > nice > to discover the link by querying for (select * where tag='link' > and title='uri'), so to speak. > * Or, break with semantics altogether and include a > span-based definition for resolvers in your spec, e.g. class="uri-resolver" title="http://example.com/unapi/" />. Again, > content-management systems might allow for body content but not > head content. It's a bit ugly when is a viable option in > many circumstances, but it's not that bad; and as a plus, it > could > allow authors to display a list of suggested resolvers right in > their page content. > * In short, seems good, and I would vote for keeping the > title/textnode alternatives available. > > As for the identifiers themselves, the waters are slightly over my > head. You folks are way deeper into URI intricacies than I am, and > protocols whose names start with a zed and end with a bunch of > numbers make me reach for my security blanket! I do get the > "urn:isbn" example, though, and the immediate benefit of this is > clear. I could see a few non-library-related uses, though mostly > localized ones, not global services -- but I probably haven't > experienced the epiphany yet. But 'tis the season, maybe I'll see > the unAPI star in the east in a couple of days. :-) > > In short, If unAPI satisfies ~80% of your COINS-PMH requirements, > then I think it's a definite win, and I'd run with it. -- Daniel Chudnov Yale Center for Medical Informatics (203) 737-5789 From fawcett at uwindsor.ca Thu Dec 15 11:36:54 2005 From: fawcett at uwindsor.ca (Graham Fawcett) Date: Thu Dec 15 11:39:15 2005 Subject: [gcs-pcs-list] Fwd: seen unAPI? In-Reply-To: References: <43A04514.3080301@uwindsor.ca> Message-ID: <43A19BA6.5000506@uwindsor.ca> Daniel Chudnov wrote: > Responses from a colleague and neighbor of Art R.'s at U. Windsor, > who ok'd copying to this list (and who, I'm hoping, will have joined > us here before this msg goes out :). Hi Dan and friends, I just got in. :-) I just re-read the e-mail that I had sent to Dan. One clueless thing that I wrote was that "users of content-management systems cannot always control the CSS applied to their content". While not all CMS systems allow access to a document's so that one could add a