Online Presence in Personal Learning Environments

OP4L: Online Presence Enabled Personal Learning Environments establish global online presence of a student along the different tools used as PLE. This can further increase students’ awareness of each other and positively affect their willingness to collaborate.

The problem tackled is to unify different semantic representation of Online Presence.

A scenario depicts recommandation of a peer, available online (on any tool), willing to help, and having the background to help on a specific topic.

The OP4L Solution is base on a component DEPTHS (Design Patterns Teaching Help System) that relies on a common ontological foundation ti intergrate several existeing eductional tools ans systems : LMS, Domain Modeling tool, online repositories of learning ressources.

The ontological stack is the following :

  • LOCO(Learning Object Context Ontologies)
    • Learning Context Ontology
    • User Model ontology, inlcuding:
      • competencies
      • learner’s performance
      • user’s preferences
    • Learning Object Content structure ontology
    • Quiz ontology
    • Domain Ontology (Vocabularies are modeled using SKOS)
    • a Learning Design ontology as a formal representation of the basic building blocks of an instructional design
  • OPO is used for representing online presence

A server called OPOS gather presence from various services, and translaite it in a data repository (as RDF triples). Those data are filtered by a recommander Peers Module in order to put people in contact.

Tools supported are currently mixed between specific learning tools (Moodle and ArgoUML) and external social services: Facebook, Twitter, Foursquaie and instant messaging client Spark.

The OP4L project propose plenty of resources

Publié dans lecture | Tagué , , | Poster un commentaire

Article Learning Engineering knowledge and Creativity by solving projects

Learning Engineering knowledge and Creativity by solving projects par Chunfang Zhou – Aalborg University

Analyse intéressante – brosse une panorama large des vues de "types de connaissances/compétences" demandées au ingénieurs. Elle souligne l’importance croissante du collectif dans la résolution des problèmes.

Elle montre également que la créativité est façonnée par le contexte social qui doit encourager l’appropriation des connaissances par conversation au sens d’un processus cognitif et développer la conversion de connaissance, au sens explicitation "externalisation" puis incorporation dans le tissu social ou "internalisation". Elle s’appuie sur le modèle de Nonaka et Takeuchi qui définit une boucle de conversion de la connaissanc. Cela ressemble un peu à du Kolb, mais avec une vue collective.

Elle justifie finalement les apports des projets pour développer les connaissances nécessaires pour un ingénieur de manière classique. Elle insiste néanmoins sur l’importance de l’attitude de l’enseignant, du tuteur pour encourager conversation et processus de conversion

 

Publié dans lecture | Tagué , , | Poster un commentaire

revue article cloud, mapreduce et ULS

Cloud Computing and MapReduce for Reliability and Scalability of Ubiquitous Learning Systems par Samah Gad à Neat’2011

Définition de ubiquitous dans cet article :

Ubiquitous learning research is about seamlessly enabling learning through the use of sensors that gather data from the learner surroundings and adapt learning content accordingly.

Étonnant : le capteur proposé coté étudiant est l’électroencéphalogramme (EEG). Ces données excessivement personnelles sont envoyées dans le cloud. J’aurai bien aimé avoir la justification d’utiliser un capteur aussi intrusif pour l’accompagnement d’un apprenant. Apprendre n’importe où, n’importe quand, mais avec un EEG … bon c’est vrai l’usage des écouteurs oreillettes est déjà largement admis, mais quand même.

L’utilisation d’Ubiquitous Learning System dans le titre n’est qu’un prétexte pour étudier une architecture cloud/MapReduce d’un classifier flou.

Si on considère ce type de capteur comme pertinent, les traitements afférents ont vocation à être fait ailleurs que dans un téléphone. La question du débit de données n’est par contre pas abordé, ce qui paraît pourtant être un goulot d’étranglement dans le système (à la lecture de l’article, on reste effectivement dans le raisonnable 7Mo pour 12 000 échantillons).

L’algorithme d’adaptation proposé pour exploiter ces données est basique, puisque le résultat se ramène à 3 niveaux de ressources (facile, moyen, supérieur), via un classifier flou.

L’auteur aborde l’introduction de l’algorithme Map reduce par une question de fiabilité. On est dans la justification d’une architecture pour supporter des ULS large échelle.

Il pourrait être intéressant de comparer différentes architectures (cloud ou traitement local entre autres) et de voir l’impact sur plusieurs critères annoncés mais non justifiés : consommation téléphone (l’envoi de données est un facteur important de consommation), consommation globale, débit réseau, délai (latency) …

Au final, on parle ici d’architecture cloud/mobile pour le traitement de données capteurs, peu de learning system. On ne voit pas non plus l’intérêt de passer par le cloud puisqu’il n’y a pas d’agrégation de données.

Publié dans lecture | Tagué , , | Poster un commentaire