Participants:

Eli, Vicente, Kostas, Adam, Peter

Notes

1) Kostas showed the statisitcal interface of the back-end.

• 6+1 repositories are harvested using both RSS and OAI-PMH protocols. Public iTunesU targets are also harvested via RSS.
• Documentation for content providers are available. More explanation to them is needed on how and where resources are not harvested or filtered out.
• All together about 22k resources are harvested of which 12k are filtered in (i.e. shown in the portal).
• 4 languages are available: English, Spanish, Hungarian and Greek (Protuguese is coming)

2) Vicente showed the front-endportal.

• Categories based on subject field, Most viewed and Recenty added lists on the front page.
• Both full text Google search and PuMuKit-based faceted searches are available.
• Embeded player is not always possible (depends on what the repository owner provides)
• Videotorium subject fields need to be translated
• Video duration is not available everywhere
• Some glitches here and there but good for a demonstration

Adam explained the vocabulary that Videotorim use for the subject element: http://videotorium.hu/en/categories

• Translation between this vocabular and the UNESCO vocabulary used by the GÉANT OER aggregator can be done. Adam looks after this.
• In general, we have two options: a) ask the content providers to comply with UNESCO, b) provide translation. TBC.

3) Peter elaborated on the next steps

• Pilot is considered to be done. KPIs all met. Will be reported to TTC by Peter.
• Final documentation will be compiled and distributed for comments by Peter. (Deadline: end of February)
• Portal will be demoed at the GÉANT Symposium and possibly at TNC'15
• Until the beginning of GN4 (April 2015) the team is off
• Anyhow, we should keep the momentum and discuss on the mailing list (on a volunatry basis until April)
• GN4 SA8 Task 3 will pick the results up and take the OER service to the next level.

Everyones' efforts and hard work are very much appreciated!

Recording:

Participating:

Peter, Kostas,Vicente, Eduardo, Giannis, Eli

Agenda:

1. Summary/Update - Current Status

2. Focus on the Content, Functionality

3. Update on the back-end engine

4. Front and back end interaction

5. Timeline

- - -

1. Current Status

Vicente: working mainly on data structure, adapting the PUMUKIT structure to the application profile

working on the import scripts - not as straightforward as expected; modifying the scripts all the time - related to the structure and the vocabulary

[demonstrates JSON file example: issues with specific fields, supposed values, file formats do not match - need a translation at an aggregation level, media format doesn’t appear, strange language codes - or appear to be English, but isn’t - language codes should be translated, lack of numeric codes, etc.] - issued needed to be solved in order to get good data

Peter: problems related to the metadata translation - should be translated into one format or schema

Vicente: some issued should be fixed at the repository level

Peter: proper translation needed, metadata not exposed by local repositories - a) ask them to change that, b) try to translate it automatically

will have to tackle that later on

Vicente: our own repositories - improving the data exposed in order to make it easy to harvest, but data coming from iTunesu - cannot count on cooperation with the data provider; translation should be done at the repository level

we have all the tools, just need to focus on improving the harvesting process

Peter: can compare the local repository and the one harvested - enough for us to prove that it will work

Kostas: the phase of transformation is problematic, we don’t know what are the elements used from others’ perspective, might have problems with mapping the local elements with the elements of TERENA OER

Peter: thumbnail gets lost for example; need to look for the basic fields we agreed on

Kostas: last time we were harvesting there were no thumbnails

Vicente: part of the collection, not of the item, but we are not working with collections now

Kostas: could harvest information where thumbnail is a part of the item

Vicente: need to interact more to solve minor issues

Kostas: send me the list of issues

Vicente: regarding the portal - some objects have been harvested, currently the URL exposed is not the direct URL to the media, but the player page (can be changed)

categories, filters

search - first implementation

information available at provider level, possible to harvest it

2. Focus on Functionality

Peter: functions need to work, else the end-users will leave, if something doesn’t work, should not be on the pilot version; ok to put new features in as they become functional

Vicente: this is work in progress, users wont be exposed to anything that won’t be working, functionalities there for demonstration purposes only, will be removed

- - -

Peter: Kostas, once the translation is done, others will work or are there differences?

