DC Registry Working Group report
October 16, DC2002, Florence

Chairs: Harry Wagner, Rachel Heery

The DC Registry working group had a well attended meeting at DC2002 in
Florence. The overall aim of the meeting was to give an overview of the
past year's work and to look ahead to plan work for the next year.

The two main highlights over the last year were the release of the Phase
One version of the registry (see
http://dublincore.org/dcregistry/index.html) and the impressive range of
translations contributed from athe DCMI community world-wide.

The Registry Phase One release is a server-side Java Application which
takes RDF schemas and XML files for input. It is based on the Jena toolkit
and uses a PostgreSql Database. The User Interface translations are
managed with Java Resource Bundles. The output is in XML which is
transformed into XHTML using XSLT.

The Registry WG worked closely with the Internationalisation WG prior to
release of Phase One in order to build up the multilingual aspect of the
Registry. Harry collaborated with forty-one translators, resulting in
twenty three sets of 'term translations', and eighteen translations of the
User Interface. It is important to note that the term translations have
not gone through any approval process, indeed no such process has yet been
established. This was the subject of some discussion at the meeting and at
the Advisory Board later in the week.

Requirements for Phase 2 Registry
---------------------------------

The WG meeting then moved on to consider requirements for the Phase 2
release of the Registry. Harry  presented some ideas which had been
gathered prior to the meeting:

- Add interface between the proposed Vocabulary Management Tool
(VMT) and the Registry, this will output 'additional' information
from the VMT to the Registry in an automated way, making updates
more timely and accurate. The VMT itself should be complete
November 2002.

- Add interface to other registries

- Improve the User Interface as regards
        - scheme support
        - limit searches to a user specified preference language
        - separation of interface style
        - additional translations
        - display of disclaimer

Requirements gathering from audience
------------------------------------
There was then some discussion amongst several of the participants who
identified a number of other requirements:

- How might user applications get notification of changes to terms? Is
this something registry could provide in an automated fashion? There needs
to be some form of alerting service to ensure user applications based on
DCMI schema are able to either automatically update their schema, or
identify that schema updates have been issued. Also there is a need for
alerting when new languages of translation have been registered, or when
translations are changed. Though how will alerting and versioning work
with translations if they are held in a distributed way. Possibly alerts
would also be useful when new schemes are registered?
Some options were discussed briefly:

        - register with change notification tool, alert by e-mail
        - use dc-registry mailing lists
        - role for RSS newsfeeds?

Further discussion considered whether an application needed to know
specific changes or just that there had been a change in the schema. Is
the requirement on change to  'get schema' or 'get element'?  There was
some interest in where applications get new schemas from, whether it would
be from the Registry or by resolving the URL.

-       Is there a requirement for all the information from the VMT to go
into the schema (and registry) including versioning? If so there needs to
be query mechanism to ask for the latest version of elements, changes from
certain date and such like.

- There was discussion as to whether it would be possible to have all data
in the registry available via HTTP GET. Data is available via HTTP except
the translations but their availability as schemas requires a number of
issues to be resolved. It was accepted that translations could be very
valuable for various applications.

-       How well is the registry linked in to RDF Core WG? How are changes
to RDFS incorporated into the schemas on which the registry is based? At
this point it was noted that the DCMI schemas are the responsibility of
the DC Architecture WG.

-       Useful expertise in creating schemas could usefully be shared with
wider community. How might this be done?

-       Should the registry provide support for the creation of
distributed language schemas? In which case some form of schema creation
tool would be needed.

-       It might be worth exploring the possibility of deploying the
registry within an agent environment. Redfoot has a primitive notion of
peer to peer. Ambition would be to have DC deployed in peer to peer
network based on RDF.

-       Need to link within registry to usage guidelines, to give best
practice for creating instance metadata.

-       Basic help required e.g. what is a registry for? Few people in
audience had used the registry.

Work programme for next year
---------------------------

1.      Confirm requirements for Phase Two release of Registry
        -       RH to lead discussion on mailing list
        -       January 2003

2.      Prioritise requirements
        -       RH to propose to mailing list
        -       February 2003

3.      Phase Two release of Registry
        -       HW
        -       September 2003

4.      Improve user documentation
        -       RH/HW to lead
        -       May 2003

5.      Liaise with Internationalisation WG to update statement of
objectives
        -       HW, date to be discussed with Internationalisation WG


---------------------------------------------------------------------------
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/