Folks:

I've been reading iterations of this document for some time, and I think
great progress has been made in this version.  I do, however, have some
continuing concerns about the ambiguous use of terms in the document,
which I'd like to see addressed before this document comes out of draft
status.

The ambiguity around the use of "application" is to some extent an
inherited one, but I believe if we want to encourage the use of these
specific kinds of profiles (further than the METS and MODS communities
have, for instance, in using profiling primarily for documentation) we
need to be very specific about what we mean.  I took a look at the
definitions in wiktionary (http://en.wiktionary.org/wiki/application):

    /application (plural applications)/

    /   1. The act of applying or laying on, in a literal sense; as, the
    application of emollients to a diseased limb./
    /   2. The thing applied./

    /          He invented a new application by which blood might be
    stanched. --Johnson./

    /   3. The act of applying as a means; the employment of means to
    accomplish an end; specific use./

    /          If a right course . . . be taken with children, there
    will not be much need of the application of the common rewards and
    punishments. --Locke./

    /   4. The act of directing or referring something to a particular
    case, to discover or illustrate agreement or disagreement, fitness,
    or correspondence./

    /          I make the remark, and leave you to make the application./
    /          The application of a theory to a set of data can be
    challenging./

    /   5. (computing) A computer program or the set of software that
    the end user perceives as a single entity as a tool for a
    well-defined purpose. (Also called: application program; application
    software.)

    //   6. A verbal or written request for assistance or employment or
    admission to a school./

    /          December 31 is the deadline for MBA applications./

    /   7. (bureaucracy, law) A petition, entreaty, or other request./

    /          Their application for a deferral of the hearing was granted./

I think what we're talking about in application profiles corresponds to
3 and/or 4 above, and not 5.  However, the document sometimes slips into
talking about applications in the software sense, and that muddies the
waters considerably.  I would suggest that we define "Application" early
on in the way we want to use it specifically in this document (and other
of our documents on APs), and when talking about software applications
(such as in section 3, in the paragraph that begins with "Functional
requirements can include general goals ... ") use "software application"
or something that explicitly differentiates.

In the second paragraph in section 3, the term "foundation standards" is
used, and although this does refer to the image shown previously, I
think a parenthetical should be added that either includes RDF and RDF/S
or refers the user back to the image.  Otherwise, we risk having users
interpret the phrase more generally than intended.

In general I like the set of questions listed under "Functional
requirements answer questions such as:" but I think the second to last
bullet includes a question that needs an additional part.  I would
suggest that the last question be changed to: "How expert are they in
relation to the data your application will manage, _or the resources
that data represents_?"

In Section 5, I think we should add RDA as a prospective source of terms
in the second paragraph.  Having RDA terms available for DCAPs was one
of the prime reasons that DCMI got involved with RDA, and the relevant
properties are already registered, though not yet finalized.  Because of
that I would suggest that RDA be noted as a source that will be
available soon, and that caveat emptor apply until they are finalized.

In the fourth paragraph I find the unfamiliar notion of
"data-engineering aspects."  What does this mean?  I thought we were
trying to enable people to figure out how to do this, not scare them
off!  I would just use "aspects" here and dump the off-putting
terminology.  A little further along we encounter the phrase "metadata
engineering."  This sounds to me a result of the same sort of thinking
that uses "sanitation engineer" to describe the guys who collect garbage
(and I include women here, since I saw my first female garbage-person
just last week!)  Far more worrisome is the effect that this sort of
terminology is likely to have on newbies to this environment,
particularly librarians, who might be likely to see these terms as
boundaries around what they can be expected to tackle.  We can't afford
that if we want to see this technology proliferate--and I think that's
what these guidelines can and should do.  This is not rocket science,
and we do ourselves no favors in casting it in that manner.

Further down in the specific analyses of the terms chosen for the sample
AP, we see that the lcsh.info work seems to be recommended--and I have
some concerns with that.  This work is specifically not the official
source of LCSH, and much as I have the utmost respect for it and use it
in presentations as an example of what can (and hopefully will) be done,
we need to be really clear that this is NOT the official prime time
source of URIs for LCSH.  Not being "real" about this risks losing
credibility with the library community, which has a big stake in this
work being done officially and with care (and appropriate maintenance).
If you want to use a vocabulary that does have official URIs, I'd
suggest one of the GEM vocabularies available on the NSDL Registry
(which actually might be more appropriate for the application!).   Or
use LCSH as literals for now (or both).

I have some related concerns about the overuse of FOAF as an example for
describing people.  Yes, FOAF is useful for some things but does not
necessarily provide the range of properties that those in the library
community are looking for, and continuing to suggest that email address,
affiliation, etc. are sufficient (or even desirable, given the
maintenance issues) will, I think, provide an excuse for folks who are
used to the richer data used on traditional library authority files to
dismiss DCAPs.  I think we could say that when LC Name Authority data is
available with URIs it can be used here as well, without getting into
too much trouble.

I agree that moving some of the more technical information to the end is
helpful, but we should also be careful that we're looking at the reality
of how this data is likely to be used.  In the paragraphs at the end of
section 6, where there is a generally good discussion about creating
related descriptions for a description set, there's an assumption that
these extra descriptions will be created, managed and communicated as a
group by individuals or groups building APs.  The last sentence in that
penultimate paragraph says: "As additional descriptions are created to
hold the additional information, Description Sets can potentially become
quite complex." On he other hand, when talking about subjects (and using
lcsh.info as an example) we talk about providing a URI which gives us
access to an externally-managed description for that subject, without
necessarily the need to take on the complexity of managing that source
information.  Like our recommendation to look for terms that have been
built by others and reused, we want to strongly suggest the same
strategy, explicitly, for values.  This fits very well with how
traditional libraries view the world of data, and I hope will reassure
them that this efficiency is not lost in a DCAP world.  Many will, of
course, choose to build and maintain these descriptions on their own
(until, at least, they discover how hard it is and how interoperable it
really isn't).  Again, if we use FOAF as the only example and this
notion that everyone will need to build all the complex bits of
description sets, we risk turning off or scaring off a potentially big
part of our audience for DCAPs.

At the end of section 7 is a paragraph that includes some information
about guidance information, which uses only AACR2 as an example of
external documentation.  Again, we miss an opportunity here to include
something about RDA, which will, I hope, provide an incentive for people
to look forward, not back.  Of course, AACR2 is another legitimage
example, but please, not the only one!  At least with RDA the rules will
be linkable ... we hope (they will be technically, but how much will be
freely accessible is still not clear).

I'm really pleased to see these guidelines at this almost finished
phase, and hope that others will respond to the call for public comment,
and perhaps even respond (positively or not!) to the comments I've put
forth.

Regards,
Diane

*********************************
Diane I. Hillmann
Director of Metadata Initiatives
Information Institute of Syracuse
Email: [log in to unmask]
Voice: (607) 387-9207
Fax: (607) 387-4867
Skype: dihillmann
*********************************