Talk 1: Cross-Project Collaboration Talk 2: Sakai and RDF

1. Talk 1: Cross-Project Collaboration Talk 2: Sakai and RDF Charles Severance Sakai Chief Architect Mellon Retreat March 29, 2005

2. Mellon Portfolio Sakai <-> OKI Sakai <-> uPortal Sakai <-> OSPI Sakai <-> Kuali Sakai <-> Fedora Sakai <-> PKI Sakai <-> Chandler Sakai <-> LionShare Other Collaborations Sakai <-> WebCt/Blackboard Sakai <-> JISC Sakai <-> LAMS, LonCAPA Working Together Maturity of elements is pre-requisite to introducing a dependency.

3. Sakai <-> OKI • Architect Exchange - E-Mail lists, Specs, F2F meetings - continuous engagement • Sakai and OKI do not have identical approaches to API design • Sakai is focused on tool APIs and OKI is focused on Integration • Sakai is more specific OKI is more general • Sakai APIs imitate OKI API design approaches • OKI is Sakai’s Solution for Enterprise Information Integration - Sakai DG on Integration • As Sakai APIs become defined, we generate change requests to OKI

4. Sakai <-> uPortal • Architect exchange - E-Mail, Specs, F2F dev meetings, user meetings “speech” exchange • Board member exchange • Open Source Week June 8-11 • Requirements communicated - but need to understand that there are two communities • For 2.x, Sakai is a “customer” of uPortal • For 3.0x, we are beginning to get to the point where some problems may be solved “once” and will end up in both source trees - requires more coordination

5. Sakai <-> OSPI • Lead by Indiana and rSmart • OSPI is very skilled in Sakai - they answer questions on our support list • Alignment at a high level around resources, storage technology, and WebDav • OSPI is *not* squeaky enough • OSPI has some technology in hand that I was not planning to have in hand until 3.0 (Slide/WCK) • Meeting planned this week to see if we can accelerate OSPI contributions into Sakai 2.0

6. Sakai <-> Kuali • Lead by Indiana • Kuali is on a sane pace • Architect Exchange - F2F Meetings • Potential alignment • Sakai Style Guide • Sakai JSF Approach • Sakai or uPortal as Deployment Vehicle • Understand that Kuali is independent - must respect its community

7. Sakai <-> Fedora • Limited exchange to date • Is Fedora a JSR-170 like Repository? • OSPI looked closely at Fedora as the internal solution • Sakai looked at Fedora as an internal storage solution • Fedora clearly needs to be integrated as a “destination” repository (see Twin Peaks for potential integration strategy) • As Sakai moves into web services, we will look closely at Fedora’s user of web services (performance, security, technical choices) • Pre-integrate Fedora into the Sakai distribution - “Every Sakai includes Fully provisioned Fedora” • Planning on attending Fedora Dev meeting (May 13-14)

8. Sakai <-> PKI • Sakai interested in PKI integration out-of-the-box as part of 2.0 or 3.0 • Form-based validation • CAS and other WebISO • LDAP • Kerberos • PKI • Insure flexibility of Sakai user and authentication model • Because there is little demand from Sakai adopters - this is of interest to architecture folks - low priority for medium term

9. Sakai <-> Chandler • Hard to share code :) • Sakai uses Java, Chandler uses Python • Sakai makes APIs, Chandler uses WebDav • Informal coordination has been around internal storage and webdav approaches • Met with Lisa Dusseault at Educause • Led to current Sakai and OSPI strategy w.r.t. WebDav, JSR-170, and general internal storage.

10. Sakai <-> LionShare • Not much real activity :( • Not for lack of goading from Ira, Sakai board and leadership • Problem (in my head): What problem does LionShare solve that Sakai is working on in the next few months? How can we help them? How can they help us? • Possible solution to explore: PeerServer is like WebDav - installing Sakai gets “free” fully provisioned PeerServer elements, sharing AUTHN, AUTHZ, backing info, etc.

11. Sakai <-> WebCt/Blackboard • How to engage “competitors” • Brad’s approach .vs. Chuck’s approach • IMS Tool Interoperability Profile • Web Services + iFrames • Based heavily on WebCT’s PowerLinks moved into IMS as standard • Samigo will run in multiple LMS hosting environments • Sakai, WebCT, SUN and Blackboard on board • Cisco and Microsoft are in the wings on the way in • Demo June 20-22 Alt-i-lab Sheffield, UK

12. Sakai <-> JISC • The “Other” Elephant in the LMS space is the JISC E-Learning Framework • They have more money, more people, more central control • JISC’s vision is more elegant • Sakai - we write code and release :) • Instead of competing, we are very careful to be complementary • Architect Exchange - Board Exchange - Rosetta Organizations - User Meeting - Keynote Exchange

