On Tue, Mar 18, 2003 at 05:39:04PM +1200, Douglas Campbell wrote:
> 1. I'm not quite sure about the intention behind the date-stamping.
> We have an issued date and modified date - is this to determine
> currency of the content or to establish versioning?
>
> Previously I thought it was to determine currency but with the new
> addition of history links in dcterms:hasVersion I start to wonder whether
> there should be better (machine-readable) access to previous versions of
> elements/qualifiers? This would presumably mean all versions are stored
> in this schema, or have a separate schema defining the previous versions?
At this point, all of the historical versions
of the term declarations, past and present, are
documented in an XHTML document (not an RDF schema!) at
http://dublincore.org/usage/terms/history/. URIs like
http://dublincore.org/usage/terms/history/#title-001
http://dublincore.org/usage/terms/history/#title-002
http://dublincore.org/usage/terms/history/#title-003
are anchors to successive historical versions of term
declarations (you can click on them). In that document,
"Version:", "Replaces:", and "Is Replaced By:" use those
anchors to point to the current, prior, and subsequent
versions respectively.
There is no reason this data could not _also_ be expressed
in an RDF schema, but deciding on the model for doing so
would take a significant effort on this list and elsewhere.
For starters, I should think we would want to understand
how applications would actually want to use the versioning
information.
> I also found it curious that the link only went to the most recent previous
> version, eg. alternative has a hasVersion of #alternative-002, but not an
> #alternative-001.
alternative-002 is actually the _current_ version -- the
same one as in the RDF schema. This is in effect analogous
to how documents are versioned on the DCMI Web site:
http://dublincore.org/usage/terms/history/
and
http://dublincore.org/usage/terms/history/2003/02/12/
are (currently) the same version of a document,
just as
http://purl.org/dc/terms/alternative
and
http://dublincore.org/usage/terms/history/#alternative-002
are (currently) the same version of an element.
> 2. Not withstanding discussions about moving to rdfs:Datatypes, it might
> be nice to have a scheme class pre-defined for all of the 15/16 elements.
> The first thing anyone who wants to add their own local encoding scheme
> in an Application Profile to say Title (eg. for a dataset naming convention)
> would be to add a TitleScheme class. It would be nice if this schema provided
> these constructs out of the box to hang your own encoding schemes off.
> Though, I guess by extension all the element refinements should also have a
> scheme class declared, eg. CreatedScheme, TableOfContentsScheme,
> isVersionOfScheme, etc...
Creating scheme classes automatically has been suggested
before. However, it's not clear to me what scheme classes
provide that could not just as well be achieved by merging
statements of the form:
dcterms:MESH dcu:qualifies dc:subject
dcterms:LCSH dcu:qualifies dc:subject
(...where dcu:qualifies is defined in a putative Usage Board
vocabulary as meaning "is encoding scheme for")?
Tom
--
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
|