As I outlined in a recent mail after discussion with Harry I agreed to
consider the functional requirements of the registry in more detail. We
need to think about the requirements of different user groups. There are a
variety of sorts of user, I would characterise these as
- information seekers : those looking for up to date information on the
semantics of DCMI terms. these might typically be metadata creators,
information specialists implementing new systems and looking for
appropriate terms for their schemas, librarians, etc
- computer specialists : developers using RDF/XML, software engineers etc
- applications : software using the regsitry to navigate information about
DCMI terms
- administrator : to add, edit and delete entries
The requirements for each group will be different. I am concerned that we
provide a user friendly interface for 'information seekers' in order to
demo the registry and get useful feedback. This user group is assumed to
have no working knowledge of RDF and will want to approach the data in the
registry using more accessible terminology. As in past DCMI practice where
possible it would seem appropriate to follow ISO 11179 recommendations for
terminology.
I have started to make a 'first stab' at defining information seeker
functionality. Warning: this is very much work in progress. i have
circulated the document at an early stage to elicit comment and offers of
help from WG members!
The document is available at
http://www.ukoln.ac.uk/~lisrmh/DCMI-registry/funreq-20010819.html
In particular I would welcome volunteers to elaborate
- functionality required by 'RDF experts'. I am rather assuming this might
be very similar to what is there now OR same functionality as for
information seekers but by-passing any XSLT re-labelling of
properties/classes and ensuring transparency of any 'canned seearches'.
- functionality required by software. I hope that the registry will be
able to 'add value' to a straight 'HTTP GET schema URI'. Presumably there
would be functionality concerned with multi-lingual context. But also the
added 'richness' from additional information expressed by means of EOR
schemas. So EOR schema vocabulary might enable additional comment
to be associated with terms over and above that expressible by RDFS...
Such functionality might be associated with a particular application such
as a metadata creation tool, or a 'metadata-aware' harvester.
Any volunteers to flesh out these sections of the document??
Anyway.... please have a look and think about any issues. and forgive the
preliminary nature of the document. I will continue to work on it!
I wanted to get something out quickly as basis for Harry to work on...
Rachel
---------------------------------------------------------------------------
Rachel Heery
UKOLN
University of Bath tel: +44 (0)1225 826724
Bath, BA2 7AY, UK fax: +44 (0)1225 826838
http://www.ukoln.ac.uk/
|