Kostas: main issue is translation, has to be done together with Vicente and his team

Peter: scalability of this process in the future - tedious manual approach for now for every repository; next repository will have to be treated the same? doesn’t seem scalable

Kostas: difficult to create a transformation file for every provider, will take time

Giannis: the first version is for the internal consumption, but later it will be important to communicate to the data providers willing to join

Vicente: maybe institutions willing to do what is needed, but might not; or we can learn to harvest the apple feeds properly

Peter: would not fixate too much on the apple one, we want to connect different sources

Giannis: need to have some educational metadata, else we will just replicate the iTunes harvesting mechanism; need to understand the semantics of the metadata - main problem, else can be corrected

ACTION: Vicente to send a detailed list of issues to Kostas

Eli: need to see how many hours Kostas will need for every repository 5-10 hours - worth it, else need to consider

Giannis: either remove the subject from the front end, or not use metadata that has no subject element - will apply to many elements

Eli: if we will see that we need more go arounds to fix something, maybe we can discuss the technology aspects in the next phase

Peter: we will have development time in the next phase (GN4, April next year) - Kostas will be spending a lot of time working on it

- - -

Timeline

Peter: one more meeting before holidays or better in January? Can also follow up individually  - (will be back on 5 January)

Giannis: specific collections from the iTunes site - who is responsible for those collections?

Peter: iTunesU was identified as an escape for now, but need to focus on the local repositories - everyone in their own countries should look for it, happy to do that in the Netherlands (also need to address the language question later)

Giannis: i will look for Greek collections

Peter: next meeting in January

Software fixes by Kostas

1. Improved the mappings from native RSS Itunes U metadata and DC to the LOM based OER Application Profile.
2. Extended the RSS Harvester to gather information from RSS Channel element and inject it to each and every element where the specific info is missing for example the itunes:image.
3. Extended the seach API to offer duration, format and contributors name.
4. The elements' possible detected languages are limited to en and es.
5. The dates issue is not addressed(and it will be very difficult to be addressed since there is a great diversity in the way dates are defined)
6. A new repository(Standford) is added.Peter sent it to me before sometime ago.It is RSS Itunes U based.Check the dashboards for more info.

Attendees:

Vicente, Eli, Giannis, Kostas, Nelson, Adam, Tibor, Antonio, Jean-Francois, Sigita, Peter

Notes by Sigita

Presentations

• OER Pilot: Value proposal, Concept, Focus by Peter
• OER Pilot: Components, Features, Project Phases by Eli

Links and Attachments

*AGREEMENTS*

0) Project phases:
- Phase 1 (Version 1.0) - until December 2014 (TERENA pilot funding)
- Phase 2 (Version 1.1) - Jan 2015 - April 2015 (no extra funding)
- Phase 3 (Version 2.0) - April 2015 - May 2016 (GN4 T3 Phase 1 funding)

2) The primary focus is on higher education and research (HEI&R) content repositories managed by an NREN or connected institutes.

3) The media type is "multimedia" (lecture recordings, conference recordings, learning objects) that includes video, audio, animation and recorded content stream but excludes still pictures and/or documents in Phase 1.

4) Two usage scenarios:

a) User starts searching globally using Google search service.
- GÉANT OER web portal indexes meta-data so Google finds it.
- User goes to GÉANT OER portal from Google and continue/refine searching there. *ADDED VALUE*
- When the users finds the content, goes off to the local repository or use the embeded player if available (learning process starts).

b) User starts searching in the local/institutional repository.
- Unsatisfied by the results but there is a GÉANT OER search widget made available by the local portal (?) *ADDED VALUE*
- User searches in the widget that directs to the GÉANT OER portal.
- As soon as the content is found and the learning process starts, user goes off to the content repository or use the embeded player if available.

5) Portal features and functionalities in Phase 1:

- Display thumbnails of multimedia objects (i.e. video, audio, animations, but no still pictures or images)

- Include direct URL to the object where available. Use embedded player or naked player provided by the source repository where possible.

- Display metadata based on the application profile (mandatory/recommended/optional) agreed by the pilot group.

- Handle Creative Common licensing.

