tor 2007-08-16 klockan 19:55 +0200 skrev Ingo Dahn:
> 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.

Actually, I tend to disagree :-)

The "aboutness" of metadata is, in my eyes, essential to the argument.
Of course metadata is data too, but to me it's not *just* data - it has
some important characteristics that makes the requirements for
representation that differentiates it significantly from other data.
Some of these characteristics are:

* Aboutness - i.e. metadata is used for descriptive purposes. 
* Openness - i.e. metadata is not the same as a serialization of a fixed
set of constructs
* Combinability - the aboutness gives a notion of two descriptions being
"about" the same thing, and therefore mergable
* etc.

Compare this with, for example, an XHTML document:

* It's not "about" something else than itself - the data is there to
describe the document itself.
* It's not open in the above sense - an XHTML document is a
serialization of web page, end of story.
* There is no natural sense of "combinations" of XHTML documents.

(I need to expand the above list, that was a fun experiment)

The arguments in [1] rely heavily on features like the above. Perhaps
that should have been made more explicit. Time for a new paper :-)

That also means that combining metadata specifications leads to a
different set of problems of you want to preserve the above features in
a meaningful way.

> 
> 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.

I stand by the analogy. As a related example - I see no problem in, say,
combining and XHTML document with RDF metadata (there are many methods
for doing that). The result is nothing more than a combination of two
things - an XHTML document and an RDF description.

However, claiming that the combination can still be called a metadata
format is completely missing the mark. It's *two* formats, each one
useful in isolation, and the combination may also carry some meaning,
but the combination lacks important features of a metadata format.

> 
> 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.

And I don't argue that that is not useful or possible, just that you're
not doing application profiling of what I would call metadata. APs for
metadata have very different requirements, and the "extensibility,
modularity, refinements, multilinguality and machine-processability"
tries to capture some of that. Add to that "aboutness, openness,
combinability" in the above senses, and *then* try to apply to for
example SCORM:

* extensibility: yes
* modularity: some, though the lack of URIs and AP-independent
declaration of elements create issues
* refinements: no
* multilinguality: yes
* machine-processability: yes
* aboutness: only in parts
* openness: not in the above sense - SCORM *is* a serialization.
* combinability: not in any general sense

etc
> 
> 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.

If you think of an IMS profile as combining "blobs" from different
specs, that's still very different from what DC does. and remember that
DC deals with metadata in the above sense.

Something to consider: what I want an AP that combines FOAF properties
with LOM metadata in an ePrints context (i.e., FRBR-based)? That is
quickly becoming a reasonable scenario.

DC metadata handles that with *one* processor that can handle DCAM
constructs. APs in your sense would need one FOAF processor, one LOM
processor and one ePrints processor, and then some red tape to glue the
three together to make sure references between them were synced. On top
of that you need a processor that deals with the AP as a whole, handling
the red tape and the splitting.

A common abstract model solves that for you. No red tape.

Guidelines: of course, I wasn't suggesting that IMS does not have
them :-)

> 
> 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.

Well, but I'm talking about not the specs as a whole, but their
components. LOM itself has this issue.

How do I reuse just, say, educational description from LOM? There's no
URI for it, and the XML element name is ambiguous. And if I *do* reuse
it, how do I know what resource it applies to ("aboutness" again)? etc.

> 
> 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

I'd say that's only true to the extent that the information can be
considered metadata in the above sense. Several IMS specs go beyond the
above definition, and so would not be interesting for DC, I think.

> 
> 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. 

DC does have that, of course. But vocabularies, elements and APs are
defined syntax-independently with a common semantics.

> 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).

That's a good development. Note that using UML does not automatically
lead to syntax-independence. I've seen a number of cases elsewhere where
the modeling was in UML, but all the modeling patterns were so closely
based on XML that implementations using other technologies was made
extremely difficult. Using UML also is no guarantee that combining
specifications works well, if the basic modelling patterns are very
different. 

>  Nevertheless, the IMS tools for profiling XML Schema Binding should
> work for profiling the DC XML Schema bindings as well.

Right, but would not work for DC in RDF or DC in HTML, and would likely
rely on XML-specific features that are not translatable to other
formalisms. I've seen that happen as well, UML or no UML.

/Mikael

> 
-- 
<[log in to unmask]>

Plus ça change, plus c'est la même chose