162,015 research outputs found
Cloud collaboration: Using (Microsoft) SharePoint as a tool to enhance access services
No full textOutline
•About Us
•Intranet overview
•Cloud computing overview
•Move to SharePoint
•SharePoint Wiki for Remote Circ Locations
•SharePoint as Comprehensive Cloud Intranet
•ConclusionCloud Collaboration:
Using (Microsoft) SharePoint as a Tool to Enhance Access Services
Jennifer Diffin
Assistant Director for Systems and Access Services
Fanuel Chirombo and Dennis Nangle
Library Technicians
April 29, 2010
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleOutline
•
About Us
•
Intranet overview
•
Cloud computing overview
•
Move to SharePoint
•
SharePoint Wiki for Remote Circ Locations
•
SharePoint as Comprehensive Cloud Intranet
•
Conclusion
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleHistory of UMUC
•
Founded in 1947
•
Primarily distance education serving working professionals
•
Approximately 86,000 worldwide headcount (~27,000 FTE)
•
Member of the University System of Maryland and Affiliated Institutions (USMAI)
•
Military contracts
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleInformation & Library Services (ILS)
•
Staff located in Largo, MD
•
Previously had physical libraries in Germany and Japan
•
Remote/satellite locations change
•
27 library staff members, 2 graduate assistants
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocument Management (DM) Team
•
1 Librarian
•
1 Library Associate
•
3 Library Technicians
•
4-5 student workers (shared with other library departments)
•
Remote circulation points throughout Maryland
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleILS Circulation Locations
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleOverview of Intranets
•
What is an intranet?
•
Functions of Intranets
•
What are the benefits
•
Limitations of UMUC Intranet
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleWhat is an Intranet?
•
A private network belonging to an organization’s members, employees, or others with authorization.
•
“…part of the organizational internal information system, dedicated to the support of group work and mastering of organizational knowledge.”
Botazzo, 2005
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleFunctions of Intranets
•
Administrative –finance, human resources, records management, course scheduling.
•
Academic-research, course work, publishing and course administration.
•
General-communication and public relations.
Weiner, 1999
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleWhat are the Benefits?
•
Sharing information and documents
•
Easy updating of documents
•
Saves time through online discussions
•
Quick and easy access to vital information
Natarajan, 2008
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleLimitations of UMUC Intranet
•
Restricted contributors-difficult to update, edit and/or access.
•
Interdepartmental promotional tool.
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCloud Computing-An Overview
•
Became an official ‘buzz word’ in 2006
•
Has several definitions and contexts
•
An ‘official’ definition:
–
“In cloud computing…the software resides on an [I]nternet server run by or on behalf of the software supplier, and users get to access the features of those applications via the [I]nternet”
Venkatraman, 2009
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleA Helpful Metaphor for Cloud Computing
“My attitude towards online information…was pretty close to taking my paycheck in cash, and stuffing it under the mattress because I didn’t trust a bank to hold it for me… Now we can treat the [W]eb much more like a bank with a network of ATMs: it’s a secure repository with a network of points where you can withdraw your information on demand.”
Gunderloy, 2008
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleThe Appeal of the Cloud
•
Cost-effective
•
Efficient
•
Fosters Innovation
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCloud Concerns
•
Security
•
Privacy
•
Data Ownership
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleThe Road to SharePoint
•
A Complex History
•
Initial Obstacles
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleA Careful Approach
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleSharePoint in Context
•
Departmental Move
•
Creating a service point without ILS staff
•
Developing a wiki for the new service point staff
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleEffective Knowledge Transfer
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocumentation Pre-SharePoint:
Dorsey StationWaldorf CenterCollege ParkAdelphi
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocumentation Post-SharePoint:
Dorsey StationWaldorf CenterCollege ParkAdelphiLargo
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleDocument Management’s “Cloud Intranet”
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleSharePoint-a Comprehensive Cloud Intranet
•
Information storage
•
Coordination
•
Communication
•
Collaboration
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleInformation Storage
•
Wiki for remote location of information
•
Document library
•
One-stop location of documents
•
Secure and easily accessible
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCoordination
•
Calendar
•
Work scheduling
•
Leave scheduling
•
Responsibilities
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCommunication
•
Discussion Board
•
Announcement
•
Sticky Notes
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleCollaboration
•
Version History
•
E-mail alerts
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleConclusion
•
Cloud Intranet
–
Convenient to access
–
Secure server
–
Flexibility
•
Strategy is essential
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleQuestions?
Jennifer Diffin –[email protected]
Fanuel Chirombo –[email protected]
Dennis Nangle –[email protected]
© Jennifer Diffin, Fanuel Chirombo, and Dennis NangleReferences
•
Bottazzo, V. (2005). Intranet: A medium of internal communication and training.Information Services & use, 25(2), 77-85. Retrieved from http://www.iospress.nl/html/01675265.php
•
Gunderloy, M. (2008). Is your information under the mattress or in the ATM?.Retrieved 12/11, 2009, from http://webworkerdaily.com/2008/07/30/information-under-mattress-or-in-atm/
•
Natarajan, M. (2008). Knowledge sharing through intranet.Journal of Library and Information Technology, 28(5), 5-12. Retrieved from http://publications.drdo.gov.in/ojs/index.php/djlit/article/view/414/286
•
Venkatraman, A. (2009). Capture the cloud.Information World Review, (255), 16-17.
•
Weiner, S. (1999). The university intranet.EContent, 22(5), 66-69. Retrieved from http://www.econtentmag.com
© Jennifer Diffin, Fanuel Chirombo, and Dennis Nangl
[Report to Chief J. E. Curry, by an unknown author #1]
No full textReport to Chief J. E. Curry, by an unknown author. The report contains a list of officers who gave depositions to the United States Attorney
[Report to Chief J. E. Curry, by an unknown author #2]
No full textReport to Chief J. E. Curry, by an unknown author. The report contains a list of officers who gave depositions to the United States Attorney
Library systems documentation: Pulling it together with SharePoint
No full textDocumentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge.Library Systems Documentation: Pulling it Together with SharePoint
Introduction
Documentation is crucial for a library systems office. But how have systems librarians documented their procedures, organized their documentation, and shared their knowledge? What tools do they use? This article will explore these issues and provide a case study of how the library Systems Team at the University of Maryland University College implemented SharePoint as a portal to organize and share their collective knowledge.
Why is documentation so important? Those who claim that documentation is not so important because “anyone in the future should be able to figure out what was done in the past” should “[m]ake that argument to someone who has inherited an undocumented network and watch the response!” (Wilson, 1998, p.100). The goal of documentation is “to keep technology running smoothly and serving the good of the institution” and “includes organizing, collocating, and disseminating the knowledge that will help you and others succeed in your library’s technological environment.” It also provides “a concrete pool of evidence for you to point to in describing the importance of your department’s function to your institution” and “paints a picture of what you have done and of the technological environment that needs supporting (Engard and Gordon, 2012, p. 94).”
What needs to be documented? “Think of the information that would have made your job easier and provide it for yourself, your staff, and your successor” (Engard and Gordon, 2012, p. 94). Document “how you do things so that if you have to do them again, you don’t have to start from scratch trying to remember how” (Rossman, 2003, p. 22). This includes configuration information for networks, servers and computers, maintenance procedures, as well as support issues and problem resolutions (Engard and Gordon, 2012). It is also important to establish a method for consistently documenting procedures and decisions (Wilson, 1998).
How should things be documented? For common tasks, provide step-by-step instructions and be liberal with screen shots. These will coalesce into “a pool of documentation” for the systems staff (Engard and Gordon, 2012). From a higher level, to organize that pool into an effective portal, it is especially important to develop a carefully thought-out taxonomy, mapping out your sites, content types, and navigation, as well as a governance strategy for its ongoing management (Buckley, 2011).
What tools are available? Common tools available in organizations include intranets, shared network drives, shared e-mail folders, help desk ticketing systems, and document management systems (Engard and Gordon, 2012; Lappin, 2010). A centralized portal and a tool that can manage records in multiple formats are desirable (Lappin, 2010). Large-scale enterprise content management (ECM) systems exist, but what many organizations really need is a system that provides basic content services (BCS) such as Microsoft SharePoint, which is a dominant player in this field (Pelz-Sharpe, 2008). SharePoint is of particular interest because it provides an integrated portal platform that combines document management tools with Web 2.0 communication and collaboration features, and it is readily available to Microsoft customers as part of the Microsoft Core Access License (CAL) Suite for institutions (Dahl, 2010; Diffin and Nangle, 2011). Wikis and Document Libraries provide a means of collaboratively creating, editing, storing, and managing documents. Many types of files can be stored in the Document Libraries, and SharePoint is designed to work seamlessly with Microsoft Office (Dahl, 2010). Announcement, discussion, and blog tools allow a centralized hub for managing a team’s communications. Calendar and survey tools are also included, as are workflow tools for managing projects and tracking issues (Herrera, 2008).
What have other libraries done? In the literature, there are a number of examples of libraries that have implemented SharePoint for documentation and communication. For example, SharePoint has been implemented at Towson University to create a portal for the reference team (“RefPortal”) (Dahl, 2010); at the University of Mississippi to build departmental sites (Herrera, 2008); at the University of Maryland University College for the Document Management Team (interlibrary loan and book delivery) (Diffin et al., 2010b); and at the University of Alabama for instruction requests, reference, and interlibrary loan (Ennis and Tims, 2010).
At the University of Mississippi, the library’s Information Technology department has a SharePoint site, and they use SharePoint’s blog for IT alerts and news items and have developed wiki pages for setup and troubleshooting tips (Herrera, 2008). At the University of Alabama, after developing their initial SharePoint sites, the library used SharePoint to create “Help Central,” which functions as a help desk and knowledge portal. It provides a ticketing system for users to report issues, for the staff to track and monitor the tickets, and for solutions to be added to a knowledgebase (Ennis and Tims, 2012).
The present article will elaborate further on how SharePoint can be used as a portal for systems documentation, and discuss how a taxonomy was developed, how the actual documentation was written, and some of the best practices that were adopted.
Background
UMUC Library Systems The University of Maryland University College (UMUC) is a predominantly distance education institution serving more than 97,000 students in more than 25 countries (University of Maryland University College, 2012a, 2012b). Information & Library Services (ILS) relies heavily on technology to deliver library services to students, faculty, and staff worldwide. The Systems Team consists of four librarians: a Systems Librarian, a Digital Services Librarian, an Advanced Technologies Librarian, and a Web Specialist. Each of these librarians has very specialized knowledge, which makes it difficult for anyone else to fill in on those duties. (For the purposes of this article the Digital Services Librarian is being considered as a second Systems Librarian, in that this position also provides technical support for faculty, staff, and students.) The team manages a wide variety of areas, including access to electronic resources, server applications, software installation, cataloging, and the Web site. Other responsibilities include developing multi-media learning objects, in-house databases, and customized programs for the Web site.
Before SharePoint Before implementing SharePoint, all of the four team members managed their own documentation. There was a tendency to use the library’s shared network drive (the “S-drive”), but team members also kept documentation on their individual computers and in file cabinets, and much was kept in their own heads. Some procedures were documented; some were not. There was no systematic effort in creating, organizing, and sharing knowledge among the whole team, and there were no best practices. Documentation on the S-drive could be difficult to find and sometimes became outdated.
Earlier, some of the staff members had made “Survival Guides” listing where their documentation was stored, and the Systems Librarian compiled a local “Procedures” Web page to try to point to all the various documentation, but none of these were consistently maintained or were ever heavily used. What the team needed was a central portal and more consistent procedures for documentation.
Cross-training initiative Since ILS is a small library, it is critical to have training and documentation that allows someone to step in for another person and keep things moving in case of absences due to illness or vacations. The Document Management and Electronic Reserves (EReserves) Teams had recently embarked on a successful cross-training initiative that included using SharePoint for documentation and conducting cross-training sessions between the two groups. To keep the knowledge fresh once the initial training was complete, every member of both teams worked in the other area one day a month.
SharePoint was chosen as the collaboration tool because it was designed specifically to manage documents, share information, and facilitate communication. Plus, the UMUC IT department had a license for it and had made it available without the library incurring any additional cost. While other options were considered, such as free, online wikis, none of them had all the functionality offered by SharePoint. Also, these services could disappear or become fee-based at any time, and there was no guarantee that data would be retrievable if the services went down. Knowing that the IT department hosted the secure SharePoint server and that they backed it up daily eliminated the concern for potential data loss (Diffin et al., 2010b, p. 231).
The cross-training worked so well that the Assistant Director for Systems and Access Services then expanded the idea to the Systems Team. Using the concepts learned by Document Management and EReserves, the Systems Team began a more formalized process of sharing and documenting knowledge.
Implementation
Getting started The Assistant Director for Systems and Access Services had some initial meetings with the Systems Team to discuss the cross-training project and to decide how the team would proceed. The main focus of this project would be building the knowledgebase. The UMUC IT Department had created a SharePoint site for the Library, and a Systems sub-site was added. The launch of the Systems site created a sense of community among the team members and officially marked the beginning of the implementation.
Site structure As part of the planning, the first priority was to develop the site structure. This provided a fresh start to reorganize the documentation strategically. The structure and hierarchy was mapped out according to the team member functions, including: cataloging, electronic resources, in-house applications, IT (hardware, software, and server management), multi-media learning objects, patron and staff assistance, and Web site management, plus useful contacts. Best practices and conventions Given that the Document Management Team had already “implemented best practices for the wiki so it would have a homogenous look and feel even though several different people were working on it” (Diffin et al., 2010a, p. 575), a member of that team was invited to speak to the Systems Team. He covered the basics of SharePoint’s tools and features and shared best practices on style and visual aids. Verdana was chosen as the text font and standardized sizes were adopted for content and headers. Annotated screenshots were preferred over descriptive paragraphs for concision. Breadcrumb trails would be added to the very top of every wiki page for navigation. Internet Explorer became the preferred browser when updating wiki pages because important formatting features in SharePoint were exclusive to this browser.
A consensus was reached that the wiki feature would be used as the main tool for creating, organizing, and sharing documentation because of the following features, as summarized by Diffin and Nangle (2011, p. 136):
1. Editing and updating is easy through the WYSIWYG (What-You-See-Is-What-You-Get) editor.
2. Errors can be quickly and easily undone using version history which encourages collaboration. SharePoint creates a new version of the document whenever any change is made in a document.
3. E-mail alerts inform subscribers of any changes to wiki pages.
4. Permissions can be added to selected pages that contain sensitive information.
5. Visual aids (e.g. screenshots) can be inserted to simplify documentation.
In addition, all wiki pages can be distributed and shared via URLs.
The Systems Team then came up with documentation conventions for the wiki pages that specified several recipe-style elements to be included as needed, such as background information, tools, how-to steps, and problem resolution. Tools included what the user would need (e.g., software, user IDs and passwords, directories) to complete the documented task. The how-to section included step-by-step instructions with screenshots. Problem resolution indicated things that have gone wrong and steps that were taken to fix the issue.
When the rubber hits the road Based on the job duties, the responsibilities for creating content in SharePoint were divided among the four library professionals. The Systems Librarian was responsible for Web sites, cataloging, and IT. The Digital Services Librarian documented electronic resources and provided assistance with Web sites. The Web Specialist worked on in-house applications. The Advanced Technologies Librarian covered the multi-media learning objects. Each member decided on the structure and content within their assigned functional areas while still following the basic agreed-upon guidelines and conventions.
The Systems wiki site then started to take shape. Over time, the initial structure was fleshed out considerably, as documentation was migrated from the S-drive or created anew. In some cases, sub-menus were created to refine the organizational structure. For example, the top-level IT page linked to a page called “Server Applications,” which in turn linked to pages on EZproxy, ILLiad, and PeopleSoft.
As documents migrated off the S-drive and were converted into wiki pages, shortcuts were provided from the S-drive to the new SharePoint site so that anybody looking for the old documents could get to the new documents quickly. Perhaps more importantly, links were provided in SharePoint to the documentation that still resided on the S-drive, so that SharePoint could effectively function as a portal to all or most of the documentation. The idea was that a user could come to SharePoint and still get to everything, even if some things were still on the S-drive.
While Word documents on the S-drive were generally re-done in wiki format, other types of documents (e.g., spreadsheets) were simply uploaded into SharePoint into the “Documents” area. These were organized into subfolders as needed, and were linked to from wiki pages where appropriate. The S-drive would still be needed for certain types of files, such as software installation executable files. Also, documents that were not currently in use but were needed for historical purposes would remain on the S-drive and not migrated.
During implementation, monthly team meetings were scheduled to review progress. The members presented their new wiki pages, elaborating on the procedures, policies, and knowledge contained therein. The other team members then had a chance to ask questions about the procedures. For example, one member asked for clarification on how Captivate tutorials were created; another asked for details about updating electronic resources. This cross-training enabled all the team members to become familiar with each other’s work and to know where to look if questions came up during a team member’s absence. After much of the initial documentation was created, team members made an ongoing effort to review and update their pages and met every few months to discuss the updates. They signed up for e-mail alerts to be notified when pages were updated.
The Result
The home page The Systems home page includes a checklist of important maintenance functions in the center. On the right is a who’s who, indicating which staff have responsibilities for the various areas. At the bottom of the home page is a list of current projects. The site navigation bar on the left contains the menu linking to the top-level functional areas of the wiki. Also included on the navigation bar are standard SharePoint links to “Documents” (the library of uploaded documents, such as spreadsheets), “Pictures” (in this case, the library of uploaded screenshots), and other tools (Calendar, Lists, Discussions, Sites, People, and Groups).
1. Home page
Organization The major functional areas, comprising the top-level navigation, are as follows:
Cataloging: This includes cataloging and weeding procedures, links to useful documentation (such as MARC standards), and the necessary tools (such as OCLC logins).
Contacts: Important contact information for the IT department (including after-hours and emergency numbers), plus other UMUC units and external vendors of vital importance, as well as the after-hours contact information of the library Systems Team members is gathered here.
Electronic Resources: Providing technical support for electronic resources includes documentation on setting up, branding, and troubleshooting electronic resources, maintaining the SFX linking service, and obtaining Lexis.com IDs for the Legal Studies program.
In-house Applications: This section includes documentation on special processes that were created by or for the library. These include everything from Access and MySQL databases that were created for in-house use, outward-facing systems such as the electronic reserves request system used by faculty, and processes involving external systems, such as the nightly processes that extract patron data from PeopleSoft and load it into the library catalog.
IT: This section became a launchpad for a broad range of systems documentation, including equipment inventories, software installation instructions, server applications (such as EZproxy and ILLiad), and IP and domain information. Learning Objects: Documentation in this section covers how multi-media and interactive learning objects on the library Web site were created and are maintained.
Patrons and Staff: This section includes tools for assisting patrons (e.g., verifying whether a patron is current), a setup checklist for new employees, how-to pages for library staff (e.g., how to access network printers, tips for using Dreamweaver), plus links to some of IT’s help pages (e.g., about using UMUC e-mail and calendars).
Web Site: The Web site management page contains documentation on how to use the content management system and what Web site conventions are in use (e.g., image and file naming conventions). 2. Top- level page for “IT” category
3. IT > Software Installation
4. IT > Software Installation > ILLiad
Project management Although not initially considered during the planning stages, SharePoint has also been used by some of the staff as a simple project management tool. Pages have been set up for special projects, indicating to-do lists and timelines. These pages will be saved after project completion in order to document what was done. “Project” sections have been added to the top-level pages as needed, with links to these pages. Links to current projects are also placed on the Systems home page for easy access.
5. Project page that was developed when servers had to be taken offline for a facilities electrical upgrade
In fact, SharePoint was used by the authors to collaborate on this article. A project folder was created in the Document Library, and each added a Microsoft Word document with their respective parts. The parts were then combined into a master document that was reviewed by the group. Further changes were made to the master document by the individual members with Word’s change tracking feature turned on, and SharePoint prevented more than one individual from working on the document at a time. The group then met again and reviewed the changes, approving or modifying them as needed. No documents were e-mailed back and forth, nor was there any confusion about what version was the most up-to-date. SharePoint, in conjunction with Word, proved to be a very useful collaboration tool.
Conclusion
SharePoint has been a very successful portal for the Systems Team. There is now a single, consistent interface for documenting and sharing knowledge and procedures. Having one central, structured location for documentation works much better than e-mailing how-to instructions back and forth or trying to find documents on the departmental shared drive. Links to wiki pages can be sent easily to library staff who ask about specific procedures.
The two Systems Librarians, who need to cover for each other, have particularly benefitted and have been the heaviest users and biggest advocates. Having their documentation readily available is critical for the Assistant Director for Systems and Access Services, who also provides back-up coverage for technical support.
The initial planning of the interface gave it a solid structure on which to grow, and consistent procedures for creating documentation have helped it grow in a somewhat orderly fashion. Placeholders for items that still need to be documented have been put in place, as have links to documentation that still lives on the shared network drive, enabling SharePoint to function as a more comprehensive portal. While the top-level structure has been stable, some of the lower-level structure may need some adjustment, as some pages have ended up getting buried. For example, to find the page on DreamWeaver Tips from the Systems wiki home page, the user has to click on Patrons & Staff on the left navigation menu, then on a link to Staff Instructions, and finally on a link for the DreamWeaver Tips page. This has frustrated some library staff members.
Creating and updating wiki pages in SharePoint is not difficult due to the WYSIWYG editor
Murder on the mountain: author talk with Peter J. Wosh
No full textAuthor talk by Peter J. Wosh on May 5th, 2022, on his book, "Murder on the Mountain: crime, passion, and punishment in gilded age New Jersey.
Mr. Melvin J. Collier, RWWL AUC, June 2011
No full textThis video is a conversation with Mr. Melvin J. Collier. Mr. Collier talks about his book, "From Mississippi to Africa: A Journey of Discovery". Daniel Le, AUC Woodruff Library, is the interviewer
Predictors and consequences of achieving persistent remission, intermittent remission or never achieving remission in patients with recent onset inflammatory polyarthritis: Results from the norfolk arthritis register (NOAR)
No full textBackground: Relatively few studies have assessed sustained remission over a follow up of more than three years and at multiple time points to identify predictors and consequences of remission in patients with inflammatory polyarthritis (IP) and its subset rheumatoid arthritis (RA). Objectives: To assess: i) which baseline clinical and demographic factors are associated with achieving persistent remission (PR), intermittent remission (IR) or never achieving remission (NR) in patients with IP and ii) the association between achieving PR, IR or NR on functional disability progression. Methods: Patients aged >16 yrs with recent onset IP (≥2 swollen joints lasting for >4 weeks and symptom duration <2 years) were recruited to NOAR from 2000 to 2008. Baseline variables collected included age at symptom onset, BMI, C-reactive protein (CRP), rheumatoid factor (RF), anti-cyclic citrullinated peptide (anti-CCP) antibody, DAS28-CRP, HAQ score and self-reported comorbidities. Remission was defined as no tender or swollen joints (out of 51) and was assessed 1, 2, 3 and 5 years after baseline. Patients were classified as NR if they were not in remission at any anniversary assessment, PR if they were in remission at ≥3 consecutive anniversaries and IR otherwise. Univariate and multivariate ordinal logistic regression analyses were used to assess the association between baseline characteristics and remission group (NR was the lowest order group). A stepwise variable selection process was used to derive the multivariate model. Missing values were imputed using multiple imputation by chained equations in the multivariate model. A random effects model was used to examine the effect of remission group status on HAQ scores over time. Results: 868 patients were included in this study; 65.8% female, mean age at symptom onset 55.9 (SD 14.6) yrs and median disease duration 6.5 [IQR 4.1 to 11.1] months at baseline. The number (%) of patients achieving NR, IR and PR was 471 (54.3), 296 (34.1) and 101 (11.6), respectively. In univariate analysis, female sex, higher number of swollen or tender joints, satisfying the 2010 RA criteria, higher HAQ and DAS28-CRP scores, having at least one comorbidity, being hypertensive, depressed or obese at baseline were all associated with lower odds of being in a higher remission group (table). Female sex, higher number of tender joints, CRP, DAS28, HAQ, time from symptom onset to starting DMARD treatment and being hypertensive at baseline were independently associated with lower odds of being in a higher remission group in a multivariate model. IR and PR were associated with a reduced HAQ score compared to NR (referent), adjusted β (95% CI) for IR and PR -0.51 (-0.60, -0.43), -0.85 (-0.98, -0.72) respectively, p<0.001. Conclusions: Only 11.6% of patients achieved PR during a five year follow up. As well as clinical and demographic factors, comorbidities at baseline were significantly associated with reduced probability of remission. Benefits of remission in terms of improved functional disability were seen, supporting the “treat to target” strategy. (Figure presented)
A Tripartite Post-Recession Rebalancing
No full textIn this latest Advance & Rutgers Report, entitled “A Tripartite Post-Recession Rebalancing,” Dean James W. Hughes and Professor Joseph J. Seneca deliver an incisive assessment of the current market conditions and obstacles in the path of our economic recovery. They offer a statistical cautionary tale that the private and public sector need to hear and acknowledge in order for the economy to make continued progress.This report was published as Issue Paper Number 7, November 2011, in Advance & Rutgers Report
Evidence for the decay B0→J/ψω and measurement of the relative branching fractions of meson decays to J/ψη and J/ψη′
No full textFirst evidence of the B 0 → J / ψ ω decay is found and the B s 0 → J / ψ η and B s 0 → J / ψ η ′ decays are studied using a dataset corresponding to an integrated luminosity of 1.0 fb -1 collected by the LHCb experiment in proton-proton collisions at a centre-of-mass energy of sqrt(s) = 7 TeV. The branching fractions of these decays are measured relative to that of the B 0 → J / ψ ρ 0 decay:frac(B (B 0 → J / ψ ω), B (B 0 → J / ψ ρ 0)) = 0.89 ± 0.19 (stat) - 0.13 + 0.07 (syst),frac(B (B s 0 → J / ψ η), B (B 0 → J / ψ ρ 0)) = 14.0 ± 1.2 (stat) - 1.5 + 1.1 (syst) - 1.0 + 1.1 (frac(f d, f s)),frac(B (B s 0 → J / ψ η ′), B (B 0 → J / ψ ρ 0)) = 12.7 ± 1.1 (stat) - 1.3 + 0.5 (syst) - 0.9 + 1.0 (frac(f d, f s)), where the last uncertainty is due to the knowledge of f d / f s, the ratio of b-quark hadronization factors that accounts for the different production rate of B 0 and B s 0 mesons. The ratio of the branching fractions of B s 0 → J / ψ η ′ and B s 0 → J / ψ η decays is measured to befrac(B (B s 0 → J / ψ η ′), B (B s 0 → J / ψ η)) = 0.90 ± 0.09 (stat) - 0.02 + 0.06 (syst)
The vanishing author in computer-generated works: a critical analysis of recent Australian case law
No full textAbstract
The use of software is ubiquitous in the creation of many copyright works, yet the requirement in copyright law that every work have a human author who engages in independent intellectual effort means that its use may prevent copyright subsistence. Several recent Australian cases have refocused attention on authorship as an essential criterion of copyright subsistence, and these cases suggest that much computer-produced output may be authorless and thus lack copyright protection. This article, the first in a two-part series, analyses how each case deals with the question of authorship of computer-produced works and why the use of software diminishes copyright protection for a significant number of computer-generated works. The article critiques the application of conventional notions of human authorship developed in the pre-computer age to modern productions and suggests alternative approaches to authorship that satisfy both the major objectives of copyright policy and the need to adapt to the computer age. The article argues that, without a broader judicial approach to authorship of computer-generated works, Parliament must remedy the lacuna in protection for these ‘authorless’ works. Possible solutions for reform are suggested. In a forthcoming article, the author comprehensively examines those reform proposals
- …