- Facilitate browsing and faceted search (i.e. organised in predefined categories based on closed vocabulary e.g., UNESCO subjects)

- Implement simple and advanced search; either based on the back-end engine search functions or the Google search engine restricted to the portal. Develop a roadmap for the advanced search functions and the pilot service evolves.

- Implement sharing, primarily via e-mail and social media platforms.

- Apply responsive web design for proper scaling and rendering on mobile devices.

- Deal with user registration; only LDAP-based local registration in the first phase but be ready for Single Sign On (e.g., social media login) and access federations with eduGAIN.

- The portal interface language shall be English; the metadata language should be English if available or the original language of the content.

- Include information pages such as: About us, Help, Contact, Terms & Policies, Disclaimer.

6) Portal features and functionalities in later phases (TBD):

- Federated access and membership management.

- Multi-lingual user interface and customization option.

- Web access for disabled.

- Paradata collection and handling including: rating, commenting, popular items, suggested items, dynamic tag cloud, usage information, quality issues.

- Peer review functionality.

7) List of good quality repositories to start with:

http://tv.uvigo.es/
http://tv.campusdomar.es/
https://educast.fccn.pt/
https://cast.switch.ch/
University of Manchester
iTunesU RSS targets...
YouTube channels...

8) Metadata application profile need to be finalised and provided to the connected repositories to comply with. This could be a mix of IEEE LOM and DublinCore. Keywords are not mandatory. We need help from the providers to translate their metadata schema/vocabulary properly.


*ACTIONS*

I) On Giannis to finalize the metadata application profile. This should be a clear recommendation to the connected repositories.

II) On Kostas to investigate iTunesU RSS harvesting as well as YouTube channel harvesting.

III) On Vicente to start developing the web front-end portal based on the agreed feature set above.

IV) On Nelson to work out a provocative promotion campaign for institutional repositories saying: "Are you ready for Open Education?", "Are you ready to publish your content with open licences?", "Are you ready to connect to the GÉANT OER?"

V) On Peter to finalise and administrative and contractual details.

VI) On ALL to contact your friendly institutes and ask for the iTunesU RSS feeds (if not the OAI-PMH target to their repository). At least, one university per country represented in the OER pilot   Pass it on to Kostas.


*NEXT MEETING*

I think, we need an on-line meeting in two weeks to speed up the process as now we have a good understanding and consensus. I'll circulate a Doodle poll soon.

Notes from Giannis (GRNET)

Attendees:

Adam, Vicente, Eli, Peter, Sigita, Kostas, Giannis, Nelson

Recordings:

http://emeeting.campusdomar.es/recording/a18776711ec9a1ba563a68ecde656eef

Minutes:

1) Status of the initial study, comments by GRNET, Wiki content, etc.

V: the two documents are mainly definition of the service - lacks info what the system will look like and what features will it provide

P: you don’t font the info needed for development? - clear concrete feature list to be determined during the face-to-face meeting

E: the players of the project will be clearly explained in the next version of the document (to be produced in a few days) - looking for input, comments

V: used to working on user driven basis - need to understand what the users are expecting; need to check user specifications (not to be fulfilled at first, but need to make sure that the architecture is ready to be updated for the later versions)

K: […?]

P: Kostas already working on aggregation of the metadata, had a look at the status and statistics - must be part of the document (screenshots, etc.) - to understand what features can be/cannot be implemented; architecture has to be flexible for when we are ready to implement more

P: metadata - a must, paradata - might be left for a later stage

K: issues with getting repositories to expose their paradata

G: the only source of paradata - OER portal - maybe more in the future

(if we want paradata, this has to be collected through the portal)

V: the system currently only collects statistics, but ratings are easy to add

G: better to have the users express this kind of requirement

G:should professors be the primary persona? maybe would be good to have one primary focus.

P: two groups - end users and system admins, would not split those groups further

E: risky to use interviews with professors - can focus on very narrow solutions, need large scale interviews, need to understand what is the state of the art in the world, find more common, most relevant features

V: in any case, need to be connected to the prospective end-users - maybe a more complete survey is needed?

P: continuous feedback necessary

