Child pages
  • TurnItIn Integration
Skip to end of metadata
Go to start of metadata

A place to gather requirements for a new TurnItIn integration with Sakai. (See also existing TurnItIn implementation.)

 

11/10/2013 - New TurnItIn API (Adam Marshall)

As far as I know, iParadigms intend to withdraw support for the current API ("the Sakai API") in December 2014. There is a replacement API which the Apereo Foundation has permission to program against. details are here: Sakai Turnitin Home

The University of Oxford is part-way (60-70%?) through yet another Sakai - TurnItIn integration rewrite but unfortunately does not have time to work on this until at least October 2014.

I would like to collect a list of institutions who use TurnItIn via Sakai with a view to setting up a consortium who can help Oxford develop and support the new integration. Oxford simply doesn't have the resources to do this alone.

01/08/09 - Turnitin-Sakai Integration/Patch Functional Specification v.2.0

Happy New Year everyone!
Sorry for the delay in posting, but I've attached a revised functional specification after incorporating feedback and suggestions.
Just an update - after talking with Indiana University as well as the LAMP schools, it seems that the Assignments 2 tool is almost completed and shooting to be deployable by May/June of 2009 and included in Sakai 2.7. It makes sense for us to try and build to that if that is going to become the standard. While there are a good number of differences between Assignments 1 and Assignments 2, the concept of how the integration/patch would work and the touch points are essentially the same, it's just that the UI will be different and how we implement it on the back end would be different.
We're looking to be a part of their pilot and hopefully can begin development soon against Assignment 2.

11/04/08 - Turnitin-Sakai Integration/Patch Functional Specification

As promised, Unicon has finished the initial draft of the specification, and it is attached to this wiki page (see attachments) for your review and feedback.

Please send comments, feedback and questions to:

David Wu, iParadigms, davidw@iparadigms.com

As mentioned in my previous email, please try and get the feedback back to us by 11/18.

This is a great step in moving forward to building out a tight integration, and I look forward to hearing from you.

----------------------------------------

In an effort to spearhead the development of a Turnitin-Sakai integration/patch, as mentioned in my previous email copied below, iParadigms, in conjunction with UNICON, has begun the process of coming up with a functional design/specification of what a Turnitin-Sakai integration would look like. UNICON is helping us to write the document, and we expect the initial draft to be ready by 11/4. We are hoping to allow interested parties to give their feedback on the document, which would help us have a better idea of how our customers would like to see the integration work or help us find areas we didn't take into consideration. However, because we are on a timeline, we'd like to get this feedback as soon as possible, preferably within two weeks from 11/4. Hopefully this advanced notice will help you allocate some time and resources to be able to look at this within the given timeframe. We hope to begin development based on this specification at the end of the two-week period.

Please be aware that this integration/patch will be for the Assignments 1 tool in Sakai (we hope to be able to adapt this to the Assignments 2 tool when it is ready and in production, which we've heard is scheduled for Sakai 2.7 to be released in Summer 2009 – please let us know if this is incorrect).

You can send your feedback and suggestions to myself and/or our contact at UNICON, Kate Valenti. More details to come when we send out the document on the 4th.

We hope that this document will present an integration that will be the most useful for Sakai users, and thus your feedback would be very helpful. Please feel free to pass this on to any other interested parties you might know of.

---------------------------------

My name is David Wu, and I am the lead developer for integrations at iParadigms, the makers of Turnitin. Over the past few years, we've had increasing requests for an integration between our Turnitin product and Sakai, and we've been exploring different ways that this might be best accomplished.

I've put out this announcement on the developers list, but I didn't get too many responses, and I thought I'd try it here, to see if there is any interest.

"iParadigms (the makers of Turnitin) have been hearing from various clients over the past couple of years interest in an integration between Sakai and Turnitin. We would definitely like to collaborate and work on such a project. We are aware that the University of Cape Town has already developed an integration for their own needs, and we think that is a great start. With the development of the new assignment tool in Sakai, we'd like to take this opportunity to take an integration even farther by making sure that our integration will work with this new assignment tool and that it will integrate and work nicely with the built-in features of Sakai. To do so, we'd like to come up with detailed requirements and specifications of what this integration would look like, hopefully to be generated by those universities that are interested in such an integration, so that we know that what we should build will be as much of what the people who are going to be using it want. Also, in developing this integration, we know that we could go the route of trying to do it ourselves, but seeing as how I am not familiar with Sakai like many of those in the community, an integration done by ourselves might take a lot longer to develop and not be done in the best, most-efficient, complete way. We believe that if there are developers out there who are much more familiar with Sakai, the APIs, the right functions to use, the right places to insert code, etc., and that they are willing to work with us on this, that would be the best way to make the integration. Our team would be willing to learn and help develop on the Sakai end however we can, and of course we would develop the Turnitin side of the API and any other hooks, etc. that would be needed to make the integration with Turnitin work. We would like to see who out there would have the time and the resources to help in coming up with the requirements and specifications as soon as possible and then passing that around to get as much feedback as possible. From there, we would also like to see who out there would have the time and resources to help in developing the integration on the Sakai end. We are definitely interested in getting this started, rolling and finished as quickly as possible, and we look forward to working with you on it."

However, though there were a couple of institutions that responded, we haven't gained much traction. It seems there is interest, but not a lot of available resources to help work on the integration.

I'd still like to try to get a few interested institutions involved, but it was also suggested to put out there if that institutions could not put in people resources into working on such a project, perhaps they might have budget to help fund an integration where Turnitin could work with a commercial/contracting development group to help us design and develop this integration to get the ball rolling.

Please let me know if you're interest and capabilities lie in either area. I appreciate your feedback.

---------------------------------------------

Requirements for Turnitin/Sakai Integration (draft)

1)     All accounts must be based on the course owner or instructor of record.

