So, Pete and Tom, if rather than "literal" Irwin and I had talked
about "character strings" would that have made the concepts more in
keeping with your division of literal and non-literal? Because I do
think that the common use of the term "literal" (rather than the RDF
and especially the DCMI use) is that of "string." I interpreted
Irwin's question to be about the use of strings in the field. (Perhaps
incorrectly, but he can speak up on that.) And that what you have both
said (if you have said the same thing, which I'm not sure of) is that
when a property is defined as a non-literal you can use URIs or
strings as values. And although it may be preferred to use a value
list, it is not necessary. So if Irwin chooses not to use URIs or a
controlled list of values, can he still use dcterms:language in his
metadata?
kc
On Fri, Nov 28, 2008 at 9:19 AM, Pete Johnston
<[log in to unmask]> wrote:
> Hi Karen,
>
>> My understanding of 'non-literal' is that it does not exclude
>> the use of literal values; instead it can allow either
>> literal or non-literal, so it is the broadest of value
>> possibilities.
>
> Ah, careful :-) No, I'm afraid that's not the case: the class of
> "non-literals" does exclude "literals".
>
> Some properties e.g. the 15 DCMES properties, are defined so as to allow
> their use with either literal or non-literal values. And the DSP model
> includes - in section 6.3 - the option of not specifying that the value
> must be a literal or must be a non-literal; in fact, that is the
> default. Using this default option means that in, an individual
> statement, either a literal or a non-literal is permitted. But when that
> default option is used, no further constraints on the value surrogate
> can be specified in the statement template.
>
> Also what the DCAM calls a "value string" can be provided in each case,
> but that is not the same thing as saying that the set of non-literals
> includes the set of literals.
>
>> Not knowing exactly what you had in mind for
>> literal language values, one could enter "English"
>> "French" or "German" into a property defined as
>> dcterms:language. If the terms themselves are controlled in
>> some way (e.g. you have a fixed
>> list) then you are entering non-literal values, and you will
>> define that list in your description profile. If not, if the
>> content is absolutely wide open, then you are entering
>> literal values, even though the property is defined as non-literal.
>
> The literal v non-literal distinction is a separate one from the
> controlled list v uncontrolled/"wide open" one. One can have a wide open
> set of non-literals and a controlled list of literals.
>
>> If what I say above is correct, then one could remove the
>> list requirement from the description of our language
>> property and go from:
>>
>> Statement template: language
>> minimum = 0; maximum = 3
>> Property: http://purl.org/dc/terms/language
>> Type of Value = "non-literal"
>> takes list = yes
>> Syntax Encoding Scheme URI =
>> http://purl.org/dc/terms/ISO639-2
>>
>> to
>>
>> Statement template: language
>> minimum = 0; maximum = 3
>> Property: http://purl.org/dc/terms/language
>> Type of Value = "non-literal"
>
> You could certainly have a statement template of this second form, which
> omits the specification of a syntax encoding scheme, but the fact that
> it says type of value = non-literal means that that template permits
> only non-literal values (and not literal values).
>
> To go back to Irwin's initial question the reason for specifying that
> values are non-literals is that (as I see Tom has just said) DCMI chose
> to specify that the dcterms:language property should be used with
> non-literal values (or at lesat that is the intent, even if the formal
> description of the term isn't as specific about that point as it might
> be). And that is a "global" consideration, which should be respected in
> the construction of constraints which are specific to a DSP.
>
>> Because there is no list named, it will not be possible to do
>> any automated quality control on the values (e.g. checking
>> the values against the list of valid values).
>>
>> It would also be possible to include an ad hoc list in the
>> statement template. So if you want to limit your set of
>> languages to the three I gave above, you could code those in
>> your DSP. (I had an example at one time but can't put my
>> fingers on it at the moment. We have talked about creating
>> some 'design patterns' to illustrate common description
>> types.)
>
> Pete
>
> ---
> Pete Johnston
> Technical Researcher, Eduserv Foundation
> [log in to unmask]
> +44 (0)1225 474323
> http://www.eduserv.org.uk/foundation/
> http://efoundations.typepad.com/efoundations/
>
--
-- ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
|