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
|
