Colleagues

The Scottish Collections Network (SCONE) CLD schema treats these as three
separate attributes (of the relationship Collects between the entities Agent
Collector and Collection, following Heaney's E-R model) so I support the
proposal.

I also support the idea of looking at values for these attributes in more
detail.

Accrual policy is probably ok with the existing 4 values. They are mutually
exclusive, so only one instance is required (in the SCONE schema, anyway).

Accrual method may be slightly more complicated, as it possible to have a
collection deposited for a fixed time through a bequest, after which it
reverts to a new owner identified in the bequest. A single value is
inadequate to describe this situation, so hybrid values may need to be
added.  Alternatively, it may be possible to use sequential multiple
instances; e.g. bequest, then deposit.

Accrual periodicity is interesting. Sarah's suggestion exposes an
observation made by Heaney that a serial is a type of collection (of parts,
which in turn are a collection of articles), and serials cataloguing has
established methods for recording periodicity or frequency. It might be
possible to use an existing standard for the content of this attribute
(which would require the addition of a value for no periodicity/frequency -
implicitly excluded for an actual serial).

Gordon Dunsire
Depute Director
Centre for Digital Library Research
Livingstone Tower
Strathclyde University
t: 0141 548 4680
f: 0141 552 5330
e: [log in to unmask]


-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]]On Behalf Of Ann Chapman
Sent: 14 July 2004 12:19
To: [log in to unmask]
Subject: Re: Comments: accrualStatus


Recent experience working on the Tap into Bath demonstrator project
supports Sarah's comment that there are three separate types of
information we are trying to include.

I would therefore support Sarah's proposal.

Ann Chapman
Collection Description Focus
UKOLN, Unviersity of Bath, Bath BA2 7AY

-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Pete Johnston
Sent: 14 July 2004 11:05
To: [log in to unmask]
Subject: Re: Comments: accrualStatus


Any more comments on Sarah's proposal please?

I'd like to produce a new draft of the DC CD AP document by, say, early
next week, so that we can clarify what proposals we are drawing up for
the Usage Board meeting in October, and this is one of the changes we
could include.

I've had one supportive comment off-list, and there have been no
negative comments here, but if there are murmurings of assent out there
it would be good to see them on the list ;-)

It is important when it comes to Usage Board considering our proposals
(and indeed when we are pointing others at this work) that we can point
to a history of engagement/support on the mailing list - even if it's
just "Yes, I agree".

Thanks
Pete

-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Sarah L. Shreeves
Sent: 28 June 2004 21:26
To: [log in to unmask]
Subject: Comments: accrualStatus


Hello all--

In response to Pete's call for proposals to bring before the usage
board, I thought I'd bring up cld:accrualStatus.  Right now the
Application Profile defines accrualStatus as:


A statement of accrual policy (closed, passive, active,
partial/selective), accrual method (purchase, deposit)) and accrual
periodicity (closed, irregular, periodic). This element has always
struck me as too packed, i.e. this one element is supposed to cover
three slightly different things. I've wondered whether we need to unpack
this a bit and actually have three distinct elements (the definitions
probably need some work):

accrualPolicy: A statement of the policy for adding items to the
collection (closed, passive, active, selective)
accrualMethod: A statement of how items are added to the collection
(purchase, gifted, deposit, etc)
accrualPeriodicity: A statement of how often items are added to the
collection (closed, irregular, daily, weekly, etc)

It seems to me that going this route would allow less ambiguous values
for each element - which would be a good thing for both humans and
potentially machines.

It also seems that accrualMethod (if the definition is tweaked) could be
applied to resources other than just collections, though I don't know
that it's a much needed element.

Thoughts? Comments?

Sarah


------------------------------------------------------------------------
-----------------------
Sarah L. Shreeves
Visiting Project Coordinator, IMLS Digital Collections and Content
University of Illinois Library at Urbana-Champaign
Phone: 217-244-7809
Fax: 217-244-7764
Email: [log in to unmask]
Web: http://imlsdcc.grainger.uiuc.edu