Hi Sarah,
Just breaking this topic out into a separate thread for a second:
> OK, in my mind, following on from discussion so far, I can see three
> separate issues emergent for the question of the Learning Resource
> Class.
>
> 1. Do we need to define a Learning Resource Class at all and if we do
> what are the implications?
> - I have come round to the idea that anything anyone describes using
> one or more DC-Ed AP properties could be defined as a "learning
> resource" (although not necessarily a resource purposed *intentionally*
> as a learning resource).
> - However, my question is a technical one stemming from my own
> rudimentary understanding of what an application profile is, how an
> "application profile module" relates to this, and what a "metadata
> record" is (I put the latter in quotes as a I am aware that this
> concept is getting more fuzzy than old library thinking would have it).
> It's this: if we are essentially just saying that, in Irvin's use case
> for example, we want to support having a metadata record for a given
> resource that includes some educational properties, and if, to use our
> DC-Ed AP we *have* to then assign that resource the class "learning
> resource" - what happens to the resource's original resource class?
> Can a resource simultaneously have 2 resource classes? Remember we are
> not creating a whole new and separate metadata "record". I genuinely
> don't know the answer and am asking if someone can clarify for me. To
> clarify my thinking- I was wondering (and I know this question isn't
> solved itself) what would happen if one were using an accessibility AP
> module to add some metadata about the accessibility properties of a
> resource. Clearly this doesn't make the resource "an accessibility
> resource" - so how, within the DCAM / Singapore Framework would that be
> handled? Why is this different?
I think we need to be very careful with this notion of "application profile module". I'm sensing a tendency to use the term as if it is a well-defined part of the formalisms defined by DCMI, and even already successfully used in other contexts.
But that isn't the case at all.
Neither the Singapore Framework document [1] nor the draft Description Set Profile spec [2] make any reference to that notion. In particular, with the current draft of the DSP document, I think there has been a conscious effort to keep the model as simple as possible, while at the same time supporting some useful basic functionality.
So in the current DSP draft there is no attempt to provide for a modular approach - there's no "import" or "include" mechanism defined, for example - because specifying such things can quickly get pretty complicated (How do I "merge" data in the imported entity with existing data in the importing entity? How do I deal with overlaps/contradictions? etc etc etc)
So a DSP as currently defined is essentially a "stand-alone" entity which describes a (single) "complete" set of constraints on a DC description set. The fact that two DSPs might have some subset of constraints in common is irrelevant as far as the spec is concerned.
So, I think the short answer to your question "how, within the DCAM / Singapore Framework would [DCAP/DSP modularity] be handled?" is that the specs as they stand right now do not provide an answer to that question.
Which is not to say that we can't try to work through some of these questions within what _is_ provided by the _existing_ framework.
To avoid getting hung up on the "DCAP module" (or "DSP module") thing, I tend to think of what this initiative is doing is _not_ developing a DCAP/DSP, but rather developing a set of guidelines/recommendations for what the creators of _other_ DCAPs/DSPs might include when creating DCAPs/DSPs dealing with learning resources (or with educational characteristics of resources, or however you want to phrase it!).
And this may extend to this initiative defining appropriate terms if required, and providing statement templates (and maybe description templates) that can be copied by DSP creators.
Maybe this is hair-splitting on my part (surely not...), and it's not so far from what you are thinking anyway. But I feel it needs to be said, as I get nervous when I see this use of terms like "AP module" as if they are well-defined and part of a formal framework.
Pete
[1] http://dublincore.org/documents/2008/01/14/singapore-framework/
[2] http://dublincore.org/documents/2008/03/31/dc-dsp/
|