innovation in metadata design, implementation & best practices

Title: "DCX" - DCMI as a Namespace Host
Identifier: http://dublincore.org/usage/meetings/2004/10/ISSUES/dcx/
See also: http://dublincore.org/usage/meetings/2004/10/ISSUES/
Created: 2004-09-14
Agenda frozen: 2004-10-02 07:25, Saturday
Archived: 2004-11-10
Maintainer: Tom Baker
Note: If any of the links below are broken, please refer to 
                   the meeting packet
                   (http://dublincore.org/usage/meetings/2004/10/Meeting-packet.pdf) 
                   for copies of the key documents discussed at the meeting.

The Usage Board has several times -- most notably in Bath in
May 2002 -- circled around the notion of creating a namespace
where users can "park" new or experimental terms without
going through a formal approval process. The underlying
idea is to make new or experimental terms citable (by URI),
thus supporting a less "bureaucratic", more bottom-up,
market-driven approach to creating new terms.

However, numerous problems with this approach have been
discussed, for example: If terms from an experimental namespace
were eventually to be approved by the DCMI Usage Board,
would the term receive an additional URI in a DCMI Namespace,
or would the Usage Board confer DCMI status on the existing
URI in the experimental namespace? Assuming maintenance
responsibility were to reside initially with the proposers of
a term, at what point and under what circumstances would that
responsibility revert to DCMI and the Usage Board? To what
extent would the existing DCMI Namespace Policy extend to
such an experimental namespace? What responsibility would
DCMI bear to ensure, at a minimum, that terms in the namespace
conform to DCMI grammatical principles?

The Usage Board has always circled back to the notion that
in the end, terms must be maintained, and it should always be
clear who is maintaining the terms -- at any rate for all terms
which have or could be perceived to have branding by DCMI.
The UB has hitherto always reaffirmed the conservative course
of managing a small and slowly growing vocabulary of terms
in accordance with reasonably strict policies, processes,
and principles.

The idea of an experimental namespace has surfaced more
recently on the DC-COLLECTIONS list, where Theo van Veen has
proposed a "DCX Namespace", which seems like a good handle
for this idea in general. A digest of the relevant postings
is appended below.

There is currently no plan to discuss this at the meeting
in Shanghai.

------------------------------------------------------------------------
Date: Thu, 19 Aug 2004 10:03:23 +0200
From: Theo van Veen <Theo.vanVeen@KB.NL>
Subject: Betr.: Suggested proposals for Usage Board
To: DC-COLLECTIONS@JISCMAIL.AC.UK
------------------------------------------------------------------------

>>> p.johnston@UKOLN.AC.UK 18-8-04 21:47:15 >>>
>- a logo/thumbnail/graphicalRepresentation property (though I don't
>think we've reached consensus yet on dropping it from DC CD AP, so we
>may submit something in the future?)

I find the fact that introducing a term in one namespace
may depend on whether it is or will be introduced in another
namespace quite a problem. What we need is a namespace where
we can put terms that are proposed in a specific application
area but is also usefull for other application areas. After
a DCMI decison it will get its final namespace. For example
you may introduce dcx:image and applications may be build to
accept such a term from any namespace. As soon as it becomes
officially dcterms:image or cld:image than applications may
be changed to accept both dcx:image and the official one as a
transition to only the official one. This allows applications
to be build without waiting for DCMI decisions.

In TEL we introduced a number of terms that we would like to keep
aligned with the outside world but we can't wait for that with
implementing applications. We introduced a tel namespace for terms we
would like to share with the outside world but I rather would have
prefered a generic namespace like dcx for this purpose.

This goes together with the concept of a generic scheme name for record
schemas that are based on a DC application profiles. In TEL we provide
a database or search in databases that may have bibliographic records
mixed with collection descriptions and the result of a search may be a
list with both types of records. They both have different record schemas
but it is difficult (in SRU) to ask for a "DC or CLD or TEL" record
schema. It is either one of them when it id not specified it is the
servers choice. I would prefer to have a generic scheme name in which I
will get both DC and CLD record schemas and it is up to my application
to ignore fields it doesn't know. In this way applications may be build
quite flexible with respect to terms that are not yet official or change
from one namespace to another.
Last year I proposed such a generic schema name (DCX) to DCMI but I do
not know the exact outcome.

------------------------------------------------------------------------
Date: Thu, 19 Aug 2004 20:48:37 +0100
Reply-To: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
Sender: DCMI Collection Description Group <DC-COLLECTIONS@JISCMAIL.AC.UK>
From: Pete Johnston <p.johnston@UKOLN.AC.UK>
Subject: Re: Betr.: Suggested proposals for Usage Board
To: DC-COLLECTIONS@JISCMAIL.AC.UK
------------------------------------------------------------------------

Hi Theo,

> I find the fact that introducing a term in one namespace may
> depend on whether it is or will be introduced in another
> namespace quite a problem. What we need is a namespace where
> we can put terms that are proposed in a specific application
> area but is also usefull for other application areas. After a
> DCMI decison it will get its final namespace. For example you
> may introduce dcx:image and applications may be build to
> accept such a term from any namespace. As soon as it becomes
> officially dcterms:image or cld:image than applications may
> be changed to accept both dcx:image and the official one as a
> transition to only the official one. This allows applications
> to be build without waiting for DCMI decisions.

We are saying that _if_ we decide a property is required for the DC CD
AP (which is not a namespace) - it was the requirement that was called
into question yesterday: do we need a
logo/thumbnail/graphicalRepresentation property? - , _then_ we will make
a proposal to the Usage Board that they should provide a URIref for the
property according to the DCMI Namespace Policy.

We don't _have_ to take that course of action: we could (as you suggest
below) decide to create a URIref for the term using a URI space owned by
another party. One of the questions we would need to ask would be
whether that other party can offer appropriate guarantees about the
persistence and uniqueness of the URIrefs assigned. We might want to ask
whether that party offered any services based on those URIrefs e.g.
whether they would be dereferenceable and what a user a might obtain on
dereferencing them, etc.

