Pete,

Sorry, I probably didn't explain it very well (probably because I
haven't got a clear picture in my head yet) so I'll give it another
go...

I guess I was thinking that APs can be seen as a way to do whatever you
like yet still say "but it's OK, look, I conform!" - kind of a cheat's
way to solve Rachel's "tension between alignment and differentiation".
I think we're still too early in our use of APs, and the resulting
records, to understand the implications of having them on the landscape.
 This is something Stu has been mentioning too.

If I have an AP that uses elements from various schemes though only
uses "dc:source" from DC, technically it conforms to DC, but that
(dc:source) isn't really much of a DC record (imho)!  What if the AP
also used an element "another:name" [from the "another" element set]
which is effectively the equivalent of dc:title - then the DC record
part in the AP could potentially have had Title and Source, which would
have made it a more "useful" record in the DC landscape.

What I mean is, APs (as we currently know them) steal elements out of
context.  While there is no such thing as a "typical" DC record, there
are [I contend] some sort of norms appearing, like if you're going to
include some typing information you will likely at least include a
dc:type value from the DCMIType vocabulary.  This is a Good Thing
because if you collect up a bunch of DC records from multiple sources,
there is likely to be at least some sort of consistency.  I know DC
doesn't require these things, but it sure makes for better resource
discovery applications!

So, maybe the DC guidelines for APs (when they emerge) could say
something like: if your AP includes an element containing data that is
"pretty darn similar" to dc:X (eg. dc:title), then you should include
dc:X in your AP, even if it means duplicating another element.  So DCMI
would say: it's OK to steal DC elements for your AP, but you can't call
it a DC-conforming AP unless it meets these requirements...?

Now you may disagree with my contention - that there are _no_ norms in
DC records.  In that case, maybe the various DCMI-endorsed APs could
establish the norms in a consistent way across all of them??

However, this is a wider issue so it shouldn't hold up the DC CD AP.
What triggered it for me was that DCMIType of Collection is implied in
the AP (in cld:CLDT), but it will never appear explicitly in any
resulting DC records that conform to the AP.  This concerns me because a
"typical" DC application shouldn't have to learn all the peculiarities
of the multiple DC APs.  Even if they did take account, they can use the
"refines" instructions in the AP to "dumb-down" the local refinements
into DC elements, but there's no equivalent information for the encoding
schemes - maybe the cld:CLDT should include "refines" instructions
too??

I know the CEN guidelines are a huge step forward, but they don't quite
fit the DCMI community's requirements yet.  I discussed this briefly
with Tom at the time but they basically had to go ahead and get
something out.  I floated the idea of a DC-AP Working Group to consider
the issues, but it needed to wait until after the CEN guidelines came
out.  Then of course I forgot about it...  :-(

Thanx,
Douglas

>>> [log in to unmask] 20/09/04 03:01:37 >>>
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