>
> 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.
>
> A metadata record made up of 50 LOM properties and 1 DC property is a LOM
> record that 'incorporates' qualified DC (IMHO).
Say some vocabulary has some property x, which the issuing authority
declares (legitimately) as a subProperty of a DC property y.
Then i think use of such a property in a record - assuming the declaration
is accessible to a receiving entity - allows the receiving entity savely an
interpretation of the record in DC terms by "dumbDown" of x to y.
As i understand such idea has been behind the HTML dotdot notation.
>
> > We first should say, what model DCMI has w.r.t. metadata in general.
>
> Yes, I agree that this is a possible approach. We *could* define a
>
> DCMI Abstract Metadata Model
>
> which would be broader than the model I propose.
>
> The main benefit in doing so would be if others, e.g. IEEE LOM, were to
> adopt the same model.
>
> That said, I think there's enough in the current document to allow people
> like IEEE LOM to adopt the same model if they desire and write it up as an
> IEEE LOM abstract model.
How you get the message over, that it is a gain to have subProperty/subClass relations
explicitly defined?
>
> > Then we can continue in indicating what a simple DC or qualified DC interpretation
> > of a given record should/could mean.
> >
> > Seems un-practical to me to insist on using DC vocabulary exclusively in a record -
>
> Where is this insisted? The document certainly doesn't insist on this.
ok, taken for the record.
> 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.
The problem remaines, what you should do with such a record from a DC point of
view. I don't see it covered by the model - as currently formulated.
>
> > > but it does not specify that encoding schemes are limited
> > > to those recommended by DCMI.
> > > I wasn't sure whether this was intentional or not?
>
> I think encoding schemes are different to properties. It seems fine to me
> that a qualified DC record can contain encoding schemes from external
> namespaces. It's only a gut feeling though I guess.
The problem comes in with schemes as well. Say some entity defines subClasses
of the DC Type list - then again you could "dumbDown" to a "purified"
DC record.
rs
>
> 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/
>
>
|