It seems to me that a lot could be accomplished with a bit more
explanation in the documentation. There is a gap between the language of
the DCAM and the language used in the DCTERMS documentation, which
expects one to extrapolate that membership in a class = non-literal
value, and silence = both allowed. A few sentences at the beginning of
the dcterms documentation making this explicit would be helpful,
especially for anyone new to these concepts. Only those with a fair
amount of prior knowledge will be making that connection.
I also think it would be great to provide examples -- probably in a
related document. Looking around the web, I see a lot of different
usages of DC, some of which may be incorrect.
(<dcterms:creator>someone's name</dcterms:creator> is a very common
usage). Giving people examples generally provides what is needed to
make the text understandable.
kc
Mikael Nilsson wrote:
> Hi Stuart!
>
> There are obviously some unclear parts of the documentation. I believe
> the intended meaning is well-defined, even though the text is not
> perfect. Let me try to sort it out:
>
> sön 2009-08-30 klockan 17:47 -0700 skrev Stuart Sutton:
>
>> 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?
>>
>
> Yes. The language is intended to convey the fact that the default value
> "both allowed" cannot actually be explicitly set - it is only achieved
> by not setting a value at all for that attribute. Maybe that is not a
> very good idea, but that's what the current text is supposed to say.
>
>
>
>> 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?
>>
>
> The result is that absolutely anything goes. (With the caveat that a
> related description of the value in the Statement might be invalid due
> to other contraints). Whether that is useful or not... well, that
> depends on what you're doing.
>
>
>> 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?
>>
>
> No. It might also be a literal value.
>
>
>> 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?)
>>
>
> "further" in the text refers to the fact that you're not allowed to add
> any Literal value constraints or Non-literal value constraints to the
> Statement Template. You ARE allowed to add property constraints and
> occurence constraints on the Statement, though.
>
>
>> 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".
>>
>
> No. That would not give you the option of using a literal value.
>
>
>> 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.
>>
>
> It's true that you can express "the equivalent" of a literal value using
> a non-literal and a single value string. Though the contained amount of
> information is the same, the semantics are very different which is
> evident from the RDF representation of the two cases.
>
> This is the non-literal case (using only resources without URIs)
>
> _:book dcterms:creator _:adam
> _:adam rdf:value "Adam Taylor"
>
> while this is the literal case
>
> _:book dcterms:creator "Adam Taylor"
>
> It was an explicit requirement on the DSP spec to be able to distinguish
> between these two cases, declaring one valid and the other invalid. The
> second form actually IS invalid according to the semantics of
> dcterms:creator, which is defined with values in the class of Agents.
> The string "Adam Taylor" is not an Agent.
>
> Thus, while from a certain application's point of view the two contain
> the same information, from another application's POV they are very
> different. For example, an application that wants to add a statement
> about the email address of the author can do so only in one of the cases
> (the first).
>
> It boils down to the fact that in DCAM, a "literal value" is NOT the
> same thing as a "value string".
>
> A "literal value" IS the value, while a "value string" only REPRESENTS
> the value, and in a vague sense too.
>
>
>> 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))
>>
>
> Yes, this is all true. But you're missing pattern #7: Literal value.
>
>
>> 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.
>>
>
> I'm not sure how to answer that last question, but I would be happy to
> hear any suggestions for improvement of the DSP text.
>
> And, thanks for the interesting feedback!
>
> /Mikael
>
>
>> 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
>>
>>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|