------------------------------------------------------------------------ Date: Tue, 26 Jul 2005 14:35:30 +0100 From: Ann Apps Subject: [DCSV and DCMI BOX] Comments To: DC-GENERAL@JISCMAIL.AC.UK ------------------------------------------------------------------------ Some minor comments on the DCSV and the DCMI Box (saving bandwidth by sending one message...) DCSV document: - Section 2, first bullet point 'equals-signs': componentLabels is misspelt. - There are a lot of references at the end that are not cited anywhere in the document, and the relevance of some of them isn't immediately obvious DCMI Box - The image in Figure 2 does not display. ------------------------------------------------------------------------ Date: Sun, 31 Jul 2005 14:11:10 +0100 From: Pete Johnston Subject: Review of revised version of DCMI DCSV (2005-07-25) To: DC-GENERAL@JISCMAIL.AC.UK ------------------------------------------------------------------------ These comments are made in response to the request for public comment on the document DCMI DCSV: A syntax for writing a list of labelled values in a text string http://dublincore.org/documents/dcmi-dcsv/ Document Metadata ================= The description of the document reads === This document describes a method for recording lists of labelled values in a text string, called Dublin Core Structured Values, with the label DCSV. The notation is intended for structured information within attribute values in Dublin Core metadata descriptions. === I think the last sentence was an explicit reference to SGML/XML attributes and is now redundant in this version. According to the DCMI Abstract Model, there are no "attribute values" in DC "descriptions". So this sentence should be deleted. (See next point for discussion of the term "value") Values and value strings in the DCMI Abstract Model =================================================== My main comment is that the use of the term "value" in this document is not consistent with the use of that term in the DCAM, and since the definition of "value" from the DCAM is also included in the glossary of this document, the text is at times confusing, if not contradictory. The DCAM definition says > A value is the physical or conceptual entity that > is associated with a property when it is used to describe a resource. That is, a value is a resource (document, collection, concept, person, place, date, etc). Given the DCAM use of "value", the title/name of the this specification itself is, I think, problematic: > DCMI DCSV: A syntax for writing a list of labelled values in a text string I can't "write a labelled value" in the sense that the term "value" is used in the DCAM. I'm not sure I have a good suggestion for an alternative. Maybe something like: > DCMI DCSV: A syntax for representing simple structured data in a text string Similarly, I'm not sure that the use of "value" in the first sentence of section 1 makes sense: > It is often highly desirable to be able to encode or serialise > values within a plain-text string. I don't think I can serialise or encode a concept or a person or a place. I can serialise a description of a value/resource or some information about a value/resource. (But N.B "description" also has a specific use in the DCAM, a structured value (string) is not necessarily a (representation of) a "description" as used in the DCAM - there is no mapping of DCSV components to statements etc) The main point is that this is not a specification for structuring _values_; it is a specification for structuring value _strings_. So the last sentence of paragraph 2 of section 2 is incorrect: > A value that is comprised of components in this way > is called a structured value. It is _not_ the value (concept, person, place etc) that is made up of components; it is the value string that is made up of components. So I think this sentence should read > A value string that is comprised of components in this way > is called a structured value string. Essentially, I think the document needs to be revised to ensure that the use of the term "value" is consistent with the definition provided: in some cases it needs to be replaced by "value string"; in others by "information about a value" or "information about a resource". Alternatively, it should be nade clear where "value" is used as it is used in the DCAM, and where it is used in some other sense. Similarly, the use of the term "componentValue" is perhaps potentially confusing, because it refers to a string, not to a "value" as the term is used in the DCAM, though I don't have any good suggestions for a replacement. Definition of component ======================= A "component" is defined as > A component is one of a set of one or more text strings > structured according to the DCSV scheme that together make up a statement. where a "statement" is (from the DCAM) > A statement is made up of a property URI (a URI reference > that identifies a property), zero or one value URI (a URI > reference that identifies a value of the property), zero or > one vocabulary encoding scheme URI (a URI reference that > identifies the class of the value) and zero or more value > representations of the value. I don't understand this definition of "component". A set of "components" certainly does not make up a "statement". It makes up a "value string" (or a "value representation") but it does not make up a statement (a set of components does not provide a property URI or a vocabulary encoding scheme URI, for example). Hierarchy in components/componentLabels ======================================= > dots (.) indicate hierachical structure in componentLabels, if required "Hierachical" is mis-spelled. But the "hierarchical structure" is a structure of the _components_, right? I think this should read something like: > dots (.) may be used within componentLabels to indicate > hierarchical/containment relationships between components However, the last sentence of section 2 says > As there is no explicit grouping mechanism, DCSV can only be used > to record a list. DCSV is only intended to be used for relatively > simple structured values. This seems to contradict the section above: if DCSV supports the representation of hierarchical data structures, it is not true that it can be used only to record a list. References ========== As Ann has noted, some references seem redundant given the removal of the discussion of SGML/XML attributes. My surname is mis-spelled in the reference to the DCMI Abstract Model, and my name appears in a different form from that of my co-authors ;-) ------------------------------------------------------------------------ Date: Sun, 31 Jul 2005 22:37:11 +0100 Sender: DCMI Architecture Group From: Pete Johnston Subject: DCMI Box/Period/Point schemes ------------------------------------------------------------------------ Revised versions of the DCMI Box/Period/Point specifications are currently available for public comment See http://dublincore.org/news/documents.shtml#pubcomjul05 A couple of times on this list [1, 2] it has been pointed out that while the approach of representing structured data in a string may be useful for some syntaxes with limited expressivity, it makes the structure of the data inaccessible to a DC or RDF application. Should the DC Arch WG consider the development of DCAM/RDF bindings for DCMI Box/Period/Point as part of its workplan for the forthcoming year? Pete [1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0407&L=DC-ARCHITECTURE&P=198 [2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0410&L=DC-ARCHITECTURE&P=3733