I am trying to wrap my head around the DSP statement template "type" constraint. According to the specification at section 6.3, permitted values are "literal" or "nonliteral" with the default being "both allowed".[1] It further states that "[i]f no value is given, no further constraining on the value surrogate can be made." So, here is my question...are "no further constraining on the value surrogate" and "both allowed" equivalent? If so, what is the *USEFUL* result of a statement in a DSP that uses the type default and, therefore, has no value surrogate constraints? Is a system consuming the DSP with such a statement type default to assume that it is dealing with the equivalent of a non-literal where every possible variation is optional--optional Value URI, optional VES URI, optional 0-n Value strings, optional language designations, and optional SES URI? Is that what "no further constraint" means? Or is such system consuming the DSP with a statement default type declaration simply intended to stare back at me asking "what do you want"? (And, further, what does "further" mean?)
I come to this question because I am working on a DSP that has a statement where the desired result is that "both [are] allowed". Now, it seems to me that if I want "both allowed" and I take the specification of the Abstract Model literally, all I need to do is set the statement type as "nonliteral" and make all the component parts of that non-literal "optional". The Abstract Model defines a nonliteral as follows: "A nonliteral value surrogate is a value surrogate for a non-literal value, and is made up of zero or one value URI (a URI that identifies the non-literal value associated with the property), zero or one vocabulary encoding scheme URI (a URI that identifies the vocabulary encoding scheme of which the non-literal value is a member), and zero or more value strings. Each value string is a literal which represents the non-literal value."[2] So, it appears that everything in a nonliteral is optional (i.e., "zero or more"). As a result, I can express the equivalent of a literal value using a nonliteral where I optionally do not use either a Value URI or VES URI. And, of course, for a pure literal, I'd need to limit my value to one value string.
So, it seems to me that if I truly want "both" enabled, setting the statement type to "nonliteral" and making all components of that nonliteral functionally "optional" explicitly enables at least all of the following value patterns (in other words, "both"):
PATTERN #1:
Value URI (only) (e.g., http://purl.org/dc/dcmitype/Collection)
PATTERN #2:
Value URI + VES URI (e.g., http://purl.org/dc/dcmitype/Collection + http://purl.org/dc/terms/DCMIType)
PATTERN #3:
Value URI + Value string (e.g., http://purl.org/dc/dcmitype/Collection + "Collection")
PATTERN #4: VES URI + Value string (e.g., http://purl.org/dc/terms/DCMIType + "Collection")
PATTERN #5: Value string only ("Collection")
PATTERN #6: Value string + language designation (e.g., "Collection" + en (or, if appropriate, an SES))
While there may be other rational (or irrational) patterns possible, these seem to me to exhaust the patterns for what the Abstract Model permits for "both" literal and nonliteral value surrogates.
Now, I have been on the planet long enough to know that I am probably messed up! So, please straighten me out. How would one explicitly declare a statement with a type that is "both" without relying on the ill-defined default. And, if relying on the default is the key, then how exactly are we to infer as much reliably from the DSP and Abstract Model documentation as they stand.
Stuart
[1] http://dublincore.org/documents/2008/03/31/dc-dsp/
[2] http://dublincore.org/documents/2007/06/04/abstract-model/#sect-2.2
Associate Professor & Chair,
MLIS Degree Program
The Information School
Mary Gates Hall, Suite 370
Box: 352840
University of Washington
Seattle, WA 98195-2840
Tel. 206-685-6618
