Hi
I went through the UKCMF and I think this is very sensible and
useful as in the end, one always has to make a decision
about the choice of elements for searching, interface etc.
For what it is worth, I checked the choice of UKCMF mandatory
elements against search scenarios we created for evaluation of
the EASEL project search gateway (project is complete and
what I am describing here was a team effort).
LearningResourceType was found to be very useful. Its importance
depends upon granularity of a collection. However, when looking for
resources, one wants to differentiate things like exercise, exam,
image, slide etc. All metadata schemas in our project used LOM
vocabulary for this element and that paid off rather well.
However, I can't resist mentioning that this vocabulary is in
desparate need of improvement (it is based on mixed critera:
type by function, type by form, type by perception).
I can confirm what is already anticipated in UKCMF:
a language element is very useful and in our case was
often used in search criteria (EASEL being a European project).
Learning resources in humanities would also need this and
it is good to have it in UKCMF.
The format element proved useful as search criteria and was
important to exclude and include in searching resources
such as video, images, pdf, ppt etc.
A few digressions and practical issues:
Title: it has to be mandatory but is absolutely useless for
anything apart from display purposes and even then it does
not help. It does not work without specific subtitles. One
gets hundreds of resources with the same title,
e.g. three screens of 'Introduction to database blah blah'
Not to mention that an alphabetical display separates titles
one would like to see together
e.g. SQL is separated from Structured Query Language...
The title is far too unspecific in learning material collections.
Users (teachers and students) should be discouraged relying
upon this.
Author: useless in learning resource discovery; every teacher
is an author. Too unspecific, a constant source of frustration,
never knowing whether J Smith is the same as J C Smith or
J. Carl Smith or J Conrad Smith or John Smith.
(how many of us have the time to create a name authority file
or VCard in a proper way?). Many resources are created by
corporate bodies, or authors are anonymous. I would not put
it as mandatory.
CLASSIFICATION/PURPOSE/DISCIPLINE/TAXONPATH
I was glad to see this in list of mandatory elements
Some implementors in the EASEL project used classification,
and this was accommodated quite well in
classification/purpose/discipline/taxonpath
(not so in DCEd)
<classification>
<purpose>discipline</purpose>
<taxonpath>
<source>UDC</source>
<taxon>
<id>004.6</id>
<entry>Database</entry>
</taxon>
<taxon>
<id>004.65</id>
<entry>Database management system (DBMS)</entry>
</taxon>
<taxon>
<id>004.651</id>
<entry>Database file organization</entry>
</taxon>
<taxon>
<id>004.651.4</id>
<entry>Tree structure organization</entry>
</taxon>
</taxonpath>
</classification>
(Giunti, EASEL partner from Italy, did something like this
in IMS if I remember correctly)
We also used classification scheme to help with choice of keywords,
so they were not as unpredictable as one may expect and also to
decide whether to use more or less specific term.
However, EASEL project eventually failed to make proper use of
classification for browsing as the project did not have the time or
resources to do it in a Z gateway. Jan Grant from ILRT pulled a bit
of this into an RDF search gateway to browse, broaden and narrow
the hit list.
I would, personally, be glad to hear if someone went further
than this with browsing.
Aida Slavic
SLAIS, University College London
-----Original Message-----
From: The CETIS Metadata Special Interest Group
[mailto:[log in to unmask]]On Behalf Of Andy Powell
Sent: 21 February 2003 16:45
To: [log in to unmask]
Subject: General comments on the UKCMF
The UKCMF document is a really useful piece of work and helps to focus
thinking on which bits of LOM are important to us. I have sent some
specific comments on the text of the document to Gerry and Lorna
separately. What follows is some discussion about the general aims behind
developing a UKCMF - i.e. what are we trying to achieve with this? I'm
sending this more widely because I think it is important to have a shared
understanding of why this work is important and what it will be used to
support. Comments on (and rejections of) this message are very welcome!
This work seems to have taken the approach of looking at what other people
have already defined as their 'application profiles' of LOM and trying to
extrapolate from that a view of the most commonly used elements.
Apologies to the authors if this seriously misrepresents the work they
have done. I can understand the rationale behind this approach - but it
is premised on the notion that other people will have the same functional
requirements as we do, and that therefore their choices of elements in the
application profile will be the same as ours?
An 'alternative' approach would be to enumerate our own functional
requirements (what kinds of services do we want to deliver based on this
metadata), then use that as the basis for deciding what elements we need.
Finally, we could compare our results with what other people have come up
with and deal with any obvious anomalies.
I think our functional requirements can be stated very briefly, as follows:
We MUST be able to support:
- keyword searches (based on title, description and keywords in the
metadata)
- title searches (find resources with known titles)
- author searches (find resources by known authors)
We MUST be able to filter the results of those searches based on
- the publisher (only display resources published by the University of
Bath)
- the resource language (only display stuff in English)
- any platform requirements (only display stuff that runs on a Mac)
- educational level (only display stuff that is appropriate for use
in FE)
When resource descriptions are displayed, we MUST be able to show
- copyright info
- resource type
in addition to title, author, publisher, keywords and description.
It is also HIGHLY DESIRABLE that we can offer browse interfaces based on
- subject classification
- publisher
- educational level
I know that people may disagree with details in these functional
requirements - the point is that we should be able to write down fairly
easily what it is we are trying to support with the metadata in the UKCMF.
Having identified our functional requirements we can then look at the
metadata elements that we need to support those requirements. If we take
a look at the current list of mandatory elements in the proposed UKCMF we
see
- identifier
- title
- language
- description
- publisher
- format
- locator
- copyright
(apologies if I missed something). I suggest that these elements do not
support the functional requirements above. Consequently, I think we also
need to add
- general.keywords
- educational.context
- author
- learningresourcetype
- otherplatformrequirements (or 4.4.requirement)
as mandatory elements. Then we can support all the MUST functionality
outlined above. By also adding
- classification
we can also support the HIGHLY DESIRABLE functionality (provided we can
agree a way of using subject classification schemes!).
Hope this helps.
One interesting feature of the list of elements above is that all of them
apart from educational.context and otherplatformrequirements map directly
to DC elements - this is very good news I think, and makes
interoperability between 'elearning' systems and 'information' systems
much more straight-forward.
Regards,
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
|