On Sat, 14 Jul 2007, Mikael Nilsson wrote:
> I am in the process of fleshing out a description of such a DSP model,
> based on discussions between me, Pete, Andy and Tom and others. The
> draft I'm working on is available here:
>
> http://dublincore.org/architecturewiki/DescriptionSetProfile
>
> This is still a *very* rough and incomplete draft, but I wanted to get
> it out for comment as early as possible.
Thanks for circulating this draft. It's a welcome step towards gaining
consensus on how to express an application profile, in particular welcome
progress towards a 'machine actionable' expression of an application
profile.
It's a bit difficult to get a full understanding of the direction of your
thoughts at this stage of the draft, but I hope the following comments
will be useful. Having spent quite a lot of time discussing 'application
profiles' my approach may be somewhat 'entrenched' but that might be
useful wrt highlighting areas that might need further explanation!
Description Sets:
I note that the draft considers profiling Description Sets as the starting
point. Whilst I see the logic of this, my impression is that 'description
sets', as opposed to 'descriptions', are not widely understood. I think it
would be useful to give some narrative and explanation (as well as
example) of a 'description set' containing one description e.g. Simple DC
and compare with description set containing multiple descriptions.
Section 4 Templates:
I am a little confused by the use of 'templates' as entities within the
'information model'. To have a 'template' as part of a 'model' does not
seem quite right to me. A template implies an expression of structured
data to me, in the DSP spec a 'template' appears to be a 'container'. It
seems more comfortable to me to think of 'constraints' relating directly
to statements and descriptions, and perhaps for the entities in the model
to be 'description profile' and 'statement profile' rather than
'description template' and 'statement template'?
Section 5 Basic semantics - Binding of descriptions to description
templates:
It is not obvious to me that each description must be bound to only one
description template (I assume that is what 'exactly one' means?!). I
think an instance of a record might match more than one description
template (and/or DSP)? In practical terms a repository holding image
resources might export records in such a way that the descriptions in the
records match both a Descripion Template for educational resources and a
Description Template for cultural heritage resources??
Section 6.1 Constraining the resource :
I don't quite get the point here. Typically DCMI APs specify constraints
for descriptions of classes of resources (say government documents,
educational resources etc, although Simple DC is often characterised as a
DCMI AP and that does not quite fit that pattern). Is the idea to state
the 'class of resource' in the DSP? what form would this take for DCMI
profiles? It would be helpful to have an example of a DCMI AP (say for
educational resources) within the draft to illustrate how this would be
done. btw the Simple DC example in section 11 does not seem to have a
'resource constraint', is that deliberate?
Oh, and I don't understand the purpose of 'standalone' in section 7.2.
but I think I better stop at this point and perhaps wait for the next
draft to get a fuller understanding!
Minor point, in 7.4 I think 'statement' should read 'description'.
Best wishes,
Rachel
---------------------------------------------------------------------------
Rachel Heery
UKOLN, University of Bath tel: +44 (0)1225 386724
http://www.ukoln.ac.uk
|