Hi Tom,

> 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]).

I think I'd disagree slightly that we've used a single URI to identify two things: we've just said that - in our view of the world at the time we coined the URI - there is just one type of thing of interest, one type of thing that we want to "talk about": profiles, such as the profile identified by [1], for which the "latest version" is identified by [2]. And for each such profile, we served as representation a document specifying the profile - but we didn't treat those documents as resources in their own right, something which we wanted to talk about as distinct from the profile.

Now, we're saying that (maybe) we do need to talk about those documents as resources in their own right.

Anyway, that is hair-splitting on my part :-)

> 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.

Yes.

> -- 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.

Yes.

> -- 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.

I don't see that second point (2009 spec talking about 2008 profile) as a showstopper. It's not so different from e.g. the revised RDF specs published in 2004 providing an upodated description of terms like rdf:type with "1999" embedded in their URIs.

> 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.

At the risk of muddying the waters even further with another possibility, another option would be to

- keep the current profile URI (your [1] below)
- leave the current document which is served as representation for the profile, with the addition only of an Errata note saying that clarification on the issues of case/builtin prefixes/ordering is provide in a separate note of clarification (with a link)
- reformulating the text I currently proposed as a replacement specification in the form of a shorter note of clarification (covering just those issues, not repeating all the current content) with a new URI (pointed to from the Errata note above)

That way we avoid substantially changing the text served from the current profile URI (which we would do with the stub doc approach, or with my initial quick-and-dirty just-replace-the-full-text approach)

Just another thought, anyway.

My only strong feeling is that, whatever we do, we should avoid the unnecessary creation of a new profile URI, because the profile "behaviour" isn't changing and so there's no need to ask implementers to use a new URI.

Pete, now going on leave and not looking at this discussion for at least a week and hoping it's all sorted when I return :-)

> 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]>
>

Eduserv has moved office! For details visit www.eduserv.org.uk/contacts