Development:Outcomes: Difference between revisions
Ray Lawrence (talk | contribs) mNo edit summary |
Mark Burnet (talk | contribs) mNo edit summary |
||
Line 18: | Line 18: | ||
Most systems attempt to seperate the semantics from the representation of metadata. | Most systems attempt to seperate the semantics from the representation of metadata. | ||
# Semantics tell us the meaning of a data element but are free from version or constraints | # Semantics tell us the meaning of a data element but are free from version or constraints | ||
# | # Representations of the metadata tell us what table and column metadata appears in each version of Moodle and what the limitations are in a specification | ||
Many metadata managment systems use a 3-part data element name: | Many metadata managment systems use a 3-part data element name: |
Revision as of 17:29, 30 December 2006
Feature description: Build on the keywords in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula.
This page is an initial place to discuss options for storing and managing moodle metadata. These are just suggestions and are made by a person who does not know moodle internals.
There are several steps to managing a complex applications metadata:
- Document the key "Data Element Concpets" and their structure. This would include high-level concepts such as Course, Student, Teacher etc.
- Document data element properties associated with each concept. Properties should always be associated with a concept.
- Store this metadata in a metadata "registry", a centrally managed place to store metadata
- Create a system that allows users to modify and update metadata
There are several ways to approach this.
- There are metadata registry standards such as ISO/IEC 11179. This standard has a wide number of interpretations.
- There are other education metadata standards such as IMS global and the School Interoperability Framework (SIF)
- Once the metadata is stored in a consistant place and format, transforms can be made to extract portions of the metadata using reports or transforms
- A metadata registry can be the heart of a model-driven architecture
Most systems attempt to seperate the semantics from the representation of metadata.
- Semantics tell us the meaning of a data element but are free from version or constraints
- Representations of the metadata tell us what table and column metadata appears in each version of Moodle and what the limitations are in a specification
Many metadata managment systems use a 3-part data element name:
ClassPropertyTerm
Were Class is the concept, property is a property of that concept and Term is a Representation term such as Count, Date, ID, Indicator, Text
For example:
CourseDescriptionText
Questions
- Where can we get a list of key moodle conceptual data elements and their definitions?
- How do we set up a data stewardship role so individuals take responsiblity for maintaining subsets of all the data elements?
- What should the highest level data elements be? Course, Enrollment, Organization, Person, Quiz
See also
- Metadata:MoodleCore LOM application profile for Moodle course
- Thing A root data element of a metadata registry
- Wikipedia entry for Metadata registry
- Wikipedia entry for ISO/IEC 11179
- Wikipedia entry for Data element
- Wikipedia entry for Representation term
- Wikipedia entry for Data element name
- Wikipedia entry for Data element definition