Dear all,

Attached you find a proposal for a concept named as DCX. This proposal
can also be found at http://krait.kb.nl/coop/tel/DCX_proposal.doc. There
has already been some discussion on this subject before it was decided
to send it to this list,  soI copied and pasted the most recent messages
below, assuming they also cover previous parts of the discussion.

Regards,
Theo van Veen

____________________________________________________________________________

On Wed, 10 Sep 2003, 'Tom Baker (E-mail)' wrote:

> If DCX (the class of schemas) and dcx (the DCMI-hosted
> namespace for non-DCMI terms) are logically distinct, then
> it still sounds confusing to me to link them.

I tend to agree.

> DCX would
> be linked to the notion of a DCAP, but a DCAP (according
> to its current definition) has no requirement to use terms
> "only" from DCMI-maintained namespaces.  On the contrary,
> a major purpose of DCAPs is to provide a way to declare
> which non-DCMI terms one is using with the DCMI terms, and
> implying that DCAPs should somehow prefer a namespace with
> "Dublin Core" in its name (dcx) would seem to blur that point
> in a confusing and possibly unhelpful way.

Agreed.

> One problem involved in using the name "Dublin Core" in the
> name "DCX" is that it _will_ imply, no matter what disclaimers
> or health warnings we may post, that DCMI is maintaining
> the namespace.  And that _will_ create the impression that
> the "Dublin Core vocabulary" is growing fast and in a rather
> uncontrolled way.
>
> More fundamentally, putting the terms into a common pool of
> emerging semantics instead of spreading ownership all around
> does not really solve the problem of ownership.

Agreed.

> For DCMI to develop a working relationship -- mutual
> recognition, schema cross-references, shared schema models,
> shared grammar, etc -- with a TEL namespace of more specialized
> terms sounds like a fine option.  This is in my personal
> opinion a better role for DCMI in the long-term than trying to
> centralize the maintenance of a vocabulary rapidly spreading
> out in a semi-planned way in multiple directions.  One Usage
> Board can only handle so much, so a growing and specializing
> vocabulary at any rate implies the creation of specialized
> Usage Boards...

I tend to agree with this... but... the problem is that, presumably,
TEL
has no permanence.  We have the same problem with the RSLP namespace
in
the context of collection descriptions.  This leaves implementors with
a
real problem - DCMI doesn't want to host their namespaces (rightly in
my
opinion), but implementors funded out of short-term project funding
don't
have a persistent mechanism for hosting their own namespaces.

I dunno, what the answer is - but this is a real problem for people.