(DCMI answers these questions in its Namespace Policy document - the
first one, at least - but yes the UB imposes fairly tight conditions on
what terms they will assign URIrefs to)

> In TEL we introduced a number of terms that we would like to
> keep aligned with the outside world but we can't wait for
> that with implementing applications. We introduced a tel
> namespace for terms we would like to share with the outside
> world but I rather would have prefered a generic namespace
> like dcx for this purpose.

The issue is not (IMHO) whether a namespace is "generic" or not. I don't
really know what that means! ;-)

As I argued on dc-architecture last year [1], the "ownership" of a URI
and the ability of someone other than the owner to discover information
about the meaning of a metadata term identified by that URI are
unrelated, or at least not as strongly related as the DCX proposal
seemed to be suggesting.

I _do_ agree with you that there is an issue about the ability of
short-term initiatives (like this WG) to issue _persistent_ names: if my
project can't guarantee that they will continue to own the myproject.org
domain after the end of my two year project, then I can't make promises
about the persistence of http://myproject.org/terms/myterm because the
domain might be bought by someone else's project.

But (from my reading of DCX!) persistence did not seem to be the
_primary_ concern expressed (and above you mention the use of dcx for
"temporary" names): the concern seemed to be about disclosure and
discovery - and I still maintain that doesn't require everyone sharing a
single "dcx namespace".

Looking back, I do recognise that the discussions of DCX on
dc-architecture didn't really seem to reach any clear conclusions, and
you did make a proposal, so maybe it would be worth raising the question
there?

Pete

[1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0309&L=dc-architecture&T=0&F=&S=&P=4587

------------------------------------------------------------------------
Date: Fri, 20 Aug 2004 09:49:30 +0200
From: Theo van Veen <Theo.vanVeen@KB.NL>
Subject: Re: Betr.: Suggested proposals for Usage Board
To: DC-COLLECTIONS@JISCMAIL.AC.UK
------------------------------------------------------------------------

Hi Pete,

As you suggest I will raise the question again on dc-architecture. The
main reason for introducing dcx: is indeed because of short term
initiatives providung names that do not have to be persistant and this
can be expressed by using dcx:. I will clarify its practical usage in a
new proposal.

Theo

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0309&L=dc-architecture&T=0&F=&S=&P=3217