Dear all,

My comments on the DCSV revisions, for discussion in Madrid.

Tom

----

Review of revised DCSV recommendations (Topic 07)

For all four documents
======================

1. Identifiers for the documents - to be discussed

2. Should the description of each document acknowledge, in one sentence, 
   that XML examples were removed, and why?  Reference could be made to 
   the "Notice to implementers" in the original in justifying the editorial
   changes made to the set of syntax examples.

3. Each document currently has unneeded references:
   DCMI Box: DCMI, XML - and revise authors for DCSV
   DCMI Period: DCMI, MathML, XML - and revise authors for DCSV
   DCMI Point: DCMI, XML - and revise authors for DCSV
   DCSV: DCMI, HTML4, Profiles, Q-DC-HTML, RDF-in-HTML, RDF-XML, URI, vCard, W3C-DTF, XHTML, XML

4. Words such as "text-string", "time-instants", and
   "value-components" are consistently hyphenated and probably
   should not be.

DCMI Period
===========

1. The definition for "scheme" seems odd: "The encoding used
   for the representation of the time-instants in the start
   and end components" and note, too, that the value is assumed
   to be a simple string like "W3C-DTF".  The recommendation,
   in effect, is that one use the "name" for a DCMI encoding
   scheme, though that is not made explicit -- nor does DCMI
   any longer document the "name" of a term separate from its
   URI (e.g., http://purl.org/dc/terms/W3CDTF/).

DCSV
====

1. Agree with Pete that the use of "value" in this specification is
   confusing in light of the Abstract Model.  In the AM, a value is a
   resource (concept, person, place, etc); here, it is a string made of
   components.  I therefore like Pete's suggestion for a title: "DCMI
   DCSV: A syntax for representing simple structured data in a text
   string".

2. I therefore also agree with Pete (packet p.148) regarding the 
   anomalous reference to "attribute values" in the Description of 
   the document.

3. [packet p.138] Section 2 is called "Structured Values -
   the DCSV encoding scheme".  I do not see how DCSV is itself
   an "encoding scheme", nor is it declared as such in the
   set of DCMI terms.  Rather, it is a syntax for "syntax encoding
   schemes".  That is not what this sentence says, and it seems
   oddly in contradiction with the title of the spec, "A syntax...".

4. Page 139, top, second full sentence: agree with Pete (p.149) that
   it should read "A value string that is comprised of components in this
   way is called a structured value string."

5. Page 139, top: "a componentLabel is the name of the type
   of a componentValue, and a componentValue is the
   data itself".  I do not understand the model here, and
   particularly the use of "type".  It also seems to be
   in contradiction with the terminology in the sentence
   two paragraphs later: "corresponding to the name of the
   value-component".

6. Section 3 [packet p.139], point 1: text is missing ("substrings
   on any unescaped semi-colons(;);].

7. Agree with Pete that the definition for "component" in the glossary
   is a mistake: the components are not part of a model for a statement
   in AM terms.

8. Acknowledgements: If the XML examples are deleted, probably also delete:
   "Eric Miller nagged regarding the overlap with XML."

9. The Glossary for DCSV, p.140+.  It looks like this was pasted in from
   the AM but is confusing because it is claimed that: "This document uses
   the following terms:".  As noted in 7, "component" seems like a mistake.
   Would suggest deleting:
        description
        element
        element refinement
        encoding scheme
        encoding scheme URI
        marked-up text
        property
        property URI
        qualifier
        related description
        resource
        resource URI
        statement
        syntax encoding scheme URI
        term
        term URI
        value URI
        vocabulary encoding scheme
        vocabulary encoding scheme URI
    Keep:
        component                - or s/component/stringComponent/
        componentLabel           - or s/component/stringComponentLabel/
        componentValue           - or s/component/stringComponentValue/
        structured value         - or s/structured value/structured value string/ (also in DAM)
        syntax encoding scheme
        value
        value representation
        value string

    One could then use these terms to describe the notion of
    "structured value", perhaps in something like the following:

        Values qualified by "syntax encoding schemes" are
        "value strings" that contain machine-parsable component
        parts.  Such value strings represent structured data
        in a text string and are thus known as "structured
        value strings" (previously known also, more simply,
        as "structured values").

        This specification offers one possible syntax
        for constructing structured value strings.
        A structured value string consists of one or more
        stringComponent.  A stringComponent has two types
        of substring: stringComponentLabels, which provide
        a machine-parsable marker for a stringComponent,
        and stringComponentValues, which represent the data
        designated by a stringComponentLabel.

    However, this suggestion implies a change of terminology in
    the Abstract Model itself.

Tom



-- 
Dr. Thomas Baker                      [log in to unmask]
SUB - Goettingen State                            +49-551-39-3883
and University Library                           +49-30-8109-9027
Papendiek 14, 37073 Göttingen