Where to host OLAC schemas

[Baden Hughes]

> 1. Only mature vocabularies achieve community-wide
> acceptance, and we anticipate a slow rate of change by the
> time a vocabulary is approved at the OLAC level.  Therefore
> the updates to the schema will be infrequent. The process of
> installing a revised schema on the OLAC site would involve a
> second level of quality control, and this is appropriate for
> an OLAC tandard that many other systems depend on.

In essence, it sounds as if you're proposing an editorial review of
changes to core schemas. As with similar community based standards
initiatives, I think this is a welcome development. Certainly it should
enhance the quality of the schemas that do make it into the OLAC
standard. The next question that leads from this is "who will do this
review" ?

Additionally, some form of centralised version control would be
advantageous in this context.

> 2. Any recommendations and implementation notes pertaining to
> the vocabulary will already be posted on the OLAC site.  New
> versions of these documents may need to be created when a
> vocabulary is updated. Transferring an updated schema to the
> OLAC site does not represent a significant additional burden.

Agreed, especially if there is a documented process by which revisions
are proposed, implemented and disseminated.

> 3. When several sites host official OLAC schemas, only one of
> the sites has to be down in order for validation to be impossible.

This is probably the most significant point. If schemas developed by
individuals are encouraged it is likely that for various reasons there
may be times when the hosting site is unavailable owing to the
infrstructure choices made by individuals. Institutions have a greater
chance of providing high availability network and hardware solutions to
serve this purpose. However ... the same criticism can still be levelled
even at this approach - if all the schemas are hosted on the OLAC
server, then it also becomes a single point of failure with regard to
validation. A better approach would be to have some kind of mirroring
arrangement (this is probably beyond the scope of this list) which would
ensure that multiple sites held the authoritative version of a schema
and could be switched between as necessary.

> 4. People can see that a schema is endorsed by OLAC simply
> from its location, rather than having to inspect the XML
> schema for the OLAC metadata format.  If OLAC vocabularies
> are ever adopted into other DCMI application profiles then
> the link to OLAC is maintained.

This is the most important of the points raised IMHO. The fact that
interoperability comes for free by using this process is of community
wide benefit.

> 5. We draw a clear division between OLAC extensions and
> third-party extensions, when schemas that are approved by the
> community are put in the OLAC namespace and hosted on the OLAC site.
>
> 6. Posting material from many authors on the OLAC site
> demonstrates that building OLAC is a community effort.
> Additionally, authors of OLAC vocabularies and the associated
> schemas are able to demonstrate the impact of their work when
> they can point to their documents posted on the OLAC site.

This will serve to encourage innovation and excellence. The as third
party schemas are tested and improved, the OLAC process allows for
consensus to be formed about the adoption of such schemas into the OLAC
namespace. In other words, kudos for writing a good schema
implementation.

As a third party schema developer, this all sounds reasonable to me. Of
course, there's probably a point at which I should be following some
"best practice" in terms of schema development and promotion, but I
guess we can add that to the list of things to be done :-)

Baden