lör 2007-08-18 klockan 11:58 +0200 skrev Ingo Dahn:
> Hi, Mikael,
> 
>  
> 
> thanks for your comments, perhaps we are converging, not sure yet. At
> least the differences in the views underlying our positions are
> emerging.

I think I agree, so let me summarize instead of commenting on all points
below.

1. The notion of APs: DC itself is about APs for metadata - i.e.
combining different kinds of metadata into one metadata record.

I do not question the usefulness of using metadata together with other
things (the IMS notion of AP) - I just wanted to make clear that the two
kinds of APs - let's call them intrinsic APs and extrinsic APs, have
*very* different functional requirements. And I'm also not saying that
IMS is doing that part (extrinsic APs) somehow "wrong".

Also, I certainly think that this group, as an example, *would* be
interested in seeing the DC-ED AP be used in such "extrinsic APs". But
we need to keep the concepts separated.

So, yes, I'm talking about the case where metadata + metadata =
metadata. Not metadata + XHTML = useful webpage, or XHTML + XHTML =
website. All useful, but not what I call intrinsic APs.

Now that we've cleared that part, we can go on about "extrinsic APs". no
need to stop the discussion :-)

2. I also tend to find it problematic that some specifications do a lot
of metadata plus something else - i.e. the structural parts of IMS CP
are useful as metadata, but are too embedded in the non-metadata parts
to be easily combined with other metadata. I'd like to see a better
separation in specifications regarding what parts introduce new metadata
elements, and what parts are there for other purposes.

Also, the IMS specs could make good use of GRDDL

http://www.w3.org/TR/grddl/

i.e. as a way of extracting metadata out of "homegrown" XML languages.
I'd also like to see the IMS AP guidelines recommend this.

3. The DCAM would not be well designed to handle "extrinsic APs" - it's
simply not designed to handle that at all.

4. Regarding LOM - I think LOM suffers from a lack of consideration for
the needs of "intrinsic APs" - it doesn't handle many of the
metadata-specific requirements very well. I think LOM at the core *is* a
metadata specification, only it's not very explicit regarding the
aboutness, etc. It's fixable, though.

For example "lom/educational/description/string" and
"lom/metametadata/identifier/entry" are not "about" the same resource.
This makes machine-merging of metadata difficult - it has te be handled
manually. So for "intrinsic APs", LOM has issues.

