SCAMMöte20070531

Inblandade

• Umeå
  • Fredrik P
  • Mikael K
  • Ola Å
  • Aron A
  • IML-lärare
• KMR
  • Ambjörn N
  • Matthias P
  • Mikael N
  • Hannes E
  • Fredrik E

Projekt

• MSU
• Organic.Edunet
• ProLEARN
• CAMRADE
• MELT

Fördelar med SCAM + portöljerna

• Sökbarhet (Professionell)
• ACL (grupper mm.)
• Icke-filer/skräddarsydd metadata
• Resursrelationer
• Distribuerade portföljer
• Integration med bibliotek/pricerunner/amazon etc.
• Annotationer

Saker att jämföra med

• Fillagring
  • WebDAV
  • HTTP
  • FTP
  • SAMBA
• Digital Repositories
  • OSID (DR)
  • Z39.50
  • SRU/SRW
• LCMS
  • SCORM
  • IMS DR
  • FIRE
  • SQI
• Triple Stores
  • Joseki
  • SPARQL
• Syndikering & Web2.0
  • RSS
  • iCal
  • Podcast

Named Graphs och uppdatering av Jena

Named Graph design

Vi listade 3 alternativ för represenation:

Där vi enades om alternativ 2. Pga sökning / access utifrån är inte intresaant på portölfj nivån (med SPARQL). Sökning mot portföljer är viktigt i portföljgränsnitt endast och där kan man använda lucene sökningar.

RDF utryck design

Anonymous closure ska in i en Named Graph och record strukturen blir NG-resursen där:

• ACL (för metadata, men om inget annat anges och resursen är en uppladdad fil så gäller ACL:en även för resursen).
• modified / created (obs, för metadata... samma argument som ovan även här).
• inModel
• ontologyUsed ? (koppla till specifik portfölj där ontologierna hanteras)

Alla dessa uppdateras i huvudsak av systemet, om editering ska tillåtas måste den begränsas så att man inte tar bort inModel eller nåt.

Relation mellan resursen och NG-resursen kan vara bra att ha för att veta vilken som är huvudresursen i NG. Dvs vad som ska presenteras / editeras (autodetektion är kanske alltid möjlig). I vilken riktning denna relation går är en öppen fråga (bakåtkompatibiltet?).

API er.

RDF2Go verkar vara intressant.
Adaptrarna för Sesame och Jena är ok, NG4J är outdated. Plan är att sätta upp Sesame (ty stöd för Named Graphs) och testa med adatern för RDF3Go. Därefter testa den RDF design vi kommit överens om. Därefter kan man testa algorimter för access till enskild portfölj via inModel propertyn, samt serialisering och deserialisering. Vid restore av portfölj kan delader resurser inte naivt ersättas... jämförelse mellan modifierings datum måste till.

Skalbarhet och prestanda

Vi tror iallafall att det inte kan bli sämre (ovanstående förslag). Förhoppningsvis kommer uppslagning av ett record gå snabbt.

Sökningar via lucene är oförändrade. Mer kapabla sökningar via SPARQL kommer att vara möjliga men prestanda är ännu okänt. (YARS bör ju vara mer effektivt).

REST design

Vi har en ide, se bilder. Förutsätter nya URL:ar, se nedan.

En viktig insikt är att om vi börjar med snygga URL:ar, så blir resten av implementationen inte så tung. Dessutom kan man ta det lite i sänder därefter:

• Man kan behålla sessionshanteringen på serversidan för saker som kräver accesskontroll, tex editering och tillgång till skyddade resurser.
• Man behöver inte 'gå över' till REST, istället kan det vara en service vid sidan av den existerande portföljimplementationen... Det är särskilt lämpligt då man tänker på att man gärna vill kunna få ut html representationer av en REST resurs.

