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

Mon Nov 26 09:14:43 MST 2012

Dear Stephen. I agree with you. Below, I share some comments:

2012/11/23 downes <stephen at downes.ca>

> 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.
>

Also keep in mind the power of Linked data <http://linkeddata.org/>
technologies (URIs for identifier things, semantic web standards,
RDF<http://www.w3.org/RDF/>vocabularies such as: DC, DCTERM, FOAF,
SCHEMA, AIISO; data sources like
DBPedia and Geonames). Linked data <http://linkeddata.org/> offers a set of
best practices for publishing, sharing, interoperating and linking data and
information on the web.
Here are some of the key benefits:
1. Elimination of data open education resources "silos", facilitating
collaboration between OER iniatives and to easily connect with external
data.
2. Integration and processing of external and internal data in order to
contextualize, augment and support acquiring knowledge of open educational
domain
3. Decentralised publishing, data re-use from different open data sources
and Web interoperability. Linked Data technologies have been applied to
many different catalogues and repositories to achieve machine-readable
representations of their content metadata using RDF
4. Linked data has feactures that support dynamic evolution of  schema in a
distributed and heterogeneous  environment.
5. The benefits arise from the emphasis on unambiguous, common identifiers
for things, from the inherent extensibility of the RDF data model, and from
the publication of data in a standard format.

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.
>

I think we need to address different kinds of concepts: repositories,
resources (and resource groups, such as MOOC, OCW), areas of knowledge,
organizations, projects, researchers, open licenses, and others.

Wha**t if you want data when there's* *no *API available*?
If there’s no API, scraping is always an option.

> 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.
>
>
I agree with your strategy: "*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.*" Also, I think that will be useful to agree on some
common concepts to interconnect data sources and resources: knowledge
categories to classify resources, keywords, geographic information, and
define unique URIs to identify common and important data.

metadata repositories to store reusable data models, schemata, taxonomies
and codelists.

> 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.
>

The current divergent interpretations of data, the lack of common metadata
and the absence of universal reference data create difficulties for data
exchange, data re-use, integration, interoperability, and discovery.  Then,
to overcome this, we can develop OER metadata repositories to store
reusable data models, schemas, data dictionaries, taxonomies and codelists.

>
> 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.
>
>
The Linked Data approach makes it easy to publish information in a way that
allows it to be combined with other sets of data, without an up-front
agreement about exactly what information should be published. See,
http://dbpedia.org (A community effort to extract structured information
from Wikipedia ), http://data.europeana.eu (that currently contains open
metadata on 2.4M of resources), geonames.org (he GeoNames geographical
database covers all countries and contains over eight million placenames
that are available for download free of charge.),  or Data Hub:
http://datahub.io/  (The easy way to get, use and share data)

> 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
>
>
>
Linked data is a great way of publishing information for diverse and
distributed organisations, such as OER initiatives/repositories/projects. A
evolutive process can includes the followings steps:

1. Identify the core concepts (classes).
2. Identify the attributes of the core concepts and relations between
concepts.
3. Check the consistency and the availability of attributes values in
proposed repositories.
4. Define a common OER identification and classification agreement.
5. Update the draft of the common metamodel.

Thanks Stephen!

best regards,

Nelson Piedra
Universidad Téncia Particular de Loja, Ecuador
Serendipity Project http://serendipity.utpl.edu.ec/
Serendipity - POIs http://serendipity.utpl.edu.ec/map

>
>
>
> , 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
> >>
> _______________________________________________
> Oer-community mailing list
> Oer-community at athabascau.ca
> https://deimos.cs.athabascau.ca/mailman/listinfo/oer-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://deimos.cs.athabascau.ca/mailman/private/oer-community/attachments/20121126/86812a32/attachment-0001.html 