Tod,
Please see my comments below...

>  I may be off the mark, but I get the feeling that the DCMI Registry
> phase 1 is closer to Administrative database (or VMT) than the ideal
> registry folks have been describing in this thread.

You are confused with regards to the vmt vs. registry.  The registry was not
intended to, and does not, provide VMT functionality.  The registry does
however deliver the functionality outlined in the functional requirements,
and developed thru experience with the prototypes.

> Contains stuff for the process of managing the evolution of instance
> data
> [[
>  (eg, proposal-submitter's email address), plus any additional
>  information that might be recorded about moving that proposal
>  through an approval process (eg, date submitted), as well the
>  historical archive of proposals that were rejected (which we
>  specificially would not want to put on the Web).
> ]]

Evolving the DC vocabulary is the responsibility of the Usage Board.
Reporting those decisions is the responsibility of the registry.  There are
no functional requirements for the above.  Are you requesting this
functionality be included in a future release?

> Doesn't produce RDF instance data.
> [[
> > There will be other registries (not to mention other applications)
> which
> > access the machine-readable representations of the DCMI vocabularies
> > (the "DCMI RDF schemas").
> ]]

Same as above.  There is no functional requirement for this.

> Doesn't aggregate/cooperate/extend(/extended by??) other vocabulary
> registries (I know we are just tripping over other registry
> systems left
> and right).
> [[
> > But perhaps more importantly for my argument
> > here, I believe that sooner rather than later it will be
> desirable for
> the
> > DCMI registry to be able to access/read/index/display the
> machine-readable
> > representations of vocabularies owned by other organisations.
> ]]

You are right - it does not.  This is intentional.  This decision was made
shortly after Tokyo.  I happen to agree with it.  Our goal is to promote the
use of DC, not to act as a publisher for everyone that writes schemas.

> So why not bolt on (I would think at the servlet layer) the needed
> management UI pieces (state management, internal (hidden) application
> data,...) and call it that.

If you have functional requirements I would love to hear them.  Phase 2 will
be developed based on functional requirements gathered from consensus.
Hoevever, design and implementation decisions will NOT be made by consensus.
I am sure as a developer you can appreciate my viewpoint on this.

> Second is there any plans to make the toolset available to the public
> (is this still EOR project based (i.e., can be obtain via) or is that
> bad word in the group)?

It is not eor based.  The registry is based on the Jena toolkit and uses a
PostgreSQL data store.

Regards,
Harry

> Cheers Tod...
>
>
> On Wed, 2002-09-18 at 03:29, Thomas Baker wrote:
> > On Tue, Sep 17, 2002 at 07:49:42PM +0100, Pete Johnston wrote:
> > > >However, please bear in mind that the registry is not
> about RDF.  It's
> > > about
> > > >the DC vocabulary.  We may wish to include information
> in the registry that
> > > >is not RDF related, is not in the schemas, and does not
> belong in the
> > > >schemas.
> > >
> > > I guess my problem is I'm struggling to understand what
> sort of information
> > > you have in mind here. I see Roland has just asked the
> same question! ;-)
> > >
> > > Essentially I had always been working on the basis that
> all the information
> > > input to and indexed by the registry application could
> and should be made
> > > available in an RDF-based form accessible on the Web.
> >
> > Pete, others,
> >
> > I fundamentally agree with the intention of putting things on
> > the Web in an RDF-based form but there are some grey areas
> > with regard to administrative metadata.  I believe Harry is
> > thinking of information such as the attributes in section 2.4
> > of http://dublincore.org/usage/documents/vocabulary-guidelines/
> > (eg, proposal-submitter's email address), plus any additional
> > information that might be recorded about moving that proposal
> > through an approval process (eg, date submitted), as well the
> > historical archive of proposals that were rejected (which we
> > specificially would not want to put on the Web).
> >
> > For me, the confusion lies in seeing the Registry (which I
> > think of as an information resource for the public) also as a
> > back-end administrative database for vocabulary management.
> > Perhaps we need to make a more careful distinction between
> > public data (which should be in RDF for reusability and
> > exchange) and internal administrative data (some of which
> > could be in an Oracle table).
> >
> > Where I don't follow Harry (if I have understood him
> > correctly), is in thinking that the administrative database
> > should export the public bits of its data into the public
> > registry through a purpose-built API instead of simply
> > exporting RDF.  I am assuming here, as Pete does in an earlier
> > posting, that the registry would have to be able to import RDF
> > anyway, so it's not clear to me what an extra API would add.
> >
> > Tom
> >
> > --
> > Dr. Thomas Baker
> [log in to unmask]
> > Institutszentrum Schloss Birlinghoven          mobile
> +49-171-408-5784
> > Fraunhofer-Gesellschaft                          work
> +49-30-8109-9027
> > 53754 Sankt Augustin, Germany                    fax
> +49-2241-144-1408
>