1. Robby Robson Chair, IEEE Learning Technology Standards Committee Chair, NSDL Technology Committee June 2005 Understanding and Using Standards This work is licensed under the Creative Commons Attribution-NoDerivs License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/2.0 or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.http://creativecommons.org/licenses/by-nd/2.0

2. There are LOTS of standards relevant to Digital Libraries l l Metadata l l Search / Discovery l l Resource Aggregates l l Identifiers & resolution systems l l Rights l l Enterprise Infrastructure Interoperability l l Content formats (e.g. Scientific Markup Languages) l l And more … So as we look to the future, what can we learn from the past?

3. Learning Technology Standards What’s been done and where we are headed

4. E-Learning Hype Cycle Courtesy RCA Wilson

5. Progression of Learning Technology Standards 199619971998199920002001200220032004 Content interoperability within the learning community General solutions for specialized communities (AICC, IMS, ARIADNE) ISO/IEC JTC1 SC36 Learning is part of bigger picture IEEE LTSC Starts – which “E” stands for Education? First Approved Standard Lots of work being done

6. IEEE LTSC Standards l l Learning Object Metadata l l Data Model & XML Binding l l Content to Runtime Environment Communication l l ECMAScript API, Data Model, XML Binding (in final stage of approval) l l Architecture Reference Model

7. Current Projects / Directions l l Recommended Practice for Rights Expression Languages l l Learning/Education/Training requirements for a standardized REL l l Reusable Competency Definitions l l Adoption of an existing specification l l Reference Model for Resource Aggregates l l Interoperability among existing standards and specifications: MPEG, METS, IMS Content Packaging, DITA, S1000D, Open Document … l l Future of Metadata l l RDF Binding  Dublin Core Abstract Model l l LTSC / DCMI Collaboration l l Contemplating: Query Languages

8. Observations And Lessons Learned

9. Standards are not always needed l Standards emerge when markets go from being under-served to over-served*. l Proprietary solutions are faster to develop and easier to control l Standards make sense when “good enough for everyone” is better than “best for me.” Clayton M Christensen & Michael E Raynor, (2003). The Innovator’s Solution: Creating and Sustaining Successful Growth *From: Clayton M Christensen & Michael E Raynor, (2003). The Innovator’s Solution: Creating and Sustaining Successful Growth, Harvard Business School Press

10. You can’t make a standard! Pre-standards Activities - Principles - Requirements - Early Specs - Prototypes Standardization - Compromises - Champions - Prototypes Early Adoption - Publication - First Products - PR Rude Awakening - User feedback - Revisions Real Adoption - Stabilization - Test Suites - Products - Conformance - Compliance Only the market can make a standard

11. Adoption Comes at Different Times l INFRASTRUCTURE PRODUCERS l Adopt when convinced its coming l APPLICATION DEVELOPERS l Adopt when convinced its real l CONSUMERS l Adopt when convinced its working

12. Case Study – MathML l l Standard wasn’t needed Had good standard (    ) l l Vendors working on related standard (OpenMath) l l Standard was done right l l Imprimatur of W3C l l Consumer interest l l Clear vision (separation of content / presentation / semantics) l l Adoption was minimal l l Browsers did not adopt l l Community did not promote l l 8 years later l l Upswing in adoption l l Significant emerging applications

13. Standards Work Behind the Scenes l l Standards encode information for computers l l They are not UI designs l l They are not necessarily human readable l l They are not product designs l l Don’t confuse: l l Element names (tokens) with display names l l The ability to encode data with the requirement to collect it l l Formats for exchange with formats for storage l l Misunderstandings in this area has interfered greatly with community adoption of standards

14. Standards Don’t Guarantee Interoperability l l Implementers still need to implement l l Communities still need to agree l l There are almost always semantics

15. Case Study l l Metadata worst practices l l Lots of long forms l l Forcing internal metadata into standardized fields l l Making lots of extensions – and exposing them to other communities l l Assuming any two people use the same term in the same way

16. “Formal” Standards are Important l Volunteer Consensus Standards Bodies: l Use agreed-upon procedures. l Are defined by the following attributes: l Openness l Balance of interest l Due process l An appeals process l Consensus References: SDO Advancement Act of 2004SDO Advancement Act of 2004 & OMB Circular A-119OMB Circular A-119

17. Process Counts – And is all you get WORKING GROUP & SPONSOR PROCESS SOLUTION IS FORGED FORMALITY VARIES LOTS OF MEETINGS IEEE STANDARDS ASSOCIATION PROCESS FORMAL PROCESS BALLOT NEEDS 75% PARTICIPATION and 75% APPROVAL TO SUCCEED Sponsor: Organization that assumes responsibility for a particular standards idea within the IEEE. CREATION APPROVAL

18. Different Entry Points l l Start at the development stage l l Takes 2 – 4 years l l Start at the consensus building stage (Start with an existing document) l l Takes 1 – 3 years l l Start at the approval stage (Adopt an existing specification - “Fast Track”) l l Takes about a year / can take less

19. http://www.niso.org/international/SC4/wg4-0996.html

20. Summary Lessons Learned l l We are us l l The process is flexible l l Information models come first l l A dedicated technical editor is vital l l Adaptation is the sincerest form of flattery l l Standards bodies are not research labs l l “Working code trumps all theories” (Philip Dodds) l l Broad perspective makes better code l l Standardization activities build developer communities

21. DISCUSSION robby@computer.org