G: 20-30 interviews needed, but due to time limitations a prototype is needed - create the first version and then ask the users for feedback

G: made a new version of the study, no major changes only improvements and small additions

E: integrated most of the comments, got comments from more professionals (mainly professors) - new version will be circulated within 10 days from now

ACTION: Giannis will send his updated version, Elis will prepare a draft for the face-to-face meeting

2) Web front-end development

P: work for Vicente’s team will be defined during the face-to-face meeting

V: need a definition asap - features and structure; also need a contract asap to define man power

P: will start an e-mail dialogue with Giannis and others to give you more clarity before the face-to-face meeting and also start working on the paper work (contracts) now

E: study document contains quite some information about the features etc. that can be used

P: the first version of this application profile should come from Giannis and Kostas

G: we can provide first proposal for that, but its an exercise based on the real needs of the users

V: use the user stories for the exercise

P: plus personas described on the wiki

3) Face to face meeting preparation

P: will prepare an agenda, full day meeting (9:00-17:00), send your arrival times, dinner possible the day before; will need to make decisions during this meeting, so good agenda and good preparation is crucial; booking hotels might be difficult - will prepare some recommendations

4) GN4 Task 3 update

5) Position paper of NRENs on Open Education

6) Priorities, deadlines, AoB

G: Application profile deadline - before the face-to-face meeting?

P: definitely - need to have the new versions of the study from everyone, will try to incorporate work from the wiki, and the application profile; will come up with a draft agenda as well and send it out for comments

V: comments for the user stories are welcome - can be found on google.docs

Attendees: Eli, Giannis, Kostas, Nelson, Peter, Sigita

Agenda:

1) Contributions from IUCC and GRNET (Eli and Giannis)

2) Face to face meeting (Peter)

3) Aggregation engine update (Kostas)

4) GN4 SA8 propoal (Peter)

5) AoB

Minutes:

1) Contributions from IUCC and GRNET (Eli and Giannis)

Peter: happy with the content of the first draft - should be merged together to have one overview on the pilot

• IUCCs contribution - good overview on the current state and describes the services
• GRNET - focused more on the technical details

Eli: What we have in our doc now (welcomes feedback):

• 1 part: introduction of the OER, definition; move to the background of the TERENA OER project and motivation; at last what kind of projects there are;
• 2 part: explanation of what kind of project TERENA project would be.
• 4 LAYERS:

1. Metadata (what kind is needed, based on TERENA survey?)

2. Paradata (comments, user ratings, tags, etc.)

3. Connectivity (connected to libraries, other depositories outside of the main project)

4. Community (social media, creation of the community)

Some of this will be done in the first phase, some in the second.

Wide project, narrow core - unique project, dealing with a lot of issues on the European level

Will be able to connect with many organisations outside of the core of this project

Survey - very important, could be added as an annex or otherwise integrate.

Document also sent to some OER experts

Peter: How can this be merged with the GRNET contribution?

Giannis: Comments on IUCC document: Good basis

Would be good to provide the scope at the beginning of this merged document

3 main objectives:

• provide the specifications for the system, will provide the design and developing phases of the project
• clear specifications most important
• and that it can be used for communication

For specifications: user stories, personas, mockups -> done already, so can easily be included

Q: mandatory subject element - proposed or strongly recommended? we don’t have the subject element in many cases

Eli: all the second part of the doc is opened to discussion, mainly the metadata; some based on the survey; metadata field taken from one of the documents discussed in the past, but it has to be edited together need to understand the scale of the project and other relevant details

Survey and previous discussion can/should be added to the document

Giannis: agree that it could be an appendix together with other long tables

Q: Nothing mentioned about vocabularies?

Eli: if we use the (LOM?) then cannot use anything other this is something that needs to be discussed knows a specialist that can help

Giannis: should include a section about this in the document include some options that we have this part can be connected to the user stories and search and browser functionalities

Eli: vocabulary is relevant to how you add the materials to the system - technology issue, how to implement it, and the filters - might be the best if we can have as many as we can filters and vocabulary

Giannis: also the need to define mappings and to make transformations - need to decide whether it will be done automatically or manually - if manually someone has to take over this task