13. Sakai <-> LAMS, LonCAPA • Smaller but very vibrant “competitors” • Complex interactions • Sakai says: “Why not make LonCAPA a tool in Sakai to get access to the folks who will be making Sakai their enterprise LMS?” • LC Says: “Because Sakai should be part of LonCAPA - we are so much cooler…” • Sakai says: “Tell me more…” • LC Says: “We are more flexible in the following ways….” • Sakai says: “Hmmm - that is a good idea…” • Ultimately interacting with these communities makes Sakai better.

14. Doing it Better • Understand and Symmetry across all projects • What can Sakai to for Fedora? What code does the Sakai team want to write and commit to Fedora CVS? • What can Fedora do for Sakai? What code does the Fedora team want to write and commit to Sakai CVS? • Software maturity is pre-requisite - hard to adopt in the middle of a re-factor • Touch point sites which deploy more than one piece of software (Rutgers Sakai/uPortal)

15. Doing it Better (part Deux) • Mellon scoped retreats for software types • Coordination on standard activities • WSRP, JSR-170, WebDav, JSR-168 • Internally factor our efforts effort for multiple uses • uPortal - Sakai Spring Components • Fedora - Web Services Security • Accepting time cost of coordination • Check into each other’s hierarchies cross-committers - requires skill and trust building

16. Conclusion (Part 1) • Sakai invests a lot in coordination • Some selfishly motivated • Some motivated by “curiosity” • Some preparing for long-term alignment • Hard for each project to do it all in an “n-squared” style. • Sakai pain point: Web Services - please help me..

17. Talk 2: Assume Sakai What Next ? Charles Severance Joseph Hardin

18. June 2006 • Sakai running at 100 institutions, with 2 million daily users who are each using Sakai 20 times per day…. • Making 10 million new “learning resources” per day • What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new “objects”? • This is *not* Google - because these learning objects are all fine grained access controlled..

19. June 2006 • Sakai running at 100 institutions, with 2 million daily users who are each using Sakai 20 times per day…. • Making 10 million new “learning resources” per day • What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new “objects”? • This is *not* Google - because these resources are all fine grained access controlled.. RDF - Resource Description Format is designed to describe Resources (Metadata) and describe relationships between Resources distributed across the Internet. (a.k.a. Semantic Web)

20. RDF Chicken or Egg? Sources of RDF Information Consumers of RDF Information * Longwell Sakai/RDF PiggyBank Simile RDF Protocols and Formats Dspace Simile Fedora Haystack Blogs Annotea RDFizers Infrastructure JENA, etc.. Infrastructure JENA, etc.. Data and Metadata * A common approach in RDF is that consumers often consume, add value, and re-produce.

21. RDF Chicken or Egg? Sources of RDF Information Consumers of RDF Information * getData() Longwell Sakai/RDF PiggyBank Simile RDF Protocols and Formats Dspace Simile Fedora Haystack Blogs Annotea RDFizers Infrastructure JENA, etc.. Infrastructure JENA, etc.. Data and Metadata * A common approach in RDF is that consumers often consume, add value, and re-produce.

22. RDF Infrastructure and Protocols • Protocols and formats are pretty well established • JENA is adequate for medium-scale work • Large-scale performance is active research effort

23. RDF Consumers • Coming along - enough exist to be “interesting” • Piggy Bank - Bookmarks on Steroids • Annotea • Longhorn - RDF Stores • Suffer from a lack of producers

24. RDF Producers • Adding RDF to repositories will make existing “Curated Resources” available via RDF • DSPACE • Fedora • EduCommons • OCW • Adding RDF to Sakai would create a massive source of “Organic” Resources • Interesting information - personal information, calendar entries, chat messages, e-Mail • Educational objects • Fine-grain access control

25. Sakai/RDF Futures – 3 Steps • 1. Current Metadata - enhance schema metadata with simple Schema style editor for Sakai Resources. LOM, DC, NEES,… Convert properties inside to RDF; add RDF access-controlled renderer to provide RDF access from the outside (RDF getData(); ) • 2. Separate RDF Service - RDF for annotation, work with RDF aware tools This would involve a new API, a tuple manager. Integrate Jena into Release and fully provision – works “out of the box” Tools (existing or new) that want to store RDF, can. Tools can be inside of Sakai as Sakai tools or work with RDF over web services. But old tools are still there working on old metadata (typically relational) representations. • 3. Integrated RDF content and metadata - shift core tools and services (chat, discussion, schedule, announcements, resources, mail archive…) from relational to RDF tuples - must retain performance - migrate old metadata as views into the new structure – solve RDF performance issues

26. Conclusion (2) • We have a problem of the explosive growth of resources (a.k.a. learning objects) in the form of Sakai courses and content • If we properly RDF-enable Sakai at the lowest levels, we could enable a whole new category of RDF applications