OBS, vi har ett terminologi problem då vi gärna pratar om resurser både i Metadata sammanhang och i REST sammanhang. (En URL där vi kan få tag på en fil (vad vi kallar en resurs) är en REST-resurs samtidigt som en URL för att få tag på metadata för filen (metadata för resursen) också är en REST-resurs...).

TODO: transkribera det som står i bilderna ovan.

Features

Snygga URL:ar

Korta och logiska (inbakad namnet på portföljen + id) är id för:

1. Uppladdade filer / kataloger / portföljer / nya resuser får URL:ar som är accessbara direkt, portfoliohost/resource/id (möjligtivis att portolios får egna special urlar).
2. Gamla resurser weblänkar/ ISBN /DOI/PURL behåller sin URL.
3. Varje Named Graph har en URL som portfoliohost/metadata/id

Admin GUI

Vad menas, snyggare i samband med AJAXifieringen kanske?

Stöd för POD

Liknar RSS, bör optimalt göras via content negotion på en katalog. Förden som inte kan göra content negotiation stoppar man in det som en parameter i URL:en.

I övrigt måste varje ny content type behandlas som en ny modul till SCAM som manglar RDF och outputtar önskat data. Även intressant för IMS CP, LOM etc.

Stöd för blog

Låter som CMS funktionalitet i huvudsak. Ej disktuerat.

CalDAV + iCal

• CalDAv (Matthias säger komplext och inga fungerande klienter ännu så vänta).
• iCal, liknar POD, se ovan.

Moodle integration

• Lärare / systemet gör i ordning en katalog av en speciell 'inlämningstyp' där slutdatum anges.
• Student som tittar på ett dokument får upp en lista på alla tillgängliga inlämningskataloger som den kan lämna in till. Studentetn kan uppdatera ända fram till slutdatumet. När den lämnar in så görs en kopia där metadata fixas till så att ägare tydligt anges.
• Studenten kan se i inlämningskatalogen att den har lämnat in via smarta accesskontroller (existernande ACL:er används smart).
• Moodle plugin som hämtar RSS flöde från katalog med inlämnade uppgifter (access kontroll), länkar generas, lärare kan betygsätta.

Ajaxifiering av portföljklienten

Möjliggjörs av RESTifieringen, Dojo är eventuellt ett bra biliotek. SHAME planeras att RESTifieras och AJAX ifieras också, så att en del av jobbet fördelas.

Metadata stöd, taggar och ontologier

I samband med REST diskussionen framkom att man kan använda portföljer för administrativa saker. Tex. snackade vi om:

• System-portfolios (beskriva portölfjer som finns och länka till agenter).
• System-agents (beskriver användare och grupper i systemet).
• System-types (beskriver hur de resurstyper ska hanteras, tex editeras, operationella aspekter (tex hur http på de fundamentala typerna ska göras) hanteras inte här, det är inbyggt).

Taggar

Så, att införa en specifik portfölj som hanterar taggar vore naturligt.

• tillåter sökning per tag, dropdowner i editorer (SHAME stöd för detta är planerat).
• nya taggar kan lägas till och delas ansvar för via inModel propertyn, medför 'mina taggar' är lätt att genomföra.
• Speciell metadataformulär för tag resurser... som man uppmanas fylla i närhelst man använder en ny tag.

Ontologier

Att införa en system-ontologies vore ju lämpligt. Tillsammans med 'ontologyUsed' propertýn kan man få en hint om vilka ontologier som är lämpliga att använda för en viss resurs... Via Named Graphs kan resuseren plockas upp effektivt och kombineras on the fly med ontologier. Nya RDF API:er har bättre stöd för detta (t.e.x. RDFSModel i RDF2GO ?).

Releasehantering

Alla får tillgång till projektplatsen, sen får vi diskturera vidare detta senare.

Prioritering utifrån de verkliga behoven, titta på bilden om de olika användingsområdena för SCAM ovan. Ger input till vilka versioner som behövs.

Enter your comment:

Author: