Hi Mikael,

> I've finalized an early, but readable, draft of the mapping 
> from IEEE LOM to the DC Abstract Model:
> 
> http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce?acti
> on=AttachFile&do=get&target=LOM-DCAM-newdraft.pdf
> 
> The mapping is presented using the DC-TEXT syntax for DCAM, 
> 
> http://dublincore.org/documents/dc-text/
> 
> I invite anyone interested to submit comments to the 
> DC-IEEELTSC-TASKFORCE list ( 
> http://www.jiscmail.ac.uk/lists/DC-IEEELTSC-TASKFORCE.html )
> 
> The mapping assumes a stable version of the RDF vocabularies in
> 
> http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce/LomTerms

Thanks! This looks good.

I've made another pass over the example on the wiki

http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce/Examples

and I _think_ it's now consistent with your document (with the exception
of one aspect discussed below) - though I probably need to check it
again!

I noticed a couple of very minor glitches in the mapping doc:

1. In the mapping of 1.8 Aggregation level, the target property is
listed as lom:structure. I think that's a typo and it should be
lom:aggregationLevel

2. In the mapping of 4.1 Technical.Format, dcterms:IMT is used as a
Syntax Encoding Scheme, but DCMI describes it as a Vocabulary Encoding
Scheme  

The aspect where the form of the example currently differs slightly is
really an issue of "convention", I think. 

I think the document is recommending what I'll call a "terse" approach
to representing LOM Vocabulary Values i.e. the use of a LOM Vocabulary
Value is mapped to constructs like

  Description (
    ResourceId ( classification1 )
    Statement (
      PropertyURI ( lom:purpose )
      ValueURI ( lomvoc:Purpose-discipline )
    )
  )

i.e. with just a Value URI provided. 

In my initial cut at the example, I took a more "verbose" approach
(which I've left in the wiki page for now), and also included a
Vocabulary Encoding Scheme URI and a separate description of the value,
following the same conventions proposed for the "no URI known" case in
the introduction, e.g.

  Description (
    ResourceId ( classification1 )
    Statement (
      PropertyURI ( lom:purpose )
      ValueURI ( lomvoc:Purpose-discipline )
      VocabularyEncodingSchemeURI ( lomvoc:Purpose )
    )
  )

  Description (
    ResourceURI ( lomvoc:Purpose-discipline )
    Statement (
      PropertyURI ( lom:source )
      LiteralValueString ( "LOMv1.0" )
    )
    Statement (
      PropertyURI ( lom:value )
      LiteralValueString ( "discipline" )
    )
  )

I appreciate that that additional information should be available to an
app by dereferencing the Value URI. I just wondered whether embedding it
was more "symmetrical" with the "no URI known" case, where obviously
there's no URI to be dereferenced to get/GET the additional data so it
has to be included.

I really don't feel strongly about it one way or the other - just wanted
to note the difference and check whether this was the intention! :-)

Pete

---
Pete Johnston
Technical Researcher, Eduserv Foundation
[log in to unmask] 
+44 (0)1225 474323
http://www.eduserv.org.uk/foundation/
http://efoundations.typepad.com/efoundations/