Karen:

I think we have to anticipate what kinds of questions we will have from
the major constituencies for this work, and seek to address them
pro-actively.  And yes, this is certainly a work in progress so we
needn't (I believe) forego discussion of developments in the world at
large which will affect the way APs will be built, and in fact including
that information will assist people in planning.  What we don't want to
do is ignore these developments in our search for purity, and risk being
dismissed as useless because we don't seem to understand the needs of
large swaths of our community.  DCMI has long been dismissed in that way
because of basic misunderstanding by the world of what we're trying to
do--let's not encourage that.

>
>
>     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):
>
>     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 agree that we need to decide what we mean by "application profile"
> and define it early on in the document; I'm just not sure that we
> currently have an agreement on its meaning. This from the Singapore
> Framework:
>
> "The Singapore Framework for Dublin Core Application Profiles is a
> framework for designing metadata applications for maximum
> interoperability and for documenting such applications for maximum
> reusability."
>
> and this from wikipedia:
>
> "In computer science, an application profile is a set of metadata
> elements, policies, and guidelines defined for a particular application."
>
> Neither of these clarifies the term "application." If it is decided
> that APs do not refer specifically to software, then we can insert
> "software applications" when that is what we mean. (Maybe it would be
> good to do that anyway?)
>
It would certainly be good to say "software applications" if that's what
we mean.  I think, though, that by not specifying that we don't mean
"software application" when we say "application" we run the risk of
readers assuming that "application" means "software application."  We
shouldn't assume that people understand what "application" means if we
don't tell them explicitly.  The number of definitions I found suggests
that in itself.
>
>
>     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.
>
>
> ...snip ...
>
>
>
>     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.
>
>
> For both of these comments, my feeling was that members of the review
> committee were only comfortable with the use of RDF-compliant
> properties in the examples. This leaves us with a very small set of
> metadata to choose from in the document -- essentially, dcterms and
> foaf. Since one of the points of the DCAP is that only properties that
> are RDF and DCAM compliant can be used, it could be confusing then to
> use non-compliant properties in the examples. I agree that neither
> dcterms nor foaf are suitable for library applications, but the DCAP
> is not just about library applications, is it?
>
Yes, I agree that we shouldn't suggest the use of properties that are
not RDF-compliant, but given the paucity of currently available
properties I think that the notion that there are over 300 coming down
the pike might be of interest to most people (even outside libraries).
Same with names and subjects--people can use the values as literals
until LC manages to complete the work of making them available with
URIs.  Lots of people don't know that work is in progress, and given
that a number of folks are still in planning stages they may want to
consider options that we know are in progress and may be available to
them as them move through the stages.

And no, the DCAP is not just about library applications but a large
proportion of the folks actually interested in DCAPs are from libraries
and other cultural institutions.  The fact that the Library AP was one
of the first to be developed speaks to that strong interest, and I think
we should actively fan the flame of that interest.
> Considering this a "living document," would your concern be lessened
> with some comments in the text regarding upcoming developments, like
> registered RDA properties? The problem, of course, about talking about
> the future in a document is that you really must update the document
> as that future happens.
>
>
That's all I'm asking for, that we not put blinders on in regards to
these developments and risk being considered irrelevant by those who
could really benefit from understanding where this work fits into the
larger world.  And of course we're going to have to update the document
"as the future happens"--do you really think this would be the last word
even without the discussion of what's coming down the pike?  Oy.
>
>
>     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).
>
>
> At the moment, I wouldn't know what to cite as "RDA" -- the JSC
> development site is incomplete, and the online site hasn't been
> announced yet. Perhaps we can put a stub in and add the link when we
> have something to link to?
>
Online is supposed to be up this week, so a citation to that should be
possible quite soon.

Diane