Douglas,

> As for the DCMIType question, this touches on a broader
> question of how should records conformant with an AP relate
> to other "normal" DC records.
>
> I know DC elements are all completely optional, but if your
> data does have certain elements, my feeling is in "best
> practice" those elements should [also?] be available in a way
> suitable for generic DC applications [ie. those using just
> DCS/DCQ] to understand, otherwise if you want to handle
> generic DC data, you in fact need to be able to handle _all_
> the AP variants too (and they're starting to sprout up quite
> quickly now).

If you are saying that all DCAPs must use a shared
(meta-)model/framework, then I strongly agree.

If you are saying all the statements made in an instance of a DCAP must
map/"dumb-down" into statements made using properties and classes from
the DCMES and DC terms vocabularies, I strongly disagree! ;-)

That would seem to suggest that every DCAP designer either

(a) gets _all_ their terms accepted by the USage Board for inclusion in
the DC Terms vocabulary;

or

(b) limits themselves to properties/classes which are
subproperties/subclasses of existing DC properties/classes

That is an unacceptable restriction for a DCAP (IMHO!). One of the
reasons for creating a DCAP is that it allows me to extend my
descriptive capability by utilising other metadata vocabularies. I
_want_ DCAPs to be able to use properties that are not subproperties of
DC properties.

An application which "understands" only the properties in the DCMES and
DC Terms vocabularies would ignore the statements made using those
additional properties.

e.g. using a MARC relator "owner" property, I can make a statement about
resource ownership. This is a Good Thing. I can't make that statement
using properties from the DCMES or DC Terms vocabularies (N.B. ownership
does not imply "contributorship" in the sense of dc:contributor, so
marcrel:owner is not a subproperty of dc:contributor). An application
which is "aware of" only the DCMES and DC Terms vocabularies has to
ignore that statement.

> Maybe DCMI will need to look at some sort of an "AP best
> practice" or "core of cores" or "AP dumb-down" guidelines so
> APs are constructed in a way that their records "make sense"
> alongside other DC records??

It's worse than that ;-) Currently, DCMI lacks any formal
definition/model for what a DCAP is.

> Is this a DC-Arch issue??

I don't know where responsibility lies. We have touched on it in the
Abstract Model document but we stop short of extending that model to
describe a DCAP.

I guess I would like to see something in the future which builds on the
AM doc and provides a model for a DCAP.

Pete