Eli: how many layers? 2 or 3? effective for the users

Giannis: this can simplify the work but the work of transportation will still be needed this has to be foreseen for the future

Peter: this issue can be left for the face to face meeting - agreement on this is needed

Giannis: we need to define the reference classification at this stage - for as many layers as needed

Peter: maybe skip for phase one, introduce later

Giannis: educational levels - could we also target vocational education?

Eli: should be open to everybody so we can say “higher education and any other users”

Peter: we narrowed down the scope - education in general, focused on higher education (primary focus of most of the NRENs), and focus on those, where the NRENs are active in - could be extended as a next step

Giannis: target audience - does not come up in the proposed schema

Elis: target audience is important to users in the higher education and outside; open to discussion and we have to see what you can implement having a target audience filter is important in the end of the process we might understand that there is no need for this we can take it out, but i believe that it is needed can be mandatory, optional or recommended

Kostas: difference between location element and url element?

Eli: sometimes there is a difference [explains] - [url issue and other should be part of the face to face meeting]

Giannis: two cases - page where resources shown and where resource can be accessed at

Eli: has doubt about the LOM is it would be used, but those who will do the implementation should be part of the face to face meeting; need to agree on the mandatory

Giannis: maybe include a section with other options to LOM?

Kostas: Keeping the balance on the mandatory elements - nice to have as many elements as we need, but from aggregation side is makes it very strict, a lot of metadata will be dropped out, need to find a balance

Giannis: we will not be able to have more than 5-10 elements as mandatory

Eli: if we are leading the way, we need to make a standard; this needs to be discussed based on what the user will get - problem with global - almost no metadata and too much unnecessary material TERENA should recommend the standards

at first maybe 5-10 mandatory fields, but recommend to have more

Giannis: agreed, but need to keep the balance

Giannis: what are the dates of the phase 1&2?

Peter: TERENA pilot - phase one is the one we can implement, the rest will be the “afterlife” of the pilot, in GN4

2) Face to face meeting (Peter)

Peter: need a date

Nelson: who will pay for this?

Peter: preferably your org pays, but could be covered by TERENA (limited number of trips)

Option 1: 25-26 September

Option 2: after 7 October

Will set up a doodle.

3) Aggregation engine update (Kostas)

Currently the Ariadne engine is harvesting about 13 repositories. The detailed statistics can be examined at

http://terenaoer.grnet.gr/index.html#/dashboard/elasticsearch/Terena%20Aggregation

http://terenaoer.grnet.gr/index.html#/dashboard/elasticsearch/Terena%20Metadata%20Analysis

4) GN4 SA8 propoal (Peter)

Peter have been appointed to be the Activity Leader of the new SA8 service activity on "Real-time communications and Media Management services" in GN4 (starting in April 2015).

There are three tasks:

• Real-time video services (former eduCONF)
• WebRTC roadmap
• OER development

Task 3 is to take over the TERENA OER pilot results in April and develop that furter toward a production service of GÉANT. Kostas (GRNET) will be the task leader of that.

5) AoB

Nelson produced a DRAFT plan for the promotioal activity of TERENA OER. The document will be circulated for further comments. 

Peter noted that the pr and marketing efforts must be aligned and incuded in the pilot early on. Nelson's contribution is very much appreciated and will be part of the initial study.

Attendees: Eli, Giannis, Kostas, Adam, Nelson, Peter

Agenda:

1. Initial study kick-off
2. AOB

Peter summarized the actual status of the pilot. We have now two contracts in place; one is with IUCC primarily to coordinate the initial study preparation and the second one is with GRNET mainly to develop and deploy the metadata aggregation engine at TERENA.

Eli (IUCC) is coordinating the study preparation, everybody is invited to contribute. External experts will also be consulted. Giannis (GRNET) will contribute to the metadata schema definition. There was an agreement to use IEEE LOM with about 8-10 mandatory and other 10 optional fields. Kostas commented that a widely used/known schema should be selected in order to be able to aggregate good quality metadata. Metadata translation will be needed anyway. It was suggested to pull a meeting dedicated to the metadata schema discussion. Eli is responsible for coordinating that. Sharing of documents and information via Google docs is preferred.

