Development:Outcomes: Difference between revisions
Dan McCreary (talk | contribs) No edit summary |
Dan McCreary (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
This | This pages 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: | There are several steps to managing a complex applications metadata: | ||
# Document the key "Data Element Concpets" and their structure | # 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 | # 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 | # 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 | # Create a system that allows users to modify and update metadata | ||
Line 9: | Line 9: | ||
There are several ways to approach this. | 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 metadata registry standards such as ISO/IEC 11179. This standard has a wide number of interpretations. | ||
* There are other metadata standards such as IMS global and the School Interoperability Framework | * 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 | * 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 matadata registry can be the heart of a model-driven architecture | ||
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 | ||
# Represtations of the metadata tell us what table and column metadata appears in each version of Moodle and what the limitations are in a specification | # Represtations 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? | |||
==See also== | ==See also== | ||
* [ | * [http://en.wikipedia.org/wiki/Representation term] | ||
* [http://en.wikipedia.org/wiki/Metadata_registry] | |||
* [http://en.wikipedia.org/wiki/ISO/IEC_11179] | |||
* [http://en.wikipedia.org/wiki/Data_element] | |||
* [http://en.wikipedia.org/wiki/Data_element_name] | |||
* [http://en.wikipedia.org/wiki/Data_element_definition] | |||
==Example of a K-12 education metadata registry for == | |||
* [http://education.state.mn.us/datadictionary Minnesota (US) Department of Education Data Dictionary] |
Revision as of 03:35, 3 February 2006
This pages 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 matadata 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
- Represtations 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?