Zobrazení zdroje stránky Advanced LD Editor

Projekt s cílem zpopularizovat, zefektivnit a zejména rozšířit výhody plynoucí z modelování výuky. Ústředním bodem bude vizuální editor (a-la UML), umožňující jednoduše modelovat výukový proces. Na konci celého procesu bude balíček odpovídající specifikaci IMS Content Packaging (SCORM?) s výukovým obsahem a modelem výuky odpovídajícím specifikaci IMS Learning Design.

= Koncept řešení =

=== Funkční požadavky ===
* Vizuální editace IMS LD (jako samostatného souboru i v rámci balíčku podle IMS CP)
* Možnost zadat namísto konkrétních výukových objektů pouze požadavky (metadata později využitelná pro dohledání vhodného materiálu)
* Možnost dohledat vhodné výukové materiály podle zadaných metadat v různých úložištích (od lokálního souborového systému až po specializované služby)
* Export modelu výuky (ve formátu IMS LD) včetně výukových objektů do balíčku odpovídajícího IMS CP (SCORM?)

=== Zachycení výukových objektů v IMS LD ===
Každý výukový objekt je součástí nějakého prostředí (<code>environment</code>) a je deklarován v rámci příslušného elementu. Jednotlivá prostředí (<code>environment</code>) jsou pak odkazována z těch aktivit (<code>learning-activity</code>/<code>support-activity</code>) nebo struktur aktivit (<code>activity-structure</code>), ve kterých mají být využívána (viz obrázek).

[[Soubor:IMS_CP+LD_manifest.png|Ukázka manifestu balíčku podle specifikace IMS Content Packaging doplněného o model výuky podle specifikace IMS Learning Design. Zvýrazněny jsou části týkající se výukových objektů.]]

Uplatnění našich falešných (mock/stub/...) výukových objektů se proto v modelu výuky neprojeví nikde mimo konkrétní element <code>learning-object</code>. Ten bude stále existovat, bude deklarován jako součást nějakého prostředí a potažmo odkazován z příslušných aktivit nebo struktur aktivit - pro "okolí" k žádným změnám nedojde.

Jediné povinné součásti elementu <code>learning-object</code> jsou atribut identifier a alespoň jeden potomek <code>item</code> (ten ale může být i zcela prázdný - zejména nemusí mít atribut identifierref odkazující příslušný zdroj). Do elementu <code>learning-object</code> je možné vložit metadata, což je pro náš záměr ideální.

= Implementace =

=== Software, ze kterého by bylo možné vyjít ===
* Open-source (Java-based) IMS-LD editory
** [http://www.reload.ac.uk/ldeditor.html Reload LD Editor] - formulářový (nevizuální) editor kopírující XML strukturu IMS LD, SWT
** [http://www.copperauthor.org CopperAuthor] - nevizuální editor, editace v podstatě na úrovni XML, SWT
** [http://www.lamsfoundation.org LAMS] - vizuální editor s patrně nejnižší vstupní bariérou, nepodporuje ale IMS LD
* Open-source (Java-based) UML editory
** [http://argouml.tigris.org ArgoUML] - plnohodnotný UML 1.4 editor
** [http://www.umlet.com UMLet] - jen kreslítko
** [http://www.horstmann.com/violet Violet] - jen kreslítko
** [http://wwwcs.uni-paderborn.de/cs/fujaba/index.html Fujaba] - Jen class a activity diagramy, konverze UML &harr; Java

=== Řešení přístupu do úložišť ===
Ke všem úložištím je nutné interně přistupovat jednotně, tzn. je třeba zvolit a vyspecifikovat obecně použitelný model, který by mohl být k tomuto účelu využíván (pravděpodobně na bázi JCR). Pro každé konkrétní úložiště bude pak potřeba vytvořit tzv. "JCR Driver", který k němu bude fyzicky přistupovat a zpřístupňovat požadovanou funkcionalitu požadovaným způsobem.

Pro zamýšlený účel je třeba pouze přistup pro čtení (tzn. JCR Compliance Level 1). Velmi důležitá je ale podpora vyhledávání na straně serveru. Tam, kde neexistuje, zbývají pouze dvě možnosti - buď přidat tuto funkcionalitu na stranu serveru a nebo (část) úložiště zrcadlit, indexovat a prohledávat lokálně (např. pomocí Apache Lucene).

==== Konkrétní typy úložišť ====
* Lokální souborový systém
* SVN Repository (de-facto odpovídá souborovému systému bez vyhledávání, přístupnému buď proprietárním protokolem nebo pomocí WebDAV)
* Website
** S vyhledáváním (např. Wikipedie)
** Bez vyhledávání (obecný web, pro prohledávání je - pokud se obsah příliš často nemění - možné použít Google)
* Specializovaná úložiště
** Informační systém MU (bohužel de-facto odpovídá website bez vyhledávání)
** [[LO Repositories| Knihovny výukových objektů]]
** VEZMU (Vyhledávač nad elektronickými zdroji MU)
** Weby/úložiště generované pomocí GVP (Generátoru vědeckých portálů vyvíjeného v NLP)

Jediné, kde se dá spolehnout na existenci a kvalitu metadat, jsou specializovaná úložiště. Ve všech ostatních případech nezbývá, než si vystačit s fulltextovým prohledáváním, nebo aplikovat nějaké techniky pro strojovou extrakci metadat (což ale není předmětem tohoto projektu - jedinou akceptovatelnou možností by zde bylo použít nějaké hotové řešení).

==== Komunikační protokoly (pro vzdálený přístup do úložiště): ====
* Proprietární protokoly
* SOAP/Web service
* REST
* WebDAV
* HTTP
* Java Content Repository (JCR, JSR 170)
* IMS Digital Repositories (SOAP, při přístupu ke specializovaným úložištím LO používá XQuery nad IMS Metadata, při přístupu do ostatních úložišť používá Z39.50)
* OKI Repository OSID (zajímavé, ale spíše jako doplněk - jako základ až příliš abstraktní)

Pouze JCR a OKI OSID mají přímo vestavěnou podporu pro vyhledávání (JCR v rámci Compliance Level 1). Ve všech ostatních případech je podpora prohledávání plně v kompetenci úložiště a při přístupu daným protokolem může, ale i nemusí být dostupná.

Zajímavost (a možná inspirace): Dvojice knihovnických protokolů SRU/SRW. Mají se stát modernější alternativou k Z39.50, jsou udržovány The Library of Congress. Při dotazech je možné pro upřesnění sémantiky využívat různá metadatová schémata (např. Dublin Core). SRU používá HTTP (dotaz je zakódován do URL) a SRW používá Web Service/SOAP. Sémanticky jsou ekvivalentní.

= ToDo =
* Navrhnout vizuální notaci pro IMS LD (úroveň A)
* Zvolit nebo navrhnout metadatový formát pro zachycení požadavků spojených s "falešným" výukovým objektem
* Zvolit obecnou reprezentaci úložiště (technologii, strukturu a funkcionalitu)
* Možnost zapojení doménové ontologie do procesu tvorby i vyhledávání