Giannis and Kostas (GRNET) reported that they have started to contact the potential content providers. 13 NRENs and other organizations have been contacted and requested to harvest and analyze their metadata via OAI-PMH protocol with mixed success. Some repositories only support RSS though. Work is in progress… Some analysis will be available by 25 July and the metadata schema contribution will be ready by 1 August.

Peter (TERENA) said that the discussion about the web portal front end development is progressing. UVigo agreed to lead that part of the pilot. Contract will be in place by September. We have to come up with clear requirements and recommendations for the web front end interface by then.

Nelson (FCT) would be happy to contribute to the outreach and dissemination strategy part of the study. He could also be our liaison person to TF-CPR. Peter will put him in contact with TF-CPR.

Peter will Doodle for the potential dates of a face to face meeting where the results of the initial study and the next steps can be discussed and agreed. The meeting most likely will take place in September in Amsterdam.

Attendees: Eli, Kostas, Vicente, Rui, Adam, Antonio, Peter

Agenda:

1. Content of the Study
2. How to proceed

Recording:

http://emeeting.campusdomar.es/recording/4bcc81ced2cb65ced4c3f95720654625

Notes:

Peter predented the DRAFT table of contents for the Initial Study and opened the floor for comments and discussion.

Coordinator: IUCC

Contributors: GRNET, UVigo, ISEP

Deadline: 15 August 2014

-----

OER state-of-the-art and outlook 

1. State-of-the-art content/metadata repositories/referatories and their functionalities
1.1. Repository strategies and policies: National, European and global initiatives (GLOBE, openeducationeuropa.eu, etc...)
1.2. TERENA OER differentiator; primarily focusing on higher-education and research (big science groups)
1.3. Classification of the user community and their requirements in 3-5 years (end-users, e-learning service integrators)

2. Architecture design
2.1. Information model and metadata schema, recommendations (mandatory, optimal)
2.2. Standards and interoperability
2.3. Harvesting engine, standard protocol set, technical features
2.4. Preliminary analysis of connected repositories
2.5. User interface and web portal functional and usability requirements

3. Promotion and outreach
3.1. Engaging users and producers
3.2. Legal and rights issues

-----

Eli commented that Chapter 1 should give the bigger picture (open education, MOOC, etc.) and the whole study should narrow down to the specific recommendations and requirements. We have to clearly understand the current trends in education and response to that. Vicente added that first we should describe the "idealistic" picture reagarless of the existing tools and then in Chapter 2 we should take into acount what tools we can reuse and see how close we can get to the idealistic solution. The closer the better.

Antonio commented that the understanding on the typical workflow how professors develop courses and use tools (such as Moodle LMS) is the key. The proper liaison with the various institutional repositories (mostly DSpace-based in Portugal) is also important to support the federated model. Trust is the key for quality assurance (the use case of sexual education was mentioned where finding good quality educational content is difficult). Integrating with AAI and developing functions such as the peer review system could maintain the trust relationship with content providers.

Antonio and Vicente offered help to incorporate the professors' view and review the study from the education perspective.

It was also suggested to use Google docs for the collaboration and distribution of the study.

Peter noted that the administrative steps (contracting, etc.) will be done shortly after TNC2014.

Attendees: Eli, Giannis, Kostas, Rui (partly), Nelson, Adam, Peter

Agenda:

1. Look at the Personas
2. How to transform requirements into basic features for both the engine and the web portal
3. Reference repository <=> reference web portal (demonstrators)

Notes:

Peter summarised the key requirements comming from the Personas proposed at the last meeting. The group made an effort to categorise the Personas. Two main categories have been identified:

  a) End-users; such as students, professors and researchers (i.e. A, B, C, D, G, K)

  b) E-learning administrators; such as service managers and system/service integrators (i.e. E, F)

Giannis suggested to extract the requirements from the Personas and identify the list of "top problems" that we are trying to give an answer to.

Attendees had a consensus on writting an initial study that leads to some clear design requirements concerning both the aggregation engine (back-end) and the web protal (front-end).

