On Wed, Aug 05, 2009 at 10:45:50AM +0100, Pete Johnston wrote:
> > Umm, I'm missing option 4)
> >
> > 4) Publish a new profile document with a new identifier but
> > KEEP the HTML profile URI.
>
> OK... And for this pattern, we could then either
>
> (i) redirect the profile URI
> http://dublincore.org/documents/2008/08/04/dc-html/ to the new profile
> document with the URI (say)
> http://dublincore.org/documents/2009/08/10/dc-html-doc/ (where the
> latter provides the pointer to the GRDDL profile transform);
>
> OR
>
> (ii) serve a short "stub" document for the profile URI
> http://dublincore.org/documents/2008/08/04/dc-html/ that (as now)
> provides the pointer to the GRDDL profile transform, and also has a "see
> also" pointer to the new profile document with URI
> http://dublincore.org/documents/2009/08/10/dc-html-doc/ ?
>
> If we want to keep available the description of the profile which is
> currently served for the profile URI (which we probably do?), we should
> probably also create
>
> http://dublincore.org/documents/2008/08/04/dc-html-doc/
>
> for which we serve a copy of the content which is currently served for
> profile URI, and mark it "is replaced by" the new
>
> http://dublincore.org/documents/2009/08/10/dc-html-doc/

Pete,

To summarize, it looks to me like the basic problem is arising
from the use of one URI

    [1] http://dublincore.org/documents/2008/08/04/dc-html/

to identify both a specific version of a specification [2] and a
profile URI (i.e., the means of accessing an associated GRDDL
transform [3]).

This approach seems flawed, and with the wisdom of hindsight I'm
wondering if we should have perhaps coined a PURL (such as e.g.
[4]), resolving to [1], and distributed the PURL as the profile
URI. Or perhaps we could simply have disseminated the latest
version identifier [2] as the profile identifier -- with the
understanding further versioning of dc-html would depend on
ongoing conformance with the semantics of the GRDDL transform
[3].

Given the current profile URI [1], all of the solutions that
involve changing the _content_ of the description [1] without
changing the _identifier_ for the profile [1] appear to break
something, and the question is which approach does the least
harm:

-- Simply creating a new version of dc-html, with an embedded
   link to the same GRDDL transform, is undesirable because it
   puts a second profile URI into the world (with the same GRDDL
   transform as the first), and because implementers who like to
   keep up-to-date may pressured to change their data.  While
   this is the simplest option from the standpoint of DCMI's
   document versioning practice, if I correctly understand
   Julian and others, this is also the option that creates the
   biggest problem for implementers.

-- Changing the examples in the text in place, keeping the
   current document URI [1], and adding an errata note, arguably
   stretches the limits of "errata" beyond the breaking point.

-- Simply redirecting [1] to a new version [5] is awkward
   because we would need to preserve the original content of [1]
   at another URI and explain why the text had been moved, and
   the text would then need to explain that "2008 URI" [1] is still
   the profile URI of the "2009-URI" specification.  It would at
   the very least be quite confusing to readers.

So I would argue for the second of Pete's two options:

-- Replace the text at [1] with a stub page.  The stub page
   could perhaps follow the model of the deprecation page for
   the SKOS Mapping Vocabulary Specification [6], which for
   historical and citation purposes provides access to the text
   that originally resided at that location (by following a
   further link) but clearly directs readers to the more recent
   text.  Following this model would mean making the current
   contents of [1] available through a new URI -- Pete suggests
   [7] (I'm not sure I agree with that particular URI but the
   principle is clear).  The stub page would explain that [5]
   is the new specification and [7] is the old.

-- The stub page would link to the GRDDL transform -- for now
   and evermore (i.e., even if there were new versions of dc-html
   in the future).

-- The new specification [5] would use [1] as the profile
   URI. The new specification would explicitly draw attention to
   this and to the stub page at [1].

-- In contrast to the old specification (the content now at [1]),
   the new specification [5] would _not_ have a link to the
   GRDDL transform [3].  Serving the GRDDL transform would be
   the role of the stub page (the new content to reside at [1]).

-- The new specification [5] would also draw attention to the
   dependency of the work "dc-html" on the semantics of the
   GRDDL transform -- i.e., any proposed change to the semantics
   of the GRDDL transform would trigger the creation of a new
   profile URI.

I would view this as a one-time practical solution, not as a
precedent for handling the versioning of profiles in the future,
as I think this situation might in principle be avoided by
having separate URIs for the profile and for the description of
the profile, or perhaps by disseminating the Latest Version URI
(dc-html) as the profile URI.

Tom

[1] http://dublincore.org/documents/2008/08/04/dc-html/
[2] http://dublincore.org/documents/dc-html/
[3] http://purl.org/dc/transform/dc-html-20080804-grddl/dc-html2rdfxml.xsl
[4] http://purl.org/dc/dc-html-profile (hypothetical)
[5] http://dublincore.org/documents/2009/09/15/dc-html/ (hypothetical)
[6] http://www.w3.org/2004/02/skos/mapping/spec/
[7] http://dublincore.org/documents/2008/08/04/dc-html-doc/

--
Thomas Baker <[log in to unmask]>