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/
|