On Fri, 15 Aug 2003 22:04:47 +0100, Andy Powell <[log in to unmask]> wrote:

>On Fri, 15 Aug 2003, Pete Johnston wrote:
>
>> http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/2003-08-12/
>
>Sorry Pete, I have a few comments on this.

OK... ;-)

>cld:accessControl
>Shouldn't we now be using the recommended dcterms:accessRights for this?

Probably! I had this down as sort of an "open issue", at the end of

http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0308&L=dc-
collections&T=0&F=&S=&P=1873

as Ann made some comments on the rights/licensing issues here

http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0308&L=dc-
collections&T=0&F=&S=&P=177

suggesting we need cld:accessControl, dc:rights and dcterms:accessRights, and
none of us had followed that up yet.

Also I'm conscious of the related discussions elsewhere

http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0308&L=dc-
architecture&D=1&T=0&O=D&P=1452

where I think (Creative Commons) cc:license is used for the function Ann
suggested for dcterms:accessRights.

>I think that the definitions of collector and owner should use wording
>that echoes the current definitions of creator, publisher and contributor
>- i.e. along the lines of
>
>An entity that has legal possession of the collection.
>
>This leaves us in line with other elements and is more in keeping with the
>flexible usage allowed by the abstract model.

OK. I've created

http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/2003-08-25/

and

http://www.ukoln.ac.uk/metadata/dcmi/collection-application-profile/2003-08-25/

which incorporate Andy's two suggested changes. I'm not sure whether we should
also consider including cc:license as a separate property.

Maybe this area is one we can discuss further in Seattle as it sounds as if the
rights issues will be on the agenda in some form there anyway?

>For each of the properties currently listed as being in the cld namespace
>I think we should ask "Is this property applicable to all resources, and
>is it useful for general resource discovery?".  My suspicion is that the
>answer in most cases will be "yes, yes" (though not in the case of, say,
>accrualStatus).
>
>Where the answer is "yes, yes" it seems to me that we have a candidate
>property for the dcterms namespace?
>
>I wouldn't want us to invent cld:agentName only to find that in a few
>months time this is actually useful for lots of resources, not just
>collections??
>
>On the other hand, it may be that the usage board will take a dim view of
>us proposing lots of new terms for the dcterms namespace, just because
>they are useful for collections and on the off chance that someone might
>want to use them more widely??

There are a number of "policy" issues here I'm a little unsure about, which I
guess we need some guidance from Usage Board on (hi Andy, change that hat!)

First, I must admit I'm not completely sure what we should be proposing
regarding the URIs for the "new" terms in this profile.

At the moment (for better or worse) the terms with prefix cld (in the summary
document) or rslpcd (in the AP document) refer explicitly to the terms defined
by the RSLP CD schema. These have URIs beginning

http://purl.org/rslp/terms#

i.e. the profile (re)uses properties "in the 'RSLP terms' namespace", rather
than defining a new set of properties with a new set of URIs.

If it's preferable/acceptable/desirable to define a new set of properties with
DCMI URIs, then we can do that. But (as Andy suggests above), it seems unlikely
to me that _all_ of these properties are candidates for the "dcterms
namespace":

- Some properties are specific to collections.
Actually we may be able to make a distinction between a subset that are
inherently specific to collections (accrualStatus, accumulationDateRange,
contentsDateRange(?), strength(?)) and a subset that as _presently_ defined are
specific to collections, but the definition could be made more generic
(agentName, legalStatus, custodialHistory, owner, hasDescription/isDescriptionOf
(?), hasLocation(?)). In the case of agentName, there's potentially an overlap
with the work of another DCMI WG, and we'd need to liaise on a coherent
proposal to UB?

- Some properties are not useful for general resource discovery

And there just seem to be a lot of properties, which in itself may be a barrier
to their acceptance as dcterms properties.

So it seems almost certain that we'll have _some_ properties that we want to
use as part of the profile but that aren't accepted for the dcterms namespace.
Do we continue to use the existing RSLP URIs for these terms or do we coin URIs
specific to this application?

Pete