2)     The UI should be based on current - known - views that instructors have used in the past

3)     Authentication to Turnitin should be passed from Oncourse without requiring a reauthentication

4)     Submissions, and types of submissions need to be dependent on the assignment'sparameter - single vs. multiple submissions of a single papera)     

  • Support option to allow students to see "Originality Reports"
  • Support option to allow submissions after the due date (dependent on assignment late submission policy - currently in place with assignment tool)
  • Allow other papers to be checked against submissions

5)     Allow for submission comparison against these search targets:

  • General student paper database
  • Current and archived internet
  • Periodicals, journals, & publications
  • Local institutions' paper database kept by Turnitin

6)     Originality Report options should include:a)     

  • Exclude Quoted
  • Exclude Bibliography

7)     Instructor report view should include:a)     

  • Sort by frequency of occurrence
  • Paper ID for administration and support

Recommendations for Next Steps (excerpted from email from Stephen Marquard)

The current TII integration does still submit everything as a single TII account.The issues that have arisen are basically that when someone else (e.g. at another U.) requests access to a paper submitted through Sakai, we get the request centrally.
Similarly, if someone at UCT requests access to a paper elsewhere, the request email has our central email address rather than the individual's email addr. This has been a low-volume issue for us so hasn't risen to the top of our priority list.

[REQ:Goodrum - what about matches within the same institution? Are those papers automatically available to other instructors at the same institution without requiring a request?]

The issue we've been thinking through (and discussed a little bit some time back with David Wu) is how to handle the association between site and assignments, given that in Sakai there could be multiple instructors in a course and there isn't a clear association between an assignment and an instructor.

We think what needs to happen is something like this:

- If you request access to another submission (through viewing an originality report from a link on Sakai), then the request should be sent as you (i.e. your own email addr) rather than the generic contact address. This may be tricky to implement because it could require Sakai to check that you have a Turnitin account when you login to Sakai. UCT and some other universities also want multiple people to be able to view originality reports (anyone with grading permission in the assignment), and not all of them may have TII accounts (e.g. some may be TAs rather than instructors).

- If someone else requests access to a submission through Sakai, Turnitin should mail a contact email address for the site, which Sakai is responsible for resolving to an email to the current instructor(s) for the site. Complications could include a request for a site in a previous year where one or more of the instructors have left. Maybe the Sakai site needs a config option to define who send incoming requests to. From the TII side, this would effectively be creating a pseudo-instructor per site, rather than a global one.

I suspect both of the above issues will be affected by different policies at institutions.

  • No labels

