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 who are not too interested in learning technologies and standards. Therefore we want to come up with a tagging regime that is odd enough to keep some distance to the “non standard” populace, and specific enough to let us capture our stuff through simple searches of the general resource cloud on the Internet.
The scheme we come up with should serve three purposes:
1. Identify the resource with our Community of Practice, and with the particular eContentplus Best Practice Network
2. Classify the resource according to some main concepts that our communities agree upon
3. Specify what specific issue(s) the resources is addressing, according to the author
The scope of this ICOPER & ASPECT tagging specification is to describe how tags are constructed, 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.
Figure 1 The ICOPER/ASPECT tag model
The first element is the Identifier. This element serves to identify the Community of Practice as a whole, or a specific community, e.g. ICOPER or ASPECT. This element will disambiguate searches so that resources with tag strings being part of our tags are not retrieved.
The second element is the few core concepts that describe the “issues space” of ICOPER, ASPECT and our learning technologies standards community at large.
The third element is the extension which is up to the individual author to decide.
To fully describe a resource, one or more tags can be used.
In this tag specification there is no distinction between capital and lowercase letters.
LS (for Learning Standards) is used to identify a resource, without attributing this resource to a specific community.
LSa is used to identify a ASPECT community resource.
LSi is used to identify a ICOPER community resource.
Other communities could use their identifying third letter to connect their resources to their communities.
ICOPER and ASPECT Core Concepts
This model is a simplification of the ICOPER Educational Framework (with five activities: Learning Needs and Learning Opportunities; Instructional Modelling; Content Development; Learning Delivery; and Assessment and Evaluation). The model also captures the ASPECT usage scenario for educational content.
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. Learning Preparation Learning Design repositories; Learning Delivery Learning Resources Repositories.
When the tags are used within the communities we will see that the practice clusters around a number of extensions that could be subject to standardisation at a later stage.
Each resource could be tagged with as many tags as the author wishes. 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 two tags, e.g. LS-LearningNeeds-QTI and LSa-LearningNeeds-QTI.
The following is a list of examples of the use of this specification:
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.