Liddy (and Stu and Rachel), it was my understanding from Rachel's
earlier post that "audience" would not be handled as a DC.Description
qualifier and that the issue had been passed to DC-Education where our
discussion of audience has been ongoing. Because of your comments,
Stu, I am sending this on to the DC-Government list as well as
DC-Education.
Liddy, your statement of our discussion of audience so far is on target
in terms of its dual nature in the education arena--i.e., a "beneficiary"
of the resource and, as you put it, someone who might "mediate
that ultimate beneficiary's access." I believe in our earlier discussions
that the latter was called "administrator". Regardless of the
names we attach to these two kinds of audience in the education
arena, we agree that they do exist and the existing metadata sets
(IEEE, GEM, EdNA, etc., etc.) capture these concepts in one way
or another. So, I am going to throw out the following proposal: We
should go to our meeting in Melbourne with an "audience" element
on the table as a _proposed_ education element (i.e., NOT a qualifier
of an existing DC element; NOT a proposed new element to the DC
15; BUT a new "auxiliary element" (as Stu calls it) in the education
arena). Anyway, here it is [brackets note that I am not wed to the
exact name of the qualifier but only to the concept]:
DCEd.Audience.[Intermediary]<==controlled vocabulary
DCEd.Audience.[Beneficiary]<==controlled vocabulary
This will allow us (here online and in Melbourne) to discuss
the merits of:
1) An auxiliary "audience" element (which could, without
qualification, support appropriate schemes);
2) Audience element qualifiers (here, "Intermediary" and
"Beneficiary" (regardless of what we actually name the
concepts in the end)); and
3) Possible DCEd-proposed value qualifiers (i.e., schemes).
At this point in time, I personally am not prepared to suggest that
DC-Education come up with controlled vocabularies (value
qualifiers). While we might try later for very general vocabularies
(or even a single vocabulary for use with both qualifiers), it is also
highly possible that specific practice communities, national bodies,
etc. will have their own formal "schemes" that need to be recognized
and expressable in DC metadata.
Stuart
----------------------------------------------------------------------------
------------
Stuart A. Sutton (206) 685-6618 (V)
University of Washington (206) 616-3152 (F)
School of Library and Information Science
Box 352930
Seattle, WA 98195-2930 [log in to unmask]
GEM http://geminfo.org (Project)
http://www.TheGateway.org
----------------------------------------------------------------------------
------------
-----Original Message-----
From: Weibel,Stu [mailto:[log in to unmask]]
Sent: Monday, December 20, 1999 5:21 AM
To: 'Rachel Heery'
Cc: [log in to unmask]; [log in to unmask]
Subject: RE: audience
Audience seems to me the perfect prototype for an auxiliary element.
There is no clear consensus on how it could or should be put into the base
15. It is of major importance to the educational sector, and I think would
also be of significance to the dc-government crowd as well?
stu
-----Original Message-----
From: Rachel Heery [mailto:[log in to unmask]]
Sent: Monday, December 20, 1999 5:53 AM
To: Liddy Nevile
Cc: [log in to unmask]
Subject: Re: audience
On Sun, 19 Dec 1999, Liddy Nevile wrote:
> I read Rachel as giving us a chance for a last call on audience (not
making
> us do something extra) = Rachel please let us know if this is how you see
> it.
Just to clarify, my previous mail was communicating the withdrawal of the
'audience' qualifier from the DC Description qualifier proposal. This
proposal is due in just about now..... and obviously discussion is still
on-going within the dc-education WG on this very area.
So I am just acknowledging that consideration of how 'audience' is dealt
with has passed to the dc-education group.
Rachel
>
> I suggest then that the DC.education troops should work towards a shared
> position on this.
>
> It seems there is general agreement about the need for a place in which to
> register some classification of the intended audiences of a
> resource/service. There is the added complication within the educational
> community that there are often two audiences - the one for whom the
resource
> is intended to have value and the one who is expected to mediate that
> ultimate beneficiary's access to the resource. In some cases, the
ultimate
> beneficiary does not ever get to see the resource as it is published on
the
> web.
>
> So have I just solved my own problem? Does education need
> DC.something.audience and DC.something.beneficiary? That is, does the
> education community not need to worry 'in particular' about where to
> classify audiences but, given what DC general adopts, does DC.education
need
> to split it to have audience and beneficiary?
>
> This is not to trivialise the problem of classification of the two kinds
of
> recipients within education - but for that issue we can work on value
> qualifiers. This is a substantial task and we, as an educational
community,
> should work hard together to find a way of specifying meaningful, useful
> values that will accommodate the needs of the discoverers.
>
> Theoretically, I like the model of a triad with teachers, students and
> materials/experiences in constant interaction. The idea that the web
> resource mediates between the student and the teacher's goal for the
> student, and that the teacher in some cases mediates between the student
and
> the teacher, makes sense to me. If all is well, the goal of those
involved
> (teacher, student and resource provider) is to advance the learning of the
> student and so I think that calling the student the beneficiary might be
> reasonable. The teacher as mediator works well for me.
>
> Liddy
>
>
>
>
>
---------------------------------------------------------------------------
Rachel Heery
UKOLN (UK Office for Library and Information Networking)
University of Bath tel: +44 (0)1225 826724
Bath, BA2 7AY, UK fax: +44 (0)1225 826838
http://www.ukoln.ac.uk/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
