I am a user, not yet a developer, and I am not a librarian, but I like the first approach, "THUS, user sees other instances of the article through his/her bookmark," for a few reasons:
(1) the URI in the bookmark in my library contains information on my access method to the article; (2) seeing other instances via DOI match would prompt me to clean up my bookmark; (3) seems like it would fit naturally in "Posted by" somewhere, since that array already refers to other libraries. I like keeping information intact (1) but if it can be or ought to be crafted, I want to do it (2). Morgan L's suggestion is similar to (2). This is all an issue for me because my students in Connotea are a mixture of students on campus and students off campus. Their links to Nature for instance, are pure nature.com URIs if on campus, but off campus student links carry the university's proxy information embedded in the URI. I would prefer that Connotea NOT destroy that distinguishing information. And perhaps others might care to analyze those access methods for Connotea as a whole. - Thomas Brueckner (Univ. of Central Florida) On Aug 1, 2007, at 5:50 AM, Mulvany, Ian wrote: > Hi List, > > We are discussing approaches to solving the long standing issue with > Connotea known colloquially as Buggotea, where the system where the > system > is not checking that two bookmarks might be referring to the same > article if > they have different uri's but the same doi or other identifier. > Martin just > sent me the mail below and I thought I'd send it on to get any > feedback that > you might have. > > > > >> Here's an open philosophical question for you to ponder. >> >> When a user adds a URL, are they merely using it as an accessor to >> present an article that goes into their library, or are they >> linking to >> that URL in particular with a passing interest to where else the >> article >> may exist. >> >> Does that make sense? >> >> It relates to whether we keep the user_bookmark table and add an >> "outer" >> layer of abstraction to group "articles", or whether we break that >> table >> and change it to user_article postings where the articles have one or >> more bookmarks. >> >> user_bookmark = one user posts one bookmark (URL) >> article = an abstract idea of an article like a human thinks of it >> article_bookmark = relate abstract article to physical bookmark >> THUS, user sees other instances of the article through his/her >> bookmark >> (slightly easier to engineer on top of what we have now) >> >> ...or.... >> >> user_article = one user includes one article >> article = an abstract idea of an article like a human thinks of it >> article_bookmark = relate abstract article to physical bookmark >> THUS, user may be shown different bookmark than originally posted, in >> practice we probably wouldn't want to do that often but it could be a >> feature, say the user could say "prefer doi resolver today" then >> "prefer >> harvard.edu links today" etc. >> (slightly harder to engineer on top of what we have now) >> (BTW: I believe this is more like CiteULike) >> >> It can work either way, it's just a mental approach. ;-) >> >> Martin >> > > ********************************************************************** > ********** > 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 > ********************************************************************** > ********** > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Connotea-code-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/connotea-code-devel > Dr. Thomas J. Brueckner Dept. of Physics, Univ. of Central Florida 407-823-4541 Designing online physics course 2007 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Connotea-code-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/connotea-code-devel
