Talk 1: CrossProject 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
Working Together

• Mellon Portfolio
• Sakai lt-gt OKI
• Sakai lt-gt uPortal
• Sakai lt-gt OSPI
• Sakai lt-gt Kuali
• Sakai lt-gt Fedora
• Sakai lt-gt PKI
• Sakai lt-gt Chandler
• Sakai lt-gt LionShare

• Other Collaborations
• Sakai lt-gt WebCt/Blackboard
• Sakai lt-gt JISC
• Sakai lt-gt LAMS, LonCAPA

Maturity of elements is pre-requisite to
introducing a dependency.
3
Sakai lt-gt 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 Sakais Solution for Enterprise
  Information Integration - Sakai DG on Integration
• As Sakai APIs become defined, we generate change
  requests to OKI

4
Sakai lt-gt 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 lt-gt 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 lt-gt 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 lt-gt 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 Fedoras 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 lt-gt 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 lt-gt 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 lt-gt 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 lt-gt WebCt/Blackboard

• How to engage competitors
• Brads approach .vs. Chucks approach
• IMS Tool Interoperability Profile
• Web Services iFrames
• Based heavily on WebCTs 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 lt-gt JISC

• The Other Elephant in the LMS space is the JISC
  E-Learning Framework
• They have more money, more people, more central
  control
• JISCs 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 lt-gt 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 others 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