DCMI IEEE LTSC Joint taskforce at DC2007
Download as ODP, PDF1 like2,805 views
This document discusses the work of the DCMI-IEEE LTSC Task Force to specify how to express Learning Object Metadata (LOM) instances using terms and constructs from the Dublin Core Metadata Initiative (DCMI) Abstract Model. The Task Force aims to develop a Recommended Practice that defines how LOM elements can be mapped to DCMI Abstract Model classes, properties and encoding schemes to allow LOM metadata to be combined with DCMI metadata in applications. The Task Force has produced initial analyses and examples and plans further work to create an application profile and transformation between LOM and the DCMI Abstract Model representation.
![DCMI-IEEE LTSC Task force Mikael Nilsson < [email_address] > DC 2007, Singapore Aug 27, 2007](https://image.slidesharecdn.com/dcmiieee-1211808510337555-8/85/DCMI-IEEE-LTSC-Joint-taskforce-at-DC2007-1-320.jpg)
![Task Force Formalities Task Force charter approval by DCMI Advisory Board and LTSC SEC [DONE] Withdrawal of P1484.12.4 RDF binding of LOM [DONE] Start work on PAR [proposal exists] Next steps: Agree on PAR , set up WG (NOTE: joint work still in TF) Start working on the process issues](https://image.slidesharecdn.com/dcmiieee-1211808510337555-8/85/DCMI-IEEE-LTSC-Joint-taskforce-at-DC2007-10-320.jpg)
![LOM => DCAM mapping Recommendation for using LOM metadata in Dublin Core descriptions A mapping “LOM elements” => “instances of DCAM concepts” Not a binding, but a translation (lossy in part) All constructs are used: properties, value strings, value URIs, [vocabulary|syntax] encoding schemes, related descriptions, except rich representations](https://image.slidesharecdn.com/dcmiieee-1211808510337555-8/85/DCMI-IEEE-LTSC-Joint-taskforce-at-DC2007-17-320.jpg)
Ad
More Related Content
Viewers also liked (7)
Similar to DCMI IEEE LTSC Joint taskforce at DC2007 (20)
Ad
More from Mikael Nilsson (9)
Ad
Recently uploaded (20)
DCMI IEEE LTSC Joint taskforce at DC2007
- 1. DCMI-IEEE LTSC Task force Mikael Nilsson < [email_address] > DC 2007, Singapore Aug 27, 2007
- 2. Scope & Purpose This Recommended Practice describes IEEE LTSC P1484.12.1 Learning Object Metadata instances in the Dublin Core Metadata Initiative Abstract Model. The Recommended Practice will include the specification of DCMI Abstract Model terms, including properties, vocabularies, syntax encoding schemes and vocabulary encoding schemes, that may be used for expressing metadata conforming to the IEEE LOM Standard in Dublin Core metadata . The recommendation will include the specification of URIs to use for the terms, as well as a description of how to combine the specified terms so that metadata instances conforming to this Recommended Practice conform to the IEEE LOM Standard.
- 3. Resources Wiki: http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce Mailing list: http://www.jiscmail.ac.uk/lists/DC-IEEELTSC-TASKFORCE.html 38 subscribers currently
- 4. Progress Existing documents: Initial LOM-in-DCAM analysis Set of classes and properties Examples Work has been on hold waiting for New version of DCAM New version of DC-RDF Domains & ranges for DC properties
- 5. Status New DCAM: Recommendation! Makes Vocabulary encoding scheme != value type Distinguishes Literals and Nonliteral New DC-RDF: Proposed Recommendation! Domains & ranges: In progress!
- 6. Workplan Update: Initial LOM-in-DCAM analysis Set of classes and properties Examples Create: Application Profile based on LOM Including Description Set Profile GRDDL transformation from LOM-XML to LOM-DCAM-in-RDF
- 7. Background LOM elements not usable in combination with DCMI elements (e.g. in Dublin Core APs) RDF a way to combine LOM and DC First LOM/RDF draft September 2002 Not generalizable to other DC formats / DCAPs Other alternative: ad-hoc mapping March 2005: DCMI Abstract Model => New possibilities for interoperability!
- 8. Goals conform to utilizes encodes TF goal (via LOM-DCAM) currently (via LOM-RDF) DCMI Abstract Model DCMI Terms LOM Terms DC Application Profile MARC Terms DC-XML RDF HTML Vocabularies Encodings LOM
- 9. Joint DCMI/IEEE LTSC Task Force Initiated at DC2005 in Madrid, Sep 2005 Chairs: Mikael Nilsson & Jon Mason Participation open to all (18 subscribers ATM) Wiki hosted @ Dublin Core, mailing list @ JISCmail In what sense Joint ? Collaborative work on drafts Joint consensus Co-publishing of results Reports to DC-Ed & LTSC
- 10. Task Force Formalities Task Force charter approval by DCMI Advisory Board and LTSC SEC [DONE] Withdrawal of P1484.12.4 RDF binding of LOM [DONE] Start work on PAR [proposal exists] Next steps: Agree on PAR , set up WG (NOTE: joint work still in TF) Start working on the process issues
- 11. PAR proposal Scope: This Recommended Practice describes IEEE LTSC P1484.12.1 Learning Object Metadata instances in the Dublin Core Metadata Initiative Abstract Model. The Recommended Practice will include the specification of DCMI Abstract Model terms, including properties, vocabularies, syntax encoding schemes and vocabulary encoding schemes, that may be used for expressing metadata conforming to the IEEE LOM Standard in Dublin Core metadata. The recommendation will include the specification of URIs to use for the terms, as well as a description of how to combine the specified terms so that metadata instances conforming to this Recommended Practice conform to the IEEE LOM Standard.
- 12. PAR proposal (cont.) Purpose: There is an increasing demand for interoperable definitions of Dublin Core metadata terms and IEEE LOM data elements which allow these to be used together in metadata instances. This Recommended Practice will approach part of this situation by describing how to use IEEE LOM and Dublin Core terms together in Dublin Core metadata instances. This represents a partial and short-term solution to the overall issue, which will still be of great value in the short to medium term for implementers that are struggling with these metadata interoperability issues. The Recommended Practice will also be of great value in the longer-term process of trying to align the abstract models of IEEE LOM and Dublin Core, as it will provide an analysis of fundamental incompatibilities between the two models.
- 13. Process issues Both an IEEE “Recommended Practice” and a DCMI “Recommendation” Consensus in both communities Both communities can contribute Both communities can participate in ballot If no consensus reached, none will be published Timing and commenting issues DCMI very flexible, IEEE more rigid Follow IEEE procedure, adjust DCMI schedule & process?
- 14. Task Force Progress “strawman” in Wiki a first outline of what the work involves a complex example Draft properties and classes Stage now set for open discussions on particular mapping issues draft formatting supporting documents (schemas, tuturials?, etc...) process issues
- 15. DCMI Abstract Model DC is much more than 15 terms (>80 in fact) DCAM: DCMI recommendation in March 2005 Specifies the relationship between properties, values, encoding schemes etc. High level of compatibility with the RDF model Used by bindings (XML, RDF, XHTML) DCMI terms are instances of the concepts in the DCAM DCAPs are based on the concepts in the DCAM
- 16. DCAM property DCAM describes relationships... ...using statements: identifies identifies represents classifies Resource Value Statement Property URI Value URI Value String Syntax Encoding Scheme URI Language Tag Vocabulary Enc. Scheme URI
- 17. LOM => DCAM mapping Recommendation for using LOM metadata in Dublin Core descriptions A mapping “LOM elements” => “instances of DCAM concepts” Not a binding, but a translation (lossy in part) All constructs are used: properties, value strings, value URIs, [vocabulary|syntax] encoding schemes, related descriptions, except rich representations
- 18. LOM XML: Corresponding DCAM: Example <lifecycle> <version> <string language=”en”>1.0</string> </version> </lifecycle> Statement: PropertyURI: lom:version VocabularyEncSchURI: lom:Version Value String: “1.0” Language: “en”
- 19. More complex example (LOM) <lifecycle> <contribute> <role> <source>LOMv1.0</source> <value>author</author> </role> <date> <dateTime>2002-04-05</dateTime> </date> </contribute> </lifecycle>
- 20. More complex DCAM example lom:contribute lom:role dc:date Description 1 Description 2 Description set
- 21. Consequences for LOM LOM elements reusable in DCAPs LOM may be viewed as a basic DCAP RDF binding of LOM for free First step towards better alignment of abstract models? Most work already done within LOM RDF binding Separates LOM=>DC translation from the specific RDF binding.
- 22. DC and RDF abstract models Both DC and RDF use a resource – property – value model DC has more high-level “values” than RDF value URIs value strings rich values, etc. The LOM RDF binding uses the RDF model (of course) It also tries to be compatible with the DC model.
- 23. Work in Progress at DCMI DCAM (March 2005) is leading to many changes: Improved DCMI Terms definitions Total remake of DC RDF expression Total remake of DC XML expression Shift from Terms to Model: Refocus on APs.
- 24. Looking forward to LOMNext... Lesson from Task Force work: What is LOM??? To understand LOM, we need: an Abstract Model (=elements-in-elements) a set of terms (the LOM Elements) a set of rules for combining them (the LOM AP) Which is the real business of LOM?
- 25. A High-Level view of Metadata Frameworks LOM Data Model
- 26. Metadata Frameworks Dublin Core: Separates Vocabulary, Model, Formats and APs LOM: Mixes Vocabulary, Model and AP, separates Format ISO MLR: Mixes Vocabulary, Model and AP, separates Format Which path to take?
- 27. Comments?
- 28. Metadata Interoperability Issues LOM elements not usable in combination with DCMI elements (e.g. Dublin Core Aps) The concept of “element” differ substantially between the two standards Surface interoperability: XML namespaces RDF ...but the interpretation of these expressions differ
- 32. Interpreting XML and RDF metadata
- 33. Requirements for Reusability The components must be unambiguously identified The components must adhere to compatible abstract models. A metadata format must be used that allows for consistent interpretation of the components with respect to their respective abstract models.