/Mikael
> 
>  
> 
> See my comments in your text.
> 
>  
> 
> Ingo
> 
>  
> 
> -----Ursprüngliche Nachricht-----
> 
> Von: DCMI Education Community [mailto:[log in to unmask]] Im
> Auftrag von Mikael Nilsson
> 
> Gesendet: Freitag, 17. August 2007 13:20
> 
> An: [log in to unmask]
> 
> Betreff: Re: WG: Describing Application Profiles
> 
>  
> 
> 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. 
> 
> [ID] Is there any specification which does not define how to describe
> something? Though, your restriction would be valid if you request that
> the specification is _only_ about the description of something. That
> would indeed restrict the domain of interest considerably. 
> 
> E.g. the manifest of an IMS Content Package describes the type of the
> elements in a content package and a WSDL describes the interface
> communication of a service. However, these specs actually contain
> more, for example the manifest defines organizations of the manifest
> which would not be there without the manifest.
> 
>  
> 
> * Openness - i.e. metadata is not the same as a serialization of a
> fixed
> 
> set of constructs
> 
> [ID] That's too vague for me - you cannot define something by what it
> is not.
> 
> * Combinability - the aboutness gives a notion of two descriptions
> being
> 
> "about" the same thing, and therefore mergable
> 
> * etc.
> 
>  
> 
> [ID] That's a key point I need to understand and it is related to
> understanding your concept of aboutness: If you insist that the
> combination is _only_ descriptive and if you are inclined to ignore
> the further potential of data specifications, we can probably stop the
> discussion at this point - restricting it so that the combination must
> be descriptive only and even about the same thing would indeed exclude
> a lot of possibilities to combine specifications and application
> profiles into domain profiles. Instead I would prefer very much the
> more general discussion how such combinations can be done in order to
> suit the needs of real contexts which only too often require the use
> of several specifications.
> 
>  
> 
> 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.
> 
> [ID] Agreed
> 
> * It's not open in the above sense - an XHTML document is a
> 
> serialization of web page, end of story.
> 
> [ID] Agreed
> 
> * There is no natural sense of "combinations" of XHTML documents.
> 
> [ID] Oh no, it is wide-spread practice to combine them into what is
> called a web site.
> 
>  
> 
> (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.
> 
> [ID] That seems to indicate that you indeed request the result of
> combination to be descriptive only; true?
> 
>  
> 
> > 
> 
> > 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.
> 
> [ID] Yes, and that can lead to a new quality, say an XHTML description
> of a service with an RDF description of its relations with other
> services - something which, I believe, is worth a thought.
> 
>  
> 
> 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.
> 
> [ID] I am not claiming that the result should be called metadata; I am
> not even particularly interested whether it is metadata, I am only
> interested whether the combination and profiling can be done in a
> clean and useful way. Perhaps our difference is, that you are mainly
> interested in the _creation_ of metadata while I am mainly interested
> in the _use_ of metadata in combinations, considering the creation of
> metadata just as a particular case of this. I will frankly admit that
> this special case requires additional thoughts and restrictions.
> Nevertheless, the experience from the general case of domain profiling
> should be valid also for the metadata case.
> 
>  
> 
> > 
> 
> > 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. 
> 
> [ID] Agreed - see above
> 
>  
> 
> APs for
> 
> metadata have very different requirements, and the "extensibility,
> 
> modularity, refinements, multilinguality and machine-processability"
> 
> tries to capture some of that. 
> 
> [ID] Ah, I am not talking about APs _for_ metadata but about APs _of_
> metadata specs.
> 
>  
> 
> Add to that "aboutness, openness,
> 
> combinability" in the above senses, and *then* try to apply to for
> 
> example SCORM:
> 
> [ID] See comment on LOM below
> 
>  
> 
> * 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.
> 
>  
> 
> [ID] Yes, I didn't want to question the great advantage of having a
> common information model, but such a model is not in sight and we have
> to do something useful meanwhile. 
> 
> NB: From what I saw from DCAM I think it's expressive power is too
> weak to handle all the profiling cases that occur in practice outside
> Dublin Core while our AP binding should be capable to handle all the
> profiling requirements for the XML Schema Binding of DC, even in a way
> that makes it not too difficult to extract the binding independent
> parts of a profile. But that's another discussion. And we have tools.
> How far is the tool support for DCAM developed?
> 
>  
> 
> 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.
> 
> [ID] :-O So you don't consider IEEE LOM as a metadata spec? Then there
> isn't much left to be combined with DC and the whole problem may be in
> the end DC internal only, is it?
> 
> Your question is easy to answer and XPATH provides a well supported
> solution: lom/educational/description/string, put quotes around it if
> you prefer having a single identifier. Don't tell me this is too
> complex, it's for machines only and experts like we are paid to make
> that usable for humans.
> 
> And lom/general/identifier is for the aboutness in very much the same
> way as dc:identifier is.
> 
>  
> 
> > 
> 
> > 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.
> 
> [ID] They might form a potential context of use of DC, sorry if this
> is not interesting for DC.
> 
>  
> 
> > 
> 
> > 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.
> 
> [ID] We still can derive the binding independent parts from those with
> binding but you cannot create the binding specific parts. And one
> cannot seriously talk about interoperability of systems without
> initially specifying a common binding used by them.
> 
>  
> 
> > 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.
> 
> [ID] I am more moderate, I just said that the IMS tools could do
> something useful for the DC APs with XML binding - and I conjecture
> that a remarkable part of the DC implementations uses this binding. At
> the very least that could create a profiled XML schema. Can you
> indicate, how this is done with DCAM tools? I didn't claim to solve
> all problems.
> 
>  
> 
> /Mikael
> 
>  
> 
> > 
> 
> -- 
> 
> <[log in to unmask]>
> 
>  
> 
> Plus ça change, plus c'est la même chose
> 
> 
-- 
<[log in to unmask]>

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