Menu
▾
▴
[Connotea-code-devel] FW: Approaches to solving Buggotea
|
From: Mulvany, I. <i.m...@na...> - 2007-08-01 11:10:22
|
> Personally, I would prefer either method compared to what is currently in > place. > > I do have one suggestion that would probably be easier than either choice > below, but is from the user perspective and may be the same as the first > choice > > If I bookmark a new article and it exists already in my collection I would > like to be prompted asking me whether I would like to replace (keep new > bookmark only), change the existing (keep the old one and make edits to it), > or make a new one (keep old and new bookmark so that users can still have > multiple bookmarks to the same article). > > When I view my bookmarks, the "number of others" should actually link to the > number of people who have linked the article independent of the url they used. > > Hopefully, this helps and is clear. Looking forward to the new version!! > > Morgan Langille > > On Wed, 01 Aug 2007 10:50:52 +0100 i.m...@na... 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 >> > Con...@li... >> > https://lists.sourceforge.net/lists/listinfo/connotea-code-devel >> > > > > ------ End of Forwarded Message ******************************************************************************** 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 ******************************************************************************** |
