[Oer-community] Our discussion of essential information for a map...

downes stephen at downes.ca
Fri Nov 23 15:56:17 MST 2012


Hiya all,

This is beginning to read and sound very much like the debates around
learning object metadata of the 1990s. I know that approaches such as LRMI
represent an improvement in that elements are aligned with schema.org data
types. But that said, knowledge of the history would be useful, and I do
recommend to people making suggestions to look at IMS and IEEE LOM as well
as LRMI.

It would also be helpful (through probably not practical) to review the
discussion surrounding these specifications. For example, below, we read a
request for "technical requirements for using the material." This is better
addressed by describing the resource format and specifications (eg., its
mime type) rather than specifying application software. This is because
software changes rapidly. Consider the requirements in IMS-LOM documents
specifying that a resource is 'best viewed in Internet Explorer 3.0'.

If course, this discussion is centered around OER *repositories* and not
only the resources themselves. Consequently, mappings will need to describe
repository properties. Consulting OAI or DSpace specifications would be
helpful here. Minimally, we would want API specifications for resource
creation, reading, update and deletion, as well as classification systems
and resource metadata specifications.

All of this is difficult to build from the ground up. It is a discussion
that has occupied the field for almost two decades. I am thinking at this
point that the OER initiative should be drawing from the experiences of OER
repositories and repository indices that already exist. The most useful
beginning of a needs project ought most probably to be a summary of the
properties of existing repository indices, including the range of resources
indexed, metadata fields used, and more.

For those specifically interested in resource metadata, rather than
repository profiles, may I recommend my article 'Resource Profiles'
http://www.downes.ca/post/41750 (I'm sorry to recommend my own work but it
will keep this post a lot shorter). It suggests approaches for the
following sorts of metadata:
- first party metadata, which is metadata specifically about the resource
itself, eg., technical data, rights metadata, bibliographic data
- second party metadtata (sometimes called 'paradata') related to the use
of the metadata, such as ratings, accesses, etc
- third party metadata, such as classifications, educational metadata
(including things like curriculum, keywords, etc)etc.

Additionally, readers should take account of the desirability of linked
data. For example, the use of strings to represent authors and publishers
creates the possibility of ambiguity, error and duplication. Contemporary
resource repositories, such as Google Scholar or academia.edu, maintain
separate registries of authors, which are linked to resources (JSTOR
doesn't, but should, as a search for au:"Stephen Downes" already returns
results from a bunch of strangers). It would be worth contemplating linking
authors and OERs to additional resources, such as publishers and
institutions (many of these are already described by schema.org). Another
argument in favour of linked data is that any string data will need to have
several properties, including character encoding and language. So it's best
to use strings sparingly.

All of the considerations above must also be mapped to a consideration of
what people will actually do in the way of creating and using resource
metadata. I recall a study by Norm Friesen, for example, examining the use
of IEEE-LOM to index learning objects. Though the specification enables
detailed educational descriptions, most people used only ten percent of the
fields. Much of the metadata available will be minimal. Any mapping will
need to contemplate listings using the most basic data: title, link (ie.,
URI) and description. Any system should attempt to automatically generate
metadata (my own website automatically generates image metadata) and make
good use of tags.

-- Stephen





, On Fri, 23 Nov 2012 15:35:42 -0500, Edward Cherlin <echerlin at gmail.com>
wrote:
> On Mon, Nov 19, 2012 at 11:15 AM, Susan D'Antoni
<susandantoni at gmail.com>
> wrote:
>> Dear Colleagues,
>>
>> On Friday, I tried to nudge the discussion back onto the issue of what
>> information would be essential for an OER world map.  Can I try
>> again.....
>>
>> The sample map at http://oerworldmap.oerknowledgecloud.org/ has 3
>> different
>> levels of information if you use the Filter and go to Markers 1,2,3. 
>> This
>> is just to show one way of giving people a quick entry point for
>> information
>> about an OER initiative.  (The text of the markers is below)
>>
>> Looking at these and thinking about the elements of information
>> identified
>> in discussion last week (see Sara's summary), does anyone wish to
>> comment on
>> this issue further?
> 
> Please add the technical requirements for using the material. Is it
> platform-specific? Does it require particular hardware (camera, I/O,
> printer, etc.) or software? Is it in a particular file format? What
> would have to be done to translate or adapt the material, with what
> tools?
> 
> Also, educational prerequisites and applicable software licenses.
> 
> Here is a sample, as it might appear for a project I am working on.
> 
> Etoys Reference Manual
> 
> Formats: HTML, PDF, EPUB, print
> 
> Organizations: FLOSS Manuals, the Etoys/Squeak community
> 
> Sites: http://www.flossmanuals.net/
> 
> http://www.squeak.org/
> 
> http://www.squeakland.org/
> 
> Link: http://booki.flossmanuals.net/etoys-reference-manual/_edit/
> 
> License: GPL
> 
> Software prerequisites: Etoys
> 
> Educational prerequisites: Etoys programming experience, perhaps a
> year or so, depending on the student's level of development.
> 
> Hardware prerequisites: Etoys runs on the Smalltalk VM, which runs on
> almost any computer. Camera, microphone, speakers, and various IO are
> optional.
> 
> Adaptations are done via changesets and packages.
> 
> Localization: Some Unicode support, including Pango for rendering.
> Insufficient IDE and non-Latin keyboard support. Uses the standard pot
> file format. Localizations are being done at
> http://translate.sugarlabs.org/projects/etoys_new/ to 64 languages.
> 
>> Best,
>>
>>
>> Susan
>>
>>
>> **************************
>>
>>
>> Marker 1 .....Miinimal information
>>
>>
>>
>> OER Initiative: MIT OCW
>>
>> OER Initiative web site: http://ocw.mit.edu
>>
>>
>>
>> Institution: Massachusetts Institute of Technology MIT
>>
>> Institution website: http://www.mit.edu/
>>
>> Country: United States
>>
>>
>>
>> *******************************
>>
>> Marker 2 ......More information
>>
>>
>>
>> OER Initiative: OER @ AVU
>>
>> OER Initiative web site: http://oer.avu.org
>>
>>
>>
>> Institution: African Virtual University
>>
>> Institution website: http://www.avu.org/
>>
>> Country: Pan African intergovernmental organisation
>>
>>
>>
>> OER Initiative contact: contact at avu.org
>>
>> Start year: 2011
>>
>> Level of education: Tertiary
>>
>> Languages: English, French, Portuguese
>>
>>
>>
>> ***********************************
>>
>> Marker 3 .... More information with a link to a case study of the OER
>> initiative
>>
>>
>>
>> OER Initiative: OpenLearn
>>
>> OER Initiative web site: http://www.open.ac.uk/openlearn
>>
>>
>>
>> Institution: The Open University
>>
>> Institution website: http://www.open.ac.uk/
>>
>> Country: United Kingdom
>>
>>
>>
>> OER Initiative contact: Andrew Law
>>
>> Start year: 2006
>>
>> Languages: English
>>
>>
>>
>> Case study: A case study of OpenLearn was prepared for the Open
>> Educational
>> Quality Initiative (http://www.oer-quality.org) The full text of the
case
>> study can be found at http://cloudworks.ac.uk/cloud/view/3494
>>
>>
>> _______________________________________________
>> Oer-community mailing list
>> Oer-community at athabascau.ca
>> https://deimos.cs.athabascau.ca/mailman/listinfo/oer-community
>>


More information about the Oer-community mailing list