Such a study must be done by mid August 2014 as the latest so that the necessary software developments and deployments (recommended by the study) can be done by the end of the year.

Eli (IUCC) agreed to coordinate the production and delivery of such a study and Giannis (GRNET) offered to contribute to the harvesting engine related technical parts of the study. Adam (NIIF) and Nelson (FCCN) will check back whether they could also contribute to the study, provided that the draft table of content of the study is agreed.

The attendees did a short brainstorming on the potential content of the study. Peter suggested that the study should start with a technical overview on the state-of-the-art content repositories and their basic characteristics. Giannis said that the overall picture should also be described including similar global (e.g., GLOBE) and European (e.g., openeducationeurope.eu) initiatives and their relation to TERENA OER. The basic information model, metadata schema, and protocol set should also be suggested by the study. Contribution to the user interface and the web front-end requirements is necessary. The functional description should look ahead to 3-5 years in time taking into account the latest trends in on-line teaching & learning  .

The study must be delivered by 15 August 2014 as the latest, the harvesting engine adaptation and deployment as well as the web portal development can then go hand in hand base don the recommendations of the study.

The next meeting will be dedicated to the discussion on the Table of Content of the study.

Attendees: Eli, Giannis, Rui, Adam, Peter, Nelson

Agenda:

1. Personas

Recording:

http://emeeting.campusdomar.es/recording/a5fcb5b9c50cc97b644b159387021180

Notes:

Rui's personas were Adam, Bob and Charlene. Bob usually searches for materials in Google but the academic value for him is in TERENA OER. Bob is a not-so-experienced guest teacher who uses Moodle but needs some ready-to-use content. He values that Moodle that he knows reasonably well is connected to the TERENA OER. Charlene is the person at the university who teaches the teachers. Reusability of materials is important for her.

Displaying "favourite content" can help to find similar contents more easily. Ratings, registered user tracking (AAI) and social networking are important.

There is a difference between the monilithic LMS approach and the open MOOCs approach. TERENA OER should support both. Following the users' behaviour is important in case of MOOCs where they can alter from the default learning path. We need to know what they are searching for.

Eli commented that the community and social aspects are challenging. We need to focus on the repositories with good quality metadata, then allow the collection of paradata (remarks, rating, comments) and finally we can bring in the networking/social aspects.

The confidence of the users can be gained by trusted information sources, good quality metadata, additional paradata and maybe in the future a peer review system.

We should be able to integrate Moodle LMS with TERENA OER by the end of the pilot.

Next step: We need to transform the requirements (coming from the Personas) into basic features

Some administrative aspects of the pilot must be clarified:

• Roles and responsibilities of the participants (to be discussed off-line)
• TERENA funding schema (contract template will be sent by Peter)
• Community must be informed about the OER group but not yet invited (oer mailing list will be created by Peter)

Personas:

Attendees: Eli, Vicente, Giannis, Rui, Jack, Peter

Agenda:

1. What are the SMART goals of the pilot
2. How we are going to deliver the pilot

Recording:

http://emeeting.campusdomar.es/recording/838013fa539370e4d9a7d3cd3fd55361

Notes:

Virtual meetings will be held bi-weekly for the pilot participants. The delivery of the contracted tasks should be monitored more closely and frequently (at least weekly) by the person responsible for the delivery.

There was a discussion whether the 9-month pilot period is okay or too short. It basically depends on the detailed objectives (SMART goals) that we want to achieve.

The identification of the target user groups and the engagement with the professors are essential. Portal features like access to thumbnails, embedded rich media players, see what other people use, etc. are important for them.

The only demonstrator of the OER harvesting engine back-end is the portal front-end. We need to define the most important features of the portal.

An agile approach must be taken where we define some personas (user stories) first, mock-up a couple of portal examples, and define the back-end requirements to that.

Users => Portal features => Metadata schema and information model => Aggregation engine

The processing and validation of the collections (connected repositories) takes time. We also need some kind of filtering of the good quality metadata.

Moodle LMS widgets should also be incorporated into the pilot system.

The next coming meetings should focus on only one topic at a time to reduce discussion time. (Personas will be discussed next time).

Key Performance Indicators for the TERENA OER pilot's outcome.