1. Five years for five perspectives on TELOS Ioan Rosca, PhD. in educational technology telecommunication, computer, information and instructional systems engineer researcher and conceptual architect at LICEF, Teleuniversity, Montréal ioan.rosca@licef.teluq.uquam.ca LOR06, Montreal, 10 November, 2006

2. Summary Introduction : history of a conceptual quest Main objectives: produce, deliver, intermediate Vision 1: extending the resources space; emergent mode Vision 2: reproducing processes; orchestrating mode Vision 3: distributing services; technical match Vision 4: managing knowledge evolution; semantic match Vision 5: managing production cascades; administrative match Current work: managing service negotiation

3. History of a conceptual quest: a retrospective perspective MOT, Explora, Adisa, ION Val, Gadisa, SavoirNet Conceptual quest GEFO TELOS0 TELOS dev 20062005 Technical architecture Conceptual refinement consolidation 2008 2003 1999 Previous work conceptual architecture

4. 104 Data SchEdDataEd Adisa f schema LinkEd xxx schema 2.5f a(104)h a(212)h a(214)h 104d1 212d1 a(104 212, 214)i P1 e104g e212g exxxg data library edstyle GADISA 104d2 2.5g f(104e, 212, 214) data function editor functional aggregation 2.2 a VAL function explorer metaf 2.2 b b Adisa1 online/offline ADISA d104 e104 e212 d104 exxx MOT EXPLORA MISA (DE104, 212,214,xxx) 35 editors e104a exxxa 2.1a dxxx semnatic “bus” 2.4 K ref service client data adaptor adviser Explora adviser epiphyte service bus Adisa service server kernel 2.3a 2.3b e104d e212d e214d d104 d212 d214 Adisa d 1d e104b e212b Adisa 1+ exxxb 2.1b d104 e104c exxxc user context Rins Rpro Racc central context SR Env PR wsc Fa Ba designer context ION resources aggregator Adisa c ResEditResManResConDocMan D 2.1c

5. LKMA (lesson) LKMPC(K) D(K) P(K) T F(K) LKMS (platform) D manager T manager P manager F manager K manager LKMA managerLKMP manager 1 Produce Core factory Core libraries Resources and services provider 2 Deliver LKMA (lesson) LKMS (platform) C(K)LKMP Resources and services obtainer 3 Mediate Resource repositories Service providers C(K) LKMS (platform) LKMA (lesson) LKMP Main objectives: produce, deliver, mediate

6. us TELOS agcofiuspu 1 using and extending resources repositories e TELOS e e e e E TEL e 2 modeling, managing, and reproducing processes P S M m m u TELOS tata’ sidis w di dis ua a,r sa us ob sa d,d 3 distributing objects and services 4 e1e3e2 e4 TELOSTELOS n pr ir do fu d ip ed u r,p ac fi us R 4 managing global knowledge evolution a2 S a1 a4a3 delete p1p4 c3c2c1 p3 p5p8p7 p2 p6 TELOS -core LKMS libraryLKMALKMP s1 s2 5 administrating production cascades

7. ob2ob1ob3 o1o1o2 p2 a primary procedure p1 rs ps persons objects operations support resource support person b abstract procedure model o1o1 i1i2 is1 o2 i3 as2 a1a2 compose model author Function editor function operations directories abstract actors abstract instruments adapter concretise elements Function adaptor resources repositories person directories knowledge reference system o1 is1 o2 as2 a1a2 ob x rs x ps x c model with concretised elements user finds and executes Function executor e1 is1 e2 as2 a1a2 d secondary procedure based on function execution ob x rs x ps x ob yob z executed operation pxpxpypy analyst Function analyser record react e meta-procedure of functional cycle Adapting orchestrations

9. From learning to explanation learning topologies participateconsultdialog Ci Cf Ci,Cf consult i f kakbkckdke M 0% 100% learning: activities as competence operators i-fmastership measured competences c1i c1f explain Ci? Cf? c2i c2f explain c3i c3f explain effects of explanation on various learners k k1 k2 k3 k1.1 k1.2 knowledge refining competences i k1.3 k1.3.1 k1.3.2 k3.1 k3.2 f Explicative capacities and pedagogical indexation. In order to observe the competence equilibrium around pedagogical operations, I have organised the competences space of a person P on "postures": (knowK, aimK, explainK(x,y), describeK(x,y), recommendK(x,y), evaluateK(x,y))- where the parenthesis show a predicate depending on the detained (x) or aimed (y) "mastering level" of the person to which P could explain directly (transmit by a document, evaluate, recommend etc) the knowledge k. The indexation of explicative documents poses similar problems to that of referencing support persons. They can be partially considered the author's representative towards the expected user (minus the interactivity limitations). That is why I have also characterised their explicative potential by (c1,c2) increases.

10. O O E a state changes for Toeda topology O D E A da e o D E A da e O D E A e O D E A a e O D E A d e O D E A da O D E A O D E A a O D E A d O E e dn c1 c2 ? f2 R b global allocation problem f1 8 Competence optimization

11. Service negotiation with TERMS actor work syst ask service grou categ partlkmp lkma lkms assist deliv supp doc filter solve transac solve compl memor solve concur manage O D E A O D E A da O D E A da e o D E A da e O D E A e TERMS define x services s1 y propose offers o1s1 z negoti accept contracts c1o1s1 c2d1s1 v u answerrequ demands d1s1 negot

12. TERMS - Telelearning Extended Rights Management System Technological background TERMS is built on a multi-tier J2EE architecture inspired by the MVC model that is designed to scale well on a cluster of front-end and back-end servers. The data layer uses the DAO pattern, providing a bridge between the data servers (HypersonicSQL, MySQL or other SQL-compliant data server) and the business layer (implemented in EJBs). The front-end is handled by servlets and JSPs, designed with action patterns in mind, extended with custom tag libraries, filters, listeners and additional web development frameworks (WebWork, Sitemesh). The Web Services access gate is implemented with the xFire framework, providing full WSDL and SOAP support. Designed to be portable across different servlet runners and EJB containers, TERMS currently uses Resin Caucho as its application server, using the Hessan binary protocol for fast access between front-end and back-end. Security is handled both explicitly and through the servlet runner's security roles and constraints, the application fully supporting Secure HTTP, through JNI and OpenSSL. The current payment mechanism uses Verisign's Java API, but can easily be swapped with alternatives. Other involved technologies include the ANT build platform, the JUnit testing package, the java activation framework, JAAS, SAAJ, MAIL, XML Parsers (Crimson, JAXP, JDOM...), log4j, Spring etc.