Dear DC Edu colleagues,

following Mikael Nilsson's suggestion, I forward his mail below to the list together with my comments. I like his comments very much as refreshing and thought-provoking.

The subject is on the concept of application profiles and on the possibilities to combine different specifications. I am very grateful for Mikael's precise remarks which allow me to reply with short comments within his text. I just need to make a few initial remarks which apply to all items below.

Mikael refers for a detailed discussion to [1]. [1] is about combining and profiling different metadata specifications. While I find combining specifications with largely overlapping domains, like metadata, to be the least interesting case, the considerations in [1] are indeed more general than they claim to be. In fact, seeing metadata as "data about data" (with some additional features), they are ultimately data too and the arguments in [1] do not rely essentially on any meta data specific properties, i.e. they might apply to any data format specification to the same extent.

The one essential argument, underlying the claims in [1] that combination of specifications and interoperability using profiles are doomed to fail is, that different specifications use different abstract models (information models in IMS jargon), and that combining them "is similar to trying to combine, say, English and Chinese text in a single Unicode document and expecting the combination to make sense" (p.18 of [1]). I really fail to see the point of this argument - there are English speaking Chinese and combining two processors working according to two different abstract models is much easier than for a Chinese to learn English.

There is no point anymore in discussing that the combination of application profiles is not useful or impossible - SCORM did it, IMS ePortfolio did it and we do it in IMS Common Cartridge, including a DC mapping.

I'll give more comments in Mikael's text below.

With kind regards

Ingo

-----Ursprüngliche Nachricht-----
Von: Mikael Nilsson [mailto:[log in to unmask]] 
Gesendet: Donnerstag, 16. August 2007 16:07
An: Ingo Dahn
Betreff: Re: Describing Application Profiles

Thanks for your comments, Ingo!

mn 2007-08-13 klockan 08:42 +0200 skrev Ingo Dahn: 
> Dear Mikael Nilsson,
>  
> my name is Ingo Dahn, I am a member of the IMS Global Learning
> Technical Advisory Board. Within IMS I am in particular concerned with
> issues of application profiling. Recently an increasing number of IMS
> specifications is not build from scratch but build as domain profiles
> of existing specification. IMS is also working to establish generic
> conformance testing facilities for application profiles, based on the
> technology developed in the European project TELCERT. That technology
> works for any specification with an XML schema binding. However the
> expressive power of our application profile goes beyond XML Schemas.
> Already some years ago IMS has established guidelines for developing
> and encoding application profiles which you may find at
> http://www.imsglobal.org/ap/.

I'm well aware of the IMS set of specifications - I was involved in the
1.2 version of the metadata spec.

A few thoughts come to mind:

1. The notion of APs is *very* different in the DC and IMS/LOM
communities. See [1] for a looong discussion. In short, DC does not rely
on "profiling" a base specification, but sees APs as combinations of
metadata properties from multiple sources, plus accompanying guidelines.
[ID] That's not a big difference - an IMS profile can contain profiles of different specifications tied through a profile of a base schema referencing them which can be dummy if needed. IMS profiles contain guidelines too.

2. DC makes a big deal about defining properties independently from any
particular AP, in order to make them reusable across many contexts. LOM
and IMS don't do this, but defines elements as part of the definition of
an AP.
[ID] No, IMS APs may define new elements at specified extension points, but are urged to do this only if absolutely necessary; IMS Common Cartridge will define just two new elements and take all the others from the base specs it profiles.

3. The IMS profiling seems to include things that go well beyond what DC
would call "metadata", such as Content Packages. However, some of the
information in a content package or Simple Sequencing description could
well be classified as metadata.
[ID] That's correct - and some of the recent discussions on this list indicate that the DC Edu group starts to move into considering contexts like packaging as well

4. IMS relies on XML and XML Schema for APs. DC is syntax-independent,
but with a semantics based on the RDF model. Thus, any notion of
application profiles needs to take that into consideration. This is also
discussed in [1].
[ID] As stated in [1], DC is about _machine_readable_ metadata and _system_ interoperability and that is meaningless without a concrete binding. 
But anything in the Overview document and anything before section 3.3.2 in the Technical Manual of the IMS Application profiling Guidelines at http://www.imsglobal.org/ap is intentionally independent of the binding. In fact IMS relies on UML for specifying data and generates the XML schemas increasingly from the UML, but there is, unfortunately, no technology for profiling UML specs in our sense (the concept of a UML profile means something totally different). Nevertheless, the IMS tools for profiling XML Schema Binding should work for profiling the DC XML Schema bindings as well.

> Within TELCERT we have developed open source tools to encode
> application profiles accordingly and to generate new XML schemas and
> Schematron rules for testing. You may find these at
> http://iwm.uni-koblenz.de/schemaprof/. A slightly improved version has
> been developed for IMS and can be downloaded as IMS Approved
> SchemaProf tool from the IMS web site. IMS is building a repository of
> application profiles of IMS specifications for its members. According
> to the needs of IMS we have also a profile of IEEE LOM strict
> describing unqualified Dublin Core.
> I should be glad if our technology could be of use for the Dublin Core
> and I should be grateful for any comments on specific requirements the
> DC Ed community might have. An exchange of application profiling
> experience between both educational communities might be of interest
> as well.

I'd love to hear more of your thoughts on the above points, but maybe
it's appropriate to hold that discussion on the DC-ED list? Feel free to
forward my comments there...
[ID] Thanks, Mikael, it's my pleasure and I am open to further discussions

/Mikael
> 
[1] Nilsson, M., Johnston, P., Naeve, A., Powell, A. (2006), The Future
of Learning Object Metadata Interoperability, in Koohang, A. (ed.),
Principles and Practices of the Effective Use of Learning Objects,
Informing Science Press
http://kmr.nada.kth.se/papers/SemanticWeb/FutureOfLOMI.pdf


-- 
<[log in to unmask]>

Plus a change, plus c'est la mme chose