6 Comments

  1. This message was posted by Stephen Marquard on Aug 14, 2008 to several Sakai lists:

    From: Stephen Marquard [mailto:stephen.marquard@uct.ac.za]
    Sent: Thursday, August 14, 2008 8:57 PM
    To: 'pedagogy'; sakai-dev@collab.sakaiproject.org; sakai-user@collab.sakaiproject.org
    Subject: RE: Interest in a Turnitin-Sakai Integration? Hi all,

    Apologies for the cross-posting. I'm adding sakai-dev back to this thread because of the architecture issues.

    I'd like to clarify the current state of the Turnitin integration and some design approaches which we followed and I believe should be continued.

    Sakai currently has a content-review API in trunk which is generic, and a 2-5-x Turnitin implementation in contrib which is specific to the service provided by turnitin.com (and currently being used by UCT, NWU, PLU and Cambridge, that we know of).

    It is not specific to the current Assignments tool, but Assignments is the only place so far where it is available. It could as easy be used from Assignments2, T&Q, Mneme, or some other tool. There are 2 design principles here:

    - The integration should be a service usable from multiple tools
    - The API should be generic such that it is possible to implement it for similar services provided by companies other than Turnitin

    I believe that future work on enhancing Turnitin integration should carry forward these principles (if necessary evolving the shared content-review API) rather than creating something specific to a particular tool and vendor.

    Lastly, on the requirements side, the differences in use cases that have emerged are mostly about how to handle the potential mismatch between Sakai accounts and Turnitin accounts and Assignment ownership for instructors (Sakai assignments belong to a site, Turnitin assignments are associated with a single instructor), and related issues about who can see review reports, and the workflow of requesting access to other assignment submissions that show up in matches (both 'outbound' and 'inbound' requests).

    Regards
    Stephen


  2. This message was posted by David Horwitz on Aug 15, 2008 to several Sakai lists

    From: David Horwitz david.horwitz@uct.ac.za
    Sent: Friday, August 15, 2008 3:23 AM
    To: Josh Baron
    Cc: David Wu; Ciellie van Vuuren Jansen; Anthony Whyte; Pretorius Boeta; Noah Botimer; Leasia John; Michael Korcuska; pedagogy; sakai-user@collab.sakaiproject.org; Stephen Marquard
    Subject: Re: Interest in a Turnitin-Sakai Integration?

    Hi All,

    Just for info the current integration is being run piloted by (that I know of):

    1) Cape Town
    2) North West
    3) Cambridge
    4) Columbia
    5) Pacific Lutheran University
    6) Sabanc Univ (not sure of the status there now that Onur has left)

    The code in question is an API in core (Content Review Service) and a Turnitin implementation in contrib. The only tool that consumes it at present is assignments - an instructor can elect to send an assignment by checking 2 boxes in the assignment setup. Currently there is no integration with Assignments 2 but this would be fairly trivial to add. There are definitely places for improvement in the workflow - like how to reconcile the UI implications that a student can submit multiple files to a single assignment. The question I would have for this group is - are there other workflows that could use Turnitin as part of their work flow?

    Regards

    David

  3. Hi all,

    As promised, Unicon has finished the initial draft of the specification, and it is attached to this email/page for your review and feedback.

    Please send comments, feedback and questions to:

    David Wu, iParadigms, davidw@iparadigms.com
    Kate Valenti, Unicon, kvalenti@unicon.net

    As mentioned in my previous email, please try and get the feedback back to us by 11/18.

    This is a great step in moving forward to building out a tight integration, and I look forward to hearing from you.

    Thanks,
    Dave

  4. Rutgers is currently using the integration from contrib. It works fine. A number of faculty are using it. I'm not entirely sure how your requirements compare with what's there now. I'd like not to lose functionality or integration compared to what we now have. (In particular, I don't want to duplicate the "integration" our eCollege users have, where all they get is single signon, but they use the normal turnitin web interface.)

    The one problem I've run into with the current integration is that only the first paper attached to a submission is reviewed. A knowledgeable student could add two attachments, with the first being innocuous. The second wouldn't be reviewed, but the instructor might not realize that. I believe all should be reviewed, even if Sakai has to generate fictitious assignments (since apparently Turnitin only has one paper per assignment.) You should also make sure that if a student resubmits, the new set of papers are reviewed.

    We also had a situation where a faculty member wanted to submit several papers that for one reason or another he had gotten directly, and not through the assignments tool. I think this is a useful function. Again, there was no way to do it because of the one paper per assignment thing. I advised him to duplicate the assignment once per student, a solution he wasn't happy with.

    On accounts: note that there can be more than one instructor and instructors can change during the course. Please make sure that nothing is lost if one instructor is removed and another added. I would think it might make more sense to use an account associated with the site, not the instructor.

  5. Some comments based on the very early stages of the Cambridge pilot (using the Cape Town integration)

    • we understand that there are options for a student's work to be compared against the TII database but isn't added to the database (e.g. if a student has given consent to have their work compared but not to be added). We'd like to be able to set this preference for students on an individual basis.
    • we agree with Rutgers that students should be able to attach multiple papers to a submission and have them reviewed
    • we really don't want our students or teaching staff to get emails from TII when papers are submitted. They shouldn't have to know it's there.
    • as with Rutgers, a single course is probably taught / administered by multiple people, and this can change during the course. We need to make sure that accounts are associated with course sites, not with individual lecturers. A current use case at Cambridge would be for the course administrator to create the assignment, the students to submit their work online, and then for a student's supervisor to pick up the TII report for the student and to go through it in a 'supervision' (i.e. a one to one teaching session) with the student.
    • we've had a lot of talk at Cambridge about using it in teaching, to talk about what is and what is not considered plagiarism. One problem at the moment is that it is so tied down to official assignments via the Assignments tool. We'd be interested in thinking about a more discursive way of using it.
  6. Posting some feedback from an email thread for completeness (emailed to David Wu and Christian Storm from iParadigms, Kate Valenti from Unicon):

    Here's our feedback on the latest 2.0 spec posted on Confluence (http://confluence.sakaiproject.org/confluence/display/SAKDEV/TurnItIn+Integration) in relation to the points below. (Note that we do not currently use Grademark, and so have not reviewed this aspect of the spec.)

    Going backwards from point 4:

    Extending or replacing the existing integration: in principle we would like to work with Turnitin and Unicon so that there is one new integration that meets everyone's needs, rather than preserving 2 parallel integrations. However, this means that effectively the new integration has to provide a superset of the functionality of the existing one.

    Vendor independence: While we designed the first integration to allow implementations from alternate vendors, in practice to date there have been no other vendors or Sakai sites interesting in implementing this, so while in general the Sakai community would support vendor independence for this type of service, I think pragmatically we should disregard this as a consideration for now.

    On the new 2.0 spec:

    We like the proposed administrative tool, the expanded options in Assignments, improved feedback on review status, and the ability to review multiple files per assignment submission. wrt p. 76 / 3.6.3.1, a common use case for instructors is to sort the submissions by Turnitin report score (so that they can review the ones with the highest scores for example). In this case it would be helpful for the multiple-files option to show a report score representing the maximum of the submitted files (as well as the multiple files item).

    As far as I can tell, the 2.0 spec doesn't address the issues in 2 & 3 below, viz.:

    Mapping from Sakai instructors to TII instructors (Assignment owner issue): our use case here is that instructors use Turnitin through Sakai or directly but not both methods for the same course. Additionally, the user who created an assignment is not necessarily the instructor for the course or the assignment owner (for example the assignment could have been created by a teaching assistant). So while we understand that there are some sites (e.g. Indiana) who want a simple 1:1 mapping, to serve other use cases we believe the integration should be configurable to support a case where there is a pseudo-instructor account per course with a specific email address (e.g. turnitin-instructor-XXXX@sakai.site.edu) which a Sakai service is responsible for resolving to the appropriate person or people (e.g. the assignment owner and/or the site owner, or a designated instructor for the site).

    Queuing strategy: We strongly believe that a queuing strategy is the best option. While synchronous integration may work well in high-bandwidth contexts, in South Africa and other contexts, bandwidth is not plentiful and response times from remote sites can be slow. Users shouldn't have to wait while they submit an assignment or review the list of submissions to get back a response from the Turnitin site (likewise when Turnitin is down for routine maintenance, this shouldn't prevent users from submitting assignments or viewing the submission list).

    Here's a sample end-user comment that we recently got from someone who was using the Turnitin site directly:

    "Thanks for the help. I have the system working. It seems a bit slow and I
    have lost the internet connection a few times, but I have some (disturbing!)
    results from a submission."

    The queuing strategy is one we designed for our Sakai integration having learnt lessons from a prior synchronous integration with a home-grown system. The queuing approach has now been proven in production for close to 2 years, so it's not something that would have to be invented from scratch.