Tagging specification for building our Best Practice Networks

Version 0.2

Introduction

By promoting a ICOPER, ASPECT and Standards Community specific tagging approach the wider Best Practice Network could store their "stuff" whereever they like and still hope that existing and future aggregation services will be able to find and make use of the resources. Nobody in this Community of Practice is at the moment able to list what types of resources will be exchanged in which format, kept in what stores for what purpose. However, we might hope to build a consensus on the tags we attach to our stuff, so that we at a later stage will be able to identify what is "ours", and for what purpose the stuff is exposed to the world.

We do not "own" our tags. They will be picked up and used by people with various interests in learning technologies and standards. Therefore we want to come up with a tagging regime that, at the same time, clearly identifies the resources produced by the learning standard community, while connecting us to the other communities with more casual interest being our ultimate targets for dissemination, i.e. teachers, school principals, policy makers, etc.

The scheme we come up with should serve four purposes:

1. Identifying the resource with our Community of Practice, and with the particular eContentplus Best Practice Network

2. Classifying the resource according to some main concepts that our communities agree upon

3. Specifying what specific issue(s) the resources is addressing, according to the author

4. Making resources visible to the other communities working in the field of standards and/or learning

Scope

The scope of this ICOPER & ASPECT tagging specification is to describe how tags are constructed and combined, so that the community specific resources can be tagged, searched and aggregated for different purposes, allowing identification of source community and subject of the resource.

Model

The model for tagging ASPECT and ICOPER resources is intended to be:

    • simple to understand and implement
    • accurate enough to be able to retrieve the information easily
    • flexible enough to cope with the complexity of the domain of learning and standards

The proposed tag model consists of using a combination of currently used tags with the addition of a limited ad-hoc ones. According to this model, each resource should be tagged with at least one tag; preferably with 3+ tags.

For example, in order to define documents relative to learning standards, we have the choice between using the combination of Learning and Standards or to create a compound tag LearningStandards.

To fully describe a resource, one or more (compound) tags can be used.

In this tag specification there is no distinction between capital and lowercase letters.

Community span tags

A first series of tags should define the community span:

    1. Learning Standards Development community
    2. The Aspect and iCoper communities
    3. Learning Standards Implementation community
    4. Learning Professionals community
    5. Learning Policies community
    • LearningStandards: This tag serves to identify the Learning Standards Community of Practice as a whole. This tag is not used today and we would like to expand its use to facilitate access to relevant resources. All resources should use this tag to make resources visible to the rest of the world. (This tag will also promote the planned common web space, learningstandards.eu)
    • AspectLS, iCoperLS: This element can be used to identify resources that are specifically relevant to the 2 projects / communities - the suffix LS is used for disambiguation. This tag might be useful to create specific displays, e.g. a list of events, activities relative to the projects. (Comment from Tore: It should be considered to use only "aspect" and "icoper", depending on the result of a survey of the prevalence of these words in the "tag cloud". SR: agreed)
    • Adoption: the combination of LearningStandards and Adoption should be sufficient to avoid the need of a new compound tag.
  • Policy: to address the community involved in policies

ICOPER and ASPECT Core Concepts

In this first draft three core concepts are proposed, described in Figure 1, below.



Figure 1 Core Concepts Model of the ICOPER and ASPECT Issues Space

(Q from Serge: would it make sense for you to add LearningAssment after Learning Delivery or do you want to see it as part of delivery? R from Tore: Assessment and Needs analysis is basically the same activity. Qualifications are assessed before and after delivery of learning. If you add a box LearningAssessment, it will be filled with pretty much the same stuff as LearningNeeds. The process arrows should explain that - or not? SR: I understand you point; may be should it be renamed LearningImpact, as the measure of impact should be embedded in the design of learning systems, and this might link to quality assurance/improvement.)

This model is a simplification of the ICOPER Educational Framework (with five activities: Learning Needs and Learning Opportunities; Instructional Modeling; Content Development; Learning Delivery; and Assessment and Evaluation). The model also captures the ASPECT usage scenario for educational content.

Q from Manuel: Proposing these tags I understand that we are defining a vocabulary, where each tag is assigned a particular description. Nevertheless, someone could use the same tags without being aware of the description provided in this community. In this way, my concern is about if tags should include a reference to the vocabulary. Maybe this reference could be included implicitly in some way, through the tagging mechanism. Maybe the reference should be included explicitly (e.g. AIBPN.LearningNeeds, AIBPN.LearningDelivery where AI means Aspect+iCoper)

Domain tags

Users may extend the core concepts with their own descriptive elements, specifying aspects of Learning Needs, Learning Preparation and Learning Delivery. This might be description of specific specifications or standards the community analyses, e.g. HR-XML or IMS QTI used for competency descriptions and assessment. Or it might be analysis of tools used, e.g.

LearningPreparation, LearningDesignRrepositories

LearningDelivery, LearningResourcesRepositories

When the tags are used within the communities we will see that the practice clusters around a number of domain specific tags that could be subject to standardisation at a later stage.

Usage conventions

Each resource could be tagged with as many tags as the author wishes, preferably more than one, ideally 3 or more. The ICOPER and ASPECT communities might want for documentation and dissemination purposes to build community specific aggregations. Therefore, we would recommend that each resource is allocated at least the tags that this specification uses for describing these communities.

Examples

The following is a list of examples of the use of this specification:

LearningStandards, LearningNeeds, HR-XML

LearningStandards, LearningNeeds, LearningDelivery, QTI

LearningStandards, LearningNeeds, HR-XML, IMS-LD

LearningStandards, LearningPreparation, IMS-LD

LearningStandards, LearningDelivery, OAI-PMH

LearningStandards, LearningDelivery, Educanext

LearningStandards, LearningNeeds, CurriculumExchangeFormat

Open issues

The Core Concepts in this draft is restricted to the educational activity space. However, the standards community is also concerned with other issues, e.g. related to the management of specifications and standards. We should therefore discuss if the Core Concepts should be extended to cover this aspect of our discourse.