To do the first, I suggest slightly revising the document structure, moving the first two paragraphs of section 2:
--- cut ---
This document describes a particular method for encoding simple structured data within a value string. In the DCMI Abstract Model [DAM], a value string is defined as "a simple string that represents the value of a property". Value strings encoded according to the method described in this document are referred to here as structured value strings.
(Note that for historical reasons, the method itself is still referred to here as the DCSV Syntax, or DCSV. "DCSV" originally stood for "Dublin Core Structured Value", a legacy concept from circa 1997 which no longer has a place in today's DCMI Abstract Model [DAM].)
--- cut ---
up to form the tail end of 1. Introduction. Then add, soething along the lines of:
--- cut ---
In general, the DCMI Usage Board encourages implementors to make use of the 'related description' feature of the DCMI Abstract Model, i.e. adding an additional description to the description set, to fully describe the value of a property where necessary. This places all the information in the description set within the context of the DCMI Abstract Model, helping to ensure that recipients of the metadata will be able to parse and understand it. Making use of DCSV-encoded structured value strings forces recipients of the metadata to understand both the DCMI Abstract Model and the DCSV specification described here. However, there may be some exceptions to this guidance. For example, where the chosen encoding syntax used by the application does not support related descriptions (e.g. XHTML) or where there is a significant legacy adoption of DCSV-encoded structured value strings within a community.
--- cut ---
To do the second, I would add a new section 3.
--- cut ---
3. DCSV syntax encoding schemes
Where DCSV-encoded structured value strings are used, this should be indicated by using a syntax encoding scheme. For example, the DCMI endorsed DCMI Period encoding scheme should be used as follows in XHTML:
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
<meta name="DC.coverage"
scheme="DCTERMS.Period"
content="name=The Great Depression; start=1929; end=1939;" />
Note that 'DCSV' itself should not be used as a syntax encoding scheme. Implementors should use the DCSV specification to derive application-specific syntax encoding schemes where necessary.
Note also that, for the reasons outlined above, it is unlikely that the DCMI Usage Board will endorse any new DCMI-maintained terms based on the DCSV specification.
--- cut ---
Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
[log in to unmask]
+44 (0)1225 474319
> -----Original Message-----
> From: A mailing list for the Dublin Core Metadata
> Initiative's Usage Board [mailto:[log in to unmask]] On
> Behalf Of Thomas Baker
> Sent: 03 March 2006 15:39
> To: [log in to unmask]
> Subject: Mikael Nilsson review of revised DCSV specs
>
> Here is Mikael Nilsson's review of the revised DCSV specs.
> In particular, he makes two suggestions:
>
> -- That the introduction be revised to discuss the
> relative benefits of related descriptions and DCSVs more
> fully (i.e., in a paragraph or two): why one might choose
> to use DCSVs and when one probably should not.
>
> -- That the text (somewhere) mention syntax encoding schemes as
> a method of flagging the presence of DCSV, perhaps by
> including a simple example of a DCSV as it would appear in a
> DC description.
>
> Any volunteers to propose some text for this?
>
> I have added Mikael as a guest to the dc-usage list so that
> he can (if he wishes) participate in follow-up discussion.
>
> Tom
>
> -----
>
> Subject: Re: Review of revised DCSV specs for DCAM-conformance
> From: Mikael Nilsson <[log in to unmask]>
> To: Thomas Baker <[log in to unmask]>
> Cc: DCMI Usage Board <[log in to unmask]>
> Date: Sat, 25 Feb 2006 21:04:46 +0100
> X-Mailer: Evolution 2.4.2.1
>
> Thanks for the pointer, Tom.
>
> [I don't think I can actually post to dc-usage, so you'll
> have to forward this.]
>
> I can't say I'm in a great position to evaluate DCSV
> generally - I have not personally used it, and I'm not well
> aware of who is actually using it.
>
> Anyway, a few comments are in place.
>
> 1. Is it DAM or DCAM? I'd say DCAM, personally.
>
> 2. Generally, the DCSV does sort of fit into the DCAM. You
> can, of course, use specialized syntaxes in value strings,
> and having a common framework for that is certainly a
> possibility. For certain kinds of values, it's probably even
> a very good idea. So no comment there.
>
> 3. That said, it's important to emphasize the relation to the DCAM.
> There are two problems with the current document:
>
> a) While the notion of related descriptions is mentioned in
> the revision note, it does *not* appear in the text itself. I
> believe this is a mistake - the discussion of the relative
> benefits of related descriptions and DCSVs should form a
> *major* part of the introduction.
> Otherwise, you risk reinforcing the notion that DC is about
> strings after all, and related descriptions is mostly a
> notion to satisfy "them RDFers" that nobody uses in
> practice... I'd say you need at least a paragraph or two
> describing *why* you might choose to use DCSVs and when you
> probably should not.
>
> b) Given that we understand the relative benefits of Related
> descriptions and DCSVs, I think there needs to be explicit
> mention of syntax encoding schemes as a method of flagging
> the presence of DCSV. A good idea would probably be to
> include a simple example of a DCSV as it would appear in a DC
> description. This would also help clarifying the relation
> between related descriptions and DCSVs - they are not
> actually mutually exclusive, but can in principle be used in
> combination (!!).
>
> That's all I can think of right now.
>
> /Mikael
>
> lör 2006-02-25 klockan 14:55 +0100 skrev Thomas Baker:
> > Mikael,
> >
> > The legacy DCSV ("Dublin Core Structured Value")
> specifications were
> > recently revised by the Usage Board to bring their language more
> > closely in line with that of the DCMI Abstract Model. On
> 13 February,
> > the revised specifications were posted for public comment until
> > mid-March [1].
> >
> > We would like to ask you to review the document "DCMI DCSV:
> > A syntax for representing simple structured data in a text string"
> > [2]. This document is meant to replace the original spec from July
> > 2000 [3].
> >
> > If you have comments of a general nature, you could of course post
> > them to dc-general in the context of the public comment
> period. With
> > comments on detail, please just forward to me and I will
> post them to
> > dc-usage. The comment period is due to end in mid-March,
> so it would
> > be helpful to have your comments by that time.
> >
> > Many thanks,
> > Tom
> >
> > [1] http://dublincore.org/news/communications/public-comment.shtml
> > [2] http://dublincore.org/documents/2006/02/13/dcmi-dcsv/
> > [3] http://dublincore.org/documents/2000/07/28/dcmi-dcsv/
> >
> --
> Plus ça change, plus c'est la même chose
>
> --
> Dr. Thomas Baker [log in to unmask]
> Director, Specifications and Documentation Dublin Core
> Metadata Initiative
>
