On Thu, 11 Sep 2003, Rachel Heery wrote:
> 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
> http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0308&L=dc-architecture&T=0&F=&S=&P=3565
>
> 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
> follows:
>
> 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."
As far as I can tell, your proposed changes still allow for my scenario
above ??
> > 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.
Well, I don't say that it doesn't exist... but I take your point.
> Is the intention to define a schema for 'pure DQ' that can be used with
> OAI-PMH?
Errr, we did that some time ago! :-)
> 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.
Sure. I don't think anyone disagrees with this. DCMI has never
discouraged this - I certainly haven't. The issue is largely around what
one calls the richer records - hence my scenario above. As I mentioned
previously, I wouldn't refer to a record like the one above (50 LOM
properties and 1 DCMI property) as a 'qualified DC record', or at least
I'd feel uncomfortable doing so - I'd refer to it as a 'metadata record
that incorporates qualified DC and LOM'.
> 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.
Well, I disagree that the current document does that - but I can see that
I'm probably in the minority, so I guess it needs to be changed.
> And, I believe, if the abstract model was more inclusive then it would be
> useful more widely.
I think there are currently three ways forward...
1) Leave the model more or less as is but extend the definition of
'qualified DC' to include external properties (i.e. my example LOM/DC
record would be labelled as being 'qualified DC').
2) Add a third section to the document called 'An abstract model for
extended DC' (i.e. we'd have three classes of records, simple, qualified
and extended - my example LOM/DC record being an example of 'extended DC')
(The notion of 'extended' comes from a separate proposal for something
called 'DCX' from the European TEL project, which some of you may not have
seen yet).
3) Re-work the document to include an 'Abstract DCMI metadata model'
(which would allow for properties from any namespace to be used) and then
define qualified and simple DC as progressively narrower instantiations of
that generic model.
Note that 'qualified DC' in option 1 and 'extended DC' in option 2 are
both open-ended in terms of the properties that can be used and therefore
(I think I'm right in saying that) they cannot be instantiated in an XML
schema. I think that this is a major problem. Can someone correct me if
I'm wrong on this.
My preference is therefore to go for 3).
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
|