On Mon, 8 Sep 2003, Andy Powell wrote:
> If a Qualified DC metadata record can include external properties then the
> logical conclusion is that a metadata record that contains 50 IEEE LOM
> properties and 1 DC property is a Qualified DC metadata record. That
> feels non-sensical (or, at least, non-intuitive) to me.
This example assumes *any* mix of metadata drawn from properties from
arbitrary namespaces plus DC is qualified DC. This is not what I
had in mind in my original mail
where I tried to argue for the usefulness of amending the abstract model
for 'Qualified DC' to allow inclusion of (non-DC) terms that follow the
'grammatical principles' of DCMI. I suggested this could be done as
Change the third bullet to say something like:
"Wherever possible existing DCMI elements or element refinements should be
used to describe properties."
And possibly add a bullet along the lines of:
"Local (novel? non-DCMI?) terms should follow DCMI conventions as regards
relationships between terms i.e. properties should be expressed as
elements or element refinements with no nesting or grouping."
> The only restriction is on what a metadata record labelled 'qualified DC'
> looks like. The document explicitly acknowledges that most real-world
> applications are not 'pure' qualified DC.
I think it would be helpful to be explicit in the document as to why you
are trying to define an abstract model for structured 'pure DQ' metadata
that (as you have acknowledged) does not seem to exist in the real world.
Is the intention to define a schema for 'pure DQ' that can be used with
OAI-PMH? I have been party to various discussions recently that have
emphasised a requirement for encouraging richer metadata to be exchanged
within the OAI context - especially as the 'metadata workflow' is not
easily predicatable in OAI distributed networks where service providers
are often in turn data providers.
Given this I would hope that the DQ model would not itself encourage
non-DC metadata to be excluded from data exchange, at least where there
is a shared underlying data model.
And, I believe, if the abstract model was more inclusive then it would be
useful more widely.
University of Bath tel: +44 (0)1225 826724
Bath, BA2 7AY, UK fax: +44 (0)1225 826838