> > So translated into the UB/CEN jargon, it sounds like you
> > are talking about "DCAP-compliant XML records".  If this is
> > the case, it is not clear to me why DCX should be called "a"
> > schema -- as opposed to "a class" of schemas (ie, "schemas
> > that conform to the DCAP guidelines").

If DCX is the label for the class of schemas (I assume that we are
using
'schema' very loosely here!) that conform to the DCAP guidelines, why
do
we need the DCX label?  Why don't we just use the 'DCAP' label?

More fundamentally, in the context of machine-interfaces the 'DCX'
label
is only useful for a limited set of protocols.  DCX could not be used
in
the OAI-PMH for example, where you can only request record formats
that
conform to a specific schema (not to a class of schemas).

So, I agree that the DCX label might be useful in the context of
Z39.50
(and presumably SRW??).  If so, it might be better to get the concept
of
DCX endorsed thru the ZIG?

Andy
_______________________________________________________________________________

On Wed, 10 Sep 2003, Rachel Heery wrote:

> I am aware that we (this discussion and DCAP guidelines) seem to be
> running in a bit of a parallel (disconnected) universe to recent
> discussion of the abstract model for Qualified DC now taking place on
DC
> Architecture list. I made one posting along these lines but have not
had
> time to reinforce my argument in response to recent postings.  I
> personally believe we need to accommodate local or 'novel' terms
within a
> model of Qualified DC,

But, unless I've misunderstood the DCX proposal, it seems to endorse
the
assumption in the current abstract model draft that 'qualified DC'
*is*
limited to DCMI properties - hence the need for the new 'DCX' label
for
application profiles that use non-DCMI properties.  ??

> so would welcome this proposal being submitted to
> DC Architecture mailing list.

Agreed.

Andy.

> Rachel
>
>  > > Robina > > -----Original Message-----
> > From: Tom Baker (E-mail) [mailto:[log in to unmask]]
> > Sent: 10 September 2003 13:59
> > To: Clayphan, Robina
> > Cc: Rachel Heery (E-mail); Theo van Veen (E-mail); Andy Powell
> > Subject: Re: FW: DCX proposal
> >
> >
> > Dear Robina, dear Theo,
> >
> > It was great to see Robina in Brussels, and thank you for
> > following up so quickly on the DCX proposal.  I am adding
> > Andy to the Cc: list.
> >
> > A few quick reactions.
> >
> > > Dublin Core eXtended (DCX) - Proposal to DCMI
> > > ======================================
> > >
> > > This proposal is for the introduction of a schema called DCX
(Dublin
> > > Core eXtended) which indicates that a data provider has XML
records
> > > which are:
> > > - encoded according to the DCMI guidelines
> > > - contain terms from the dc and dcterms namespaces
> > > - contain terms from other namespaces added for concepts that
could not
> > > be expressed by terms from the dc and dcterms namespaces.
> > >
> > > This schema would not replace the actual schema or application
profile
> > > which defines or validates the data providers' records, it is
mainly
> > > used as a name to exchange records that conform to this concept.
It is
> > > recommended that, as far as possible, data providers should use
terms
> > > from DCMI registered element sets.
> >
> > Except for specifying that the schema refers to "XML records"
> > (not clear what's in scope here -- XML Schema, XHTML, RDF...?),
> > the underlying idea sounds alot like what we have in the
> > context of the DCMI Usage Board and CEN MMI-DC workshop
> > been calling a "Dublin Core Application Profile", or DCAP
> > (see ftp://ftp.cenorm.be/public/ws-mmi-dc/mmidc076.zip,
> > which was approved on Monday, subject to final confirmation,
> > as a CEN Workshop Agreement).
> >
> > So translated into the UB/CEN jargon, it sounds like you
> > are talking about "DCAP-compliant XML records".  If this is
> > the case, it is not clear to me why DCX should be called "a"
> > schema -- as opposed to "a class" of schemas (ie, "schemas
> > that conform to the DCAP guidelines").
> >
> > > Rational
> > > =======
> > >
> > > Dublin Core terms are now widely accepted as the basis for the
creation
> > > of metadata within projects and initiatives undertaken in many
different
> > > sectors.  Generally projects start by using DC terms, add terms
from
> > > other namespaces or coin new terms as necessary and thus create
their
> > > own application profile and namespace.  This results in a
continually
> > > growing body of schemas containing terms from a growing number
of
> > > namespaces.
> > >
> > > Services requesting metadata from data providers via OAI, SRU/W,
Z39.50
> > > or other protocols are limited to requesting records in DC or one
of the
> > > range of schemas already known to them.  They can only make use
of the
> > > terms they find in a record insofar as they understand the names
of the
> > > terms.
> > >
> > > A data provider adding a useful term to their metadata (that is
not
> > > within DC or any other known application profile) introduces a
new
> > > schema.  A data requestor asks for DC because he is unaware of
the new
> > > schema.  Even if the requesting application has the ability to
ask for
> > > other available schemas it has no reason to ask for the new
schema as it
> > > does not know of its existence. However the extra term in the new
schema
> > > could be very relevant to the data requestor or the users of the
> > > services thereby provided.  It would therefore be convenient for
the
> > > data provider to be able to send the added element as well as
long as
> > > this does not cause a problem for the receiving application.
> >
> > Though I have a problem with the first sentence (having to
> > do with the idea of introducing "a" schema), I agree with
> > the basic thrust here.
> >
> > > If DCX existed data providers could label their records as such
thereby
> > > a) removing the need for data requestors to know every variation
of DC
> > > based schemas and b) alerting the requestor to the existence of
new and
> > > possibly useful terms in the records.
> >
> > I take it that a data provider would _not_ be saying
> > "these records conform to _the_ DCX schema", but merely
> > "these records are based on a schema that conforms to the
> > DCAP guidelines".
> >
> > > Many applications that make use of XML can choose to ignore terms
that
> > > are not known to them or they can present such data to the users,
along
> > > with the names that are used in the XML record.  Service
providers who
> > > become aware of the extra elements may find that they can do
something
> > > useful with the additional data terms and have the option of
adapting
> > > their applications.
> >
> > Very good.
> >
> > >                     In some cases it may be that users may be
able to
> > > interpret the data correctly just by means of the name from the
XML
> > > tag.
> >
> > Hmm, risky...?
> >
> > > In addition to DCX as a schema it is proposed to introduce dcx as
a
> > > namespace, which can be used as a surrogate for private
namespaces.
> >
> > But the idea of dcx as namespace is so completely different
> > from DCX as a class of schemas (or "a schema", if I have in
> > fact misunderstood) that I find it confusing to call them by
> > the same name...
> >
> > >
   The
> > > use of this namespace indicates the use of dc and dcterms when
possible
> > > and will allow for a "loose" distributed registration mechanism
and
> > > sharing of terms without the need for a central formal
acceptance
> > > procedure.  In the absence of such a namespace many projects
would need
> > > to introduce their own private namespaces that can either not
easily be
> > > shared or raise expectations for future maintenance of these
namespaces.
> > >  The dcx namespace will be used to express the intention of
communities
> > > to share terms that are not in dc and dcterms and this concept
relies on
> > > the self-organising capabilities of the communities utilising it.
 The
> > > proposal for the dcx namespace is independent from and additional
to the
> > > proposal for the DCX schema.
> > >
> > > It is proposed that DCMI is the owner of DCX as schema and dcx
> > > namespace. Due to the experimental character of DCX it is
proposed that
> > > DCMI support the concept of what is described above by owning
and
> > > publishing the names but without taking any further
responsibility.
> >
> > This sounds like the notion of "namespace hosting", which has
> > been discussed off and on in DCMI over the years.  I think it
> > was first suggested in 1997 by John Kunze in analogy to the
> > "X-" extensions to the RFC-supported email header attributes.
> > As recently as a year or two ago we considered the idea of
> > setting up exactly what you suggest: some sort of DCMI-hosted
> > namespace where people could post "emerging semantics" for
> > sharing with others.  We decided for many reasons that it
> > was not a good idea for DCMI to go down that path, though we
> > certainly recognized that there is an unmet requirement for
> > something in that area.
> >
> > However, the idea of creating a label for "DCAP-compliant"
> > records doesn't seem to _depend_ on hosting a namespace
> > for extension elements.  Focusing on the former, then,
> > if metadata harvesting and query protocols could make good
> > use of such a label, then it seems like an interesting idea
> > to pursue.  Assuming it were linked to the notion of "DCAP",
> > we would perhaps need to formulate a more specific notion of
> > "compliance" with those guidelines.
> >
> > Cheers,
> > Tom
> >
> > >
> > >
> > > Theo van Veen and Robina Clayphan, 1 September 2003
> > >
> > >
> > >
> > >
**************************************************************************
> > >
> > > Now exhibiting at the British Library Galleries:
> > >
> > > Painted Labyrinth : the world of the Lindisfarne Gospels
> > >
> > > Until 28 September 2003.  Admission Free.
> > >
> > >
*************************************************************************
> > >
> > > The information contained in this e-mail is confidential and may
be
> > legally
> > > privileged. It is intended for the addressee(s) only. If you are
not the
> > > intended recipient, please delete this e-mail and notify the
> > > [log in to unmask] : The contents of this e-mail must not be
disclosed or
> > > copied without the sender's consent.
> > >
> > > The statements and opinions expressed in this message are those
of the
> > > author and do not necessarily reflect those of the British
Library. The
> > > British Library does not take any responsibility for the views of
the
> > > author.
> > >
> > >
*************************************************************************
> > >
> >
> > --
> > Dr. Thomas Baker
[log in to unmask]
> > Institutszentrum Schloss Birlinghoven         mobile
+49-160-9664-2129
> > Fraunhofer-Gesellschaft                          work
+49-30-8109-9027
> > 53754 Sankt Augustin, Germany                    fax
+49-2241-144-2352
> > Personal email: [log in to unmask]
> >
> >
> >
**************************************************************************
> >
> > Now exhibiting at the British Library Galleries:
> >
> > Painted Labyrinth : the world of the Lindisfarne Gospels
> >
> > Until 28 September 2003.  Admission Free.
> >
> >
*************************************************************************
> >
> > The information contained in this e-mail is confidential and may be
legally
> > privileged. It is intended for the addressee(s) only. If you are
not the
> > intended recipient, please delete this e-mail and notify the
> > [log in to unmask] : The contents of this e-mail must not be
disclosed or
> > copied without the sender's consent.
> >
> > The statements and opinions expressed in this message are those of
the
> > author and do not necessarily reflect those of the British Library.
The
> > British Library does not take any responsibility for the views of
the
> > author.
> >
> >
*************************************************************************
> >
> >
>
>
>
---------------------------------------------------------------------------
> 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/
>
>
>

Andy

_______________________________________________________________________________

Robina,

On Wed, Sep 10, 2003 at 05:38:33PM +0100, Robina Clayphan wrote:
> The "schema" aspect of the prospoal is independent of the "namespace"
aspect
> of the proposal.  I do see a logical relationship however - if your
schema
> is DCX according to the above definition then why not use a dcx
prefix for
> the terms you have minted for your application?  And if the place
existed,
> why not register them in a common pool of emerging semantics rather
than
> claim some spurious "ownership" of the term you are defining by
assigning
> e.g a "TEL" URI and prefix.  Especially in the case of encoding
schemes that
> do have an owner somewhere.

If DCX (the class of schemas) and dcx (the DCMI-hosted
namespace for non-DCMI terms) are logically distinct, then
it still sounds confusing to me to link them.  DCX would
be linked to the notion of a DCAP, but a DCAP (according
to its current definition) has no requirement to use terms
"only" from DCMI-maintained namespaces.  On the contrary,
a major purpose of DCAPs is to provide a way to declare
which non-DCMI terms one is using with the DCMI terms, and
implying that DCAPs should somehow prefer a namespace with
"Dublin Core" in its name (dcx) would seem to blur that point
in a confusing and possibly unhelpful way.

One problem involved in using the name "Dublin Core" in the
name "DCX" is that it _will_ imply, no matter what disclaimers
or health warnings we may post, that DCMI is maintaining
the namespace.  And that _will_ create the impression that
the "Dublin Core vocabulary" is growing fast and in a rather
uncontrolled way.

More fundamentally, putting the terms into a common pool of
emerging semantics instead of spreading ownership all around
does not really solve the problem of ownership.  If an ad-hoc
working group places something in DCX, who owns it: the working
group? DCMI? Both?  And when the group disbands?  What kind
of policy would the terms fall under: Would DCMI guarantee
persistence?  Semantic stability?  Controlled versioning
of changes?  If people were using dcx:aroma, and the Usage
Board were to decide it is important enough to become an
officially maintained DCMI term, would the Usage Board simply
assign an official status to the existing dcx:aroma, or would
it _move_ the term to dcterms:aroma, or would it create a new
dcterms:aroma with a schema cross-reference back to dcx:aroma?
Et cetera.

> I can see that undertaking the namespace aspect would be an onerous
task, in
> many ways, and I can understand why DCMI would choose to leave it
alone.
> Curiously enough, I have just realised that "exploring the need for a
cross
> domain namespace(s) to register non-DC elements ..." is still down on
the
> Library WG charter. Hmmm.  Maybe there is scope for TEL and its
registry to
> play a role here.

For DCMI to develop a working relationship -- mutual
recognition, schema cross-references, shared schema models,
shared grammar, etc -- with a TEL namespace of more specialized
terms sounds like a fine option.  This is in my personal
opinion a better role for DCMI in the long-term than trying to
centralize the maintenance of a vocabulary rapidly spreading
out in a semi-planned way in multiple directions.  One Usage
Board can only handle so much, so a growing and specializing
vocabulary at any rate implies the creation of specialized
Usage Boards...

If some combination of DC-Lib-plus-TEL were to make sense
as a source for a set of terms needed in the library world,
perhaps it would be best first to consider who would maintain
that vocabulary and _then_ to ask whether it would make sense
to define it as a TEL activity, a DCMI activity, or even
(why not) both.

I looked up the name of the presenter in Goettingen:
it was Richard Gartner of the Oxford University Library
Services <[log in to unmask]>.  He said that the Oxford
Digital Library was currently using qualified Dublin Core
following strict AACR2-based cataloguing guidelines, but that
it was investigating a possible move to MODS.  He said that
their reason for considering such a move had to do with the
fact that alot of their users were consistently asking for a
level of specificity just beyond the reach of DC qualifiers.
His impression was that this (still hypothetical) set of
more-specific terms had stabilized and that they would be
manageable in number.  I suggested to him that if a manageable
set of needed qualifiers had emerged and confirmed itself
over time, that (provided they fit the DCMI model) the
Usage Board could review them for inclusion as DCMI terms.
(And a TEL namespace would be another possible home for them.)

He said that the nitty-gritty work of comparing these emerging
requirements with DC and MODS terms (in order to consolidate
that list of candidate terms) was somewhere down his list of
things to do, so it sounded like a project for the medium term.
At any rate, if TEL were to consider making a namespace of
terms needed in the library world, perhaps it could learn
from Oxford's perspective on this.

Tom

>
> Robina
>
> -----Original Message-----
> From: Tom Baker (E-mail) [mailto:[log in to unmask]]
> Sent: 10 September 2003 13:59
> To: Clayphan, Robina
> Cc: Rachel Heery (E-mail); Theo van Veen (E-mail); Andy Powell
> Subject: Re: FW: DCX proposal
>
>
> Dear Robina, dear Theo,
>
> It was great to see Robina in Brussels, and thank you for
> following up so quickly on the DCX proposal.  I am adding
> Andy to the Cc: list.
>
> A few quick reactions.
>
> > Dublin Core eXtended (DCX) - Proposal to DCMI
> > ======================================
> >
> > This proposal is for the introduction of a schema called DCX
(Dublin
> > Core eXtended) which indicates that a data provider has XML
records
> > which are:
> > - encoded according to the DCMI guidelines
> > - contain terms from the dc and dcterms namespaces
> > - contain terms from other namespaces added for concepts that could
not
> > be expressed by terms from the dc and dcterms namespaces.
> >
> > This schema would not replace the actual schema or application
profile
> > which defines or validates the data providers' records, it is
mainly
> > used as a name to exchange records that conform to this concept.
It is
> > recommended that, as far as possible, data providers should use
terms
> > from DCMI registered element sets.
>
> Except for specifying that the schema refers to "XML records"
> (not clear what's in scope here -- XML Schema, XHTML, RDF...?),
> the underlying idea sounds alot like what we have in the
> context of the DCMI Usage Board and CEN MMI-DC workshop
> been calling a "Dublin Core Application Profile", or DCAP
> (see ftp://ftp.cenorm.be/public/ws-mmi-dc/mmidc076.zip,
> which was approved on Monday, subject to final confirmation,
> as a CEN Workshop Agreement).
>
> So translated into the UB/CEN jargon, it sounds like you
> are talking about "DCAP-compliant XML records".  If this is
> the case, it is not clear to me why DCX should be called "a"
> schema -- as opposed to "a class" of schemas (ie, "schemas
> that conform to the DCAP guidelines").
>
> > Rational
> > =======
> >
> > Dublin Core terms are now widely accepted as the basis for the
creation
> > of metadata within projects and initiatives undertaken in many
different
> > sectors.  Generally projects start by using DC terms, add terms
from
> > other namespaces or coin new terms as necessary and thus create
their
> > own application profile and namespace.  This results in a
continually
> > growing body of schemas containing terms from a growing number of
> > namespaces.
> >
> > Services requesting metadata from data providers via OAI, SRU/W,
Z39.50
> > or other protocols are limited to requesting records in DC or one
of the
> > range of schemas already known to them.  They can only make use of
the
> > terms they find in a record insofar as they understand the names of
the
> > terms.
> >
> > A data provider adding a useful term to their metadata (that is
not
> > within DC or any other known application profile) introduces a new
> > schema.  A data requestor asks for DC because he is unaware of the
new
> > schema.  Even if the requesting application has the ability to ask
for
> > other available schemas it has no reason to ask for the new schema
as it
> > does not know of its existence. However the extra term in the new
schema
> > could be very relevant to the data requestor or the users of the
> > services thereby provided.  It would therefore be convenient for
the
> > data provider to be able to send the added element as well as long
as
> > this does not cause a problem for the receiving application.
>
> Though I have a problem with the first sentence (having to
> do with the idea of introducing "a" schema), I agree with
> the basic thrust here.
>
> > If DCX existed data providers could label their records as such
thereby
> > a) removing the need for data requestors to know every variation of
DC
> > based schemas and b) alerting the requestor to the existence of new
and
> > possibly useful terms in the records.
>
> I take it that a data provider would _not_ be saying
> "these records conform to _the_ DCX schema", but merely
> "these records are based on a schema that conforms to the
> DCAP guidelines".
>
> > Many applications that make use of XML can choose to ignore terms
that
> > are not known to them or they can present such data to the users,
along
> > with the names that are used in the XML record.  Service providers
who
> > become aware of the extra elements may find that they can do
something
> > useful with the additional data terms and have the option of
adapting
> > their applications.
>
> Very good.
>
> >                     In some cases it may be that users may be able
to
> > interpret the data correctly just by means of the name from the
XML
> > tag.
>
> Hmm, risky...?
>
> > In addition to DCX as a schema it is proposed to introduce dcx as
a
> > namespace, which can be used as a surrogate for private namespaces.

>
> But the idea of dcx as namespace is so completely different
> from DCX as a class of schemas (or "a schema", if I have in
> fact misunderstood) that I find it confusing to call them by
> the same name...
>
> >
 The
> > use of this namespace indicates the use of dc and dcterms when
possible
> > and will allow for a "loose" distributed registration mechanism
and
> > sharing of terms without the need for a central formal acceptance
> > procedure.  In the absence of such a namespace many projects would
need
> > to introduce their own private namespaces that can either not
easily be
> > shared or raise expectations for future maintenance of these
namespaces.
> >  The dcx namespace will be used to express the intention of
communities
> > to share terms that are not in dc and dcterms and this concept
relies on
> > the self-organising capabilities of the communities utilising it.
The
> > proposal for the dcx namespace is independent from and additional
to the
> > proposal for the DCX schema.
> >
> > It is proposed that DCMI is the owner of DCX as schema and dcx
> > namespace. Due to the experimental character of DCX it is proposed
that
> > DCMI support the concept of what is described above by owning and
> > publishing the names but without taking any further responsibility.

>
> This sounds like the notion of "namespace hosting", which has
> been discussed off and on in DCMI over the years.  I think it
> was first suggested in 1997 by John Kunze in analogy to the
> "X-" extensions to the RFC-supported email header attributes.
> As recently as a year or two ago we considered the idea of
> setting up exactly what you suggest: some sort of DCMI-hosted
> namespace where people could post "emerging semantics" for
> sharing with others.  We decided for many reasons that it
> was not a good idea for DCMI to go down that path, though we
> certainly recognized that there is an unmet requirement for
> something in that area.
>
> However, the idea of creating a label for "DCAP-compliant"
> records doesn't seem to _depend_ on hosting a namespace
> for extension elements.  Focusing on the former, then,
> if metadata harvesting and query protocols could make good
> use of such a label, then it seems like an interesting idea
> to pursue.  Assuming it were linked to the notion of "DCAP",
> we would perhaps need to formulate a more specific notion of
> "compliance" with those guidelines.
>
> Cheers,
> Tom