JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  September 2003

DC-ARCHITECTURE September 2003

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

DCX proposal

From:

Theo van Veen <[log in to unmask]>

Reply-To:

DCMI Architecture Group <[log in to unmask]>

Date:

Thu, 11 Sep 2003 16:53:21 +0200

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (758 lines) , DCX_proposal.doc (758 lines)

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



Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

February 2020
January 2020
December 2019
November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager