[CODE4LIB] NEWS RELEASE: VIVO 1.8.1 Now Available–Improved Performance, New Visualizations
FOR IMMEDIATE RELEASE November 10, 2015 Read it online: http://vivoweb.org/blog/2015/11/now-available-vivo-181-—-improved-performance-and-new-visualizations <http://vivoweb.org/blog/2015/11/now-available-vivo-181-%E2%80%94-improved-performance-and-new-visualizations> Contact: Graham Triggs <gtri...@duraspace.org <mailto:gtri...@duraspace.org>> NOW AVAILABLE: VIVO 1.8.1 — Improved Performance and New Visualizations Winchester, MA On November 10, 2015 VIVO 1.8.1 was released by the VIVO team. This new release offers users vastly improved performance, new and better visualizations, as well as bug fixes. • Download VIVO 1.8.1: http://bit.ly/vivo-1_8_1-release <http://bit.ly/vivo-1_8_1-release> Full release notes are available on the VIVO wiki: https://wiki.duraspace.org/display/VIVO/VIVO+v1.8.1+Release+Notes <https://wiki.duraspace.org/display/VIVO/VIVO+v1.8.1+Release+Notes>. Performance improvements Users should see up to 75% reduction in time to display profiles compared to VIVO 1.8, and a 30% reduction compared to VIVO 1.7. These findings have been observed on both small data sets (200 people, 3,500 articles), and large data sets (4,500 people, 40,000 articles). Most profiles - even large/complex profiles - display within approximately two seconds. Visualizations The ability to examine the VIVO network from many points-of-view is at the heart of connecting researchers, ideas and resources. VIVO 1.8.1 offers users new and improved visualizations that make it easier to “see” formative research as it emerges at individual, institutional and topic levels. Click here to see an example of the new Visualizations in 1.8.1 New Javascript based versions of Co-Author and Co-Investigator are networks available. These new visualizations do not require Flash and display on mobile devices such as phones and tablets. All visualizations have significant performance improvements. Maps of Science, Temporal Graphs and Co-author and Co-Investigator networks now all complete in just a few seconds. The very largest Maps of Science may require up to two minutes to complete. Additional Improvements New AltMetric badges are enabled on publications by default, providing direct link to AltMetric information regarding the publication. Additional improvements reduce time and resource usage for indexing and inferencing. More than a dozen have been made to improve user experience. We look forward to hearing from you about VIVO 1.8.1. Please contact VIVO Tech Lead Graham Triggs with questions, suggestions and feedback: <gtri...@duraspace.org <mailto:gtri...@duraspace.org>>. About VIVO VIVO (http://vivoweb.org <http://vivoweb.org/>) is an open source, open ontology, open process platform for hosting information about the interests, activities and accomplishments of scientists and scholars. VIVO supports open development and integration of science and scholarship through simple, standard semantic web! technologies. VIVO was originally funded by Cornell University and the National Institutes of Health (U24 RR029822) and is currently a community-supported project under the DuraSpace umbrella. How Does DuraSpace Help? The DuraSpace (http://duraspace.org <http://duraspace.org/>) organization is an independent 501(c)(3) not-for-profit providing leadership and innovation for open technologies that promote durable, persistent access and discovery of digital data. Our values are expressed in our organizational byline, "Committed to our digital future." DuraSpace works collaboratively with organizations that use VIVO to advance the design, development and sustainability of the project. As a non-profit, DuraSpace provides technical leadership, sustainability planning, fundraising, community development, marketing and communications, collaborations and strategic partnerships, and administration.
Re: [CODE4LIB] separate list for Jobs
On 8 May 2014 18:08, Scott Fisher scott.fis...@ucop.edu wrote: 4. I find arguments to the effect of I love looking at jobs² orthoginal to the discussion since weıre not talking about disallowing job postings, but just moving them to a separate list. Anyone who is interested enough in jobs could also add a separate jobs list to go to their daily email inbox, so Iım not sure how it would be a loss of all jobs emails they like. I suppose this argument essentially comes down to the same kind of argument as the pro-email-filter one. Basically that argument is, ³just do something different to receive the emails you want the way you want them.² But in this case the argument is coming right back at you from the other direction of suggting a separate email list. I have filters set up, and find they just don't work reliably. OK, they work 9 times out of 10, but things always slip through. Imho, there are more people inconvenienced by having jobs on the list (setting up filters, filters not working, unable to filter digests, etc.) than there are people inconvenienced by having a separate list for jobs (is there really anyone that can't sign up for a separate list? is it impossible to add a subscribe link to the jobs list in a footer?) (actually, I note there isn't a footer on this mailing list at all - must be one of the only mailing lists that doesn't include a footer with unsubscribe and general information. Technically, doesn't this mean it falls foul of anti-spam legislation in some territories?) G
Re: [CODE4LIB] Anyone have access to well-disambiguated sets of publication data?
Hi Paul, I guess this rather depends on your purposes. From the way you've asked the question, it sounds like you are looking for a control set of data to compare your own efforts of author disambiguation to (rather than simply having good sources of disambiguated data - presumably for feeding into a VIVO instance)? In case you haven't looked at it already, you might find the Profiles RNS Disambiguation Engine useful: http://profiles.catalyst.harvard.edu/docs/ProfilesRNS_DisambiguationEngine.pdf Although this would just cover Medline/PubMed data. This could work just as a source of disambiguated data for you, not just as a control set for your own implementations. Additionally, if you are not adverse to using other software to provide disambiguated data, rather than implementing your own solution, then you might want to look at research information management software (e.g. Symplectic Elements). These specialise in acquiring data from a number of data sources (including PubMed), and helping you create a clean, disambiguated set of publication data - and typically provide APIs that allow you to interact and/or extract that information for re-use in other systems. Regards, G On 9 July 2013 16:32, Paul Albert paa2...@med.cornell.edu wrote: I am exploring methods for author disambiguation, and I would like to have access to one or more set of well-disambiguated data set containing: – a unique author identifier (email address, institutional identifier) – a unique article identifier (PMID, DOI, etc.) – a unique journal identifier (ISSN) Definition for well-disambiguated – for a given set of authors, you know the identity of their journal articles to a precision and recall of greater than 90-95%. Any ideas? thanks, Paul Paul Albert Project Manager, VIVO Weill Cornell Medical Library 646.962.2551
Re: [CODE4LIB] It's all job postings!
On 6 August 2012 13:19, Ed Summers e...@pobox.com wrote: 150 people responded about whether jobs.code4lib.org posting should come to the discussion list: yes: 132 no: 10 who cares: 8 93% in support or agnostic seems to be a good indicator that the postings should continue to come to the list for now. I'm not entirely convinced about that assessment. I quite readily agree that the jobs should be posted to *a* mailing list, I'm not so sure that it should be this mailing list. It's been discussed about filtering the jobs sent to the list, but I already filter the code4lib mailing list into a tag. It's been a bit of a faff, but I've subdivided the filtering so that I can get the messages sent from jobs@... to go to a different tag. But then Ed replied to one, so now it appears in both tags, and because I'm using Gmail, it takes the whole thread with it. So filtering really isn't a solution. Rather than just asking whether jobs should come to this mailing list, maybe we can ask whether a separate mailing list should be set up, specifically for jobs. The two mailing lists could be cross promoted (e.g. a standard footer), and people can choose whether they want or don't want to receive them. And we can still have discussions/follow-ups about those jobs on that mailing list. Even though the vast majority of the postings aren't applicable to me, I would probably still sign up to a separate jobs mailing list as it is of interest - but I would at least then be able to keep that separate from the main discussions, which is something I can't effectively do right now. G
Re: [CODE4LIB] Metadata
On 16 February 2012 12:13, suzanne.pilsk suzanne.pi...@gmail.com wrote: (Pssst: Does it matter if you call it data and I call it metadata?) Yes. Yes it does. Although possibly not for the reasons you might think I'll give. I think it's really important that developers (and researchers) get out of the mindset that: a) metadata isn't data b) metadata isn't important c) data can't be both metadata and data Because the chances are that it is all important, but in different ways, and has different needs in frequency of use, indexing, etc. Treating everything the same, and in one big bucket, is likely to slow down the processes of indexing, locating, and scanning over possible resources. So there is a need to think about things in terms of what is required for different purposes - what is needed for locating and describing resources, and everything that is required to use those resources. And that may well mean having bits of information that are duplicated in more than one bucket. But what we can't be is scared of identifying that there are different needs and requirements, different scopes of relevant data. Or that users actually have names for these scopes. G
Re: [CODE4LIB] Metadata
On 13 February 2012 15:57, Nate Vack njv...@wisc.edu wrote: My take on this discussion, coming from a research lab: Metadata isn't meta. Well, coming from a publishing and repositories world, my take is slightly different. For example, in recordings of, say, blood pressure over time, it's common to think about things such as participant identifiers, acquisition dates, event markers, and sampling rates as metadata, and the actual measurements as data. But really: those meta things aren't ancillary to data analysis; they're essential in keeping analyses organized, and often important parameters in running an analysis at all. That's an interesting distinction though. Do you need all that data in order to make sense of the results? You don't [necessarily] need to know who conducted some research, or when they conducted it in order to analyse and make sense of the data. In the context of having the data, this other information becomes irrelevant in terms of understanding what that data says. But in a wider context, you do need such additional information in order to be able to use it. If you don't know who conducted the research, when it was conducted, etc. then you can't reference it.You can't place it into another context (a follow up study to validate the findings, or see if something has changed over time). And it's not a case of saying something has to fall into one category or another, it may be necessary / useful in both. Breaking things down into data versus metadata I think, encourages a false (and not very interesting) dichotomy. If information has a use, call it what it is: data. Store everything that's useful. The problem isn't that we have labels for data to be used in different contexts. It's that just because something does have a label [and may not necessarily be important to you in your context], that doesn't mean that it's any less important than something else with another label. G
Re: [CODE4LIB] Google Analytics w/ Sub-sub-domains
Having a quick look at your site(s), it appears that those links through resources... are redirecting through other pages. If so, it may have more to do with not being able to follow the flow of page accesses, than the ability to track a sub domain. G On Feb 7, 2012 12:30 PM, Predmore, Andrew andrew.predm...@yale.edu wrote: Yes, the code is not consistent across our pages. That is the problem I am trying to solve. The pages are served by dozens of different systems. Therefore, I had held off on changing all of them until I knew I had working code. At this point, based on my research and the feedback here I will be going with this: _gaq.push(['_setDomainName', '.yale.edu']); After I get that code on the majority of pages, I can start looking into the separate problems I am having with drop-offs and setting up a profile that will show me the sub-domains. Thank you to everyone for the help. -- Clayton Andrew Predmore Manager, Web Operations Yale University Library andrew.predm...@yale.edu On 2/6/12 4:53 PM, Brian Tingle brian.tingle.cdlib@gmail.com wrote: Henry, that is what you need to do if you want to track the same page to two different google analytics properties and you are using the legacy synchronous code. It sounds like yale wants to collect all this use under one UA- google analytics property (it is just that the property spans multiple subdomains). I think the link I sent to http://code.google.com/apis/analytics/docs/tracking/gaTrackingSite.html ht tp://%22 addresses the yale case; and I the way I read it adding this: _gaq.push(['_setDomainName', '.yale.edu']); Or _gaq.push(['_setDomainName', 'library.yale.edu']); on _every_ page should work. Right now, I only see _setDomainName on the home page. If this is not the _same_ on all the pages, the cookies won't be shared as users move between the sites. For example; view-source:http://www.library.yale.edu/researcheducation/ This page is missing _gaq.push(['_setDomainName', '.yale.edu']); It will only work prospectively (it won't change the past) but when all pages are sharing the same _setDomainName then they should all share the same cookies and the links between pages should be counted correctly. But google analytics can get tricky, just when I think I understand something it changes. I find I have to double check things a lot with the debug toolbar to make sure the right stuff is getting sent to google (esp. when setting up custom events or setting up multiple trackers on the same page). You should be able to use it to verify that the same session and cookies are being used as you go from page to page. In the chrome debug nowadays you can right click on the console log and select Preserve Log upon navigation which makes this a lot easier.
