Hi Karen,

> Thanks, Pete. One difference from what you have here and what 
> I was struggling with:

Sorry, I should have been clearer in my last message. In my example, I
was assuming that my VES _did_ include a wider range of colours (i.e. my
VES included the colours orange, yellow, green, indigo and violet, as
well as red, blue and white), and the statement template was restricting
the set available to a subset of what the VES included, just those
three. So I think it does address a similar scenario to the one you
describe below? 
 
> Let's make the mandatory VES one of the ISO 639 lists, say 639-2. Then
> *within* that, limit to a small set of those codes, such as "en" "fr" 
> "sp". (Note that I'm not sure that this *can* be done -- 
> that's what I'm exploring here -- but I know that some folks 
> will want to do it.)

OK, the language example is slightly different, at least if using DCMI's
own terms, because DCMI has modelled ISO639-2 as a syntax encoding
scheme, rather than a vocabulary encoding scheme - a set of "strings",
rather than a set of "things", if you like. 

But a similar approach could be applied. 

If I want to specify that my statements using the dcterms:language
property should use only one of those three codes, "eng", "fra", "spa",
rather than any of the codes in the list, then I could use a template
like:  

<StatementTemplate type="nonliteral">
  <Property>http://purl.org/dc/terms/language</Property>
  <NonLiteralConstraint>
    <ValueStringConstraint minOccurs="1" maxOccurs="1">
      <LiteralOption>eng</LiteralOption>
      <LiteralOption>fra</LiteralOption>
      <LiteralOption>spa</LiteralOption>
 
<SyntaxEncodingSchemeOccurrence>mandatory</SyntaxEncodingSchemeOccurrenc
e>
 
<SyntaxEncodingScheme>http://purl.org/dc/terms/ISO639-2</SyntaxEncodingS
cheme>
    </ValueStringConstraint>
  </NonLiteralConstraint>
</StatementTemplate> 

An alternative approach might be to model ISO639-2 as a set of things
(languages), in which case, it is similar to my colour scheme example,
and the approach I used in the previous message would apply in more or
less the same way i.e. I could use a tempalte like

<StatementTemplate type="nonliteral">
  <Property>http://purl.org/dc/terms/language</Property>
  <NonLiteralConstraint>
 
<VocabularyEncodingSchemeOccurrence>mandatory</VocabularyEncodingSchemeO
ccurrence>
 
<VocabularyEncodingSchemeURI>http://example.org/my/ISO639-2</VocabularyE
ncodingSchemeURI>
    <ValueStringConstraint minOccurs="1" maxOccurs="1"> 
      <LiteralOption>eng</LiteralOption>
      <LiteralOption>fra</LiteralOption>
      <LiteralOption>spa</LiteralOption>
    </ValueStringConstraint>
  </NonLiteralConstraint>
</StatementTemplate> 

> The question is whether a list of values in a DSP is just a 
> list of values, or if the values in the list can be 
> considered members of an outside VES.

So sticking with my last example above, ISO639-2 as a VES, a DC
description set (the "instance" data, if you like) containing a
statement matching that template would include the URI of the VES
http://example.org/my/ISO639-2

So, yes, the DSP template can specify a list of strings which represent
values which are members of a VES.

> It's kind of a fine 
> distinction but I think it will make a difference to 
> applications. If the values are members of a VES then the 
> application may want to query that VES for more information, 
> such as alternate display terms, broader/narrower, etc. If 
> what is in the DSP is only being defined in the DSP, then the 
> application can only work with what is in the DSP.

An application could dereference the VES URI it found in the instance
and if the URI owner follows good practice they should provide some
information about the thing identified by that URI.

There's no guarantee/requirement that the document I obtain about the
VES would also include information about the individual members of the
VES. It might do, but it might not: it's really up to the URI owner how
they parcel up the information they provide, I think, and the size if
the vocabulary might be a factor in that decision, I think.

For the VES for which DCMI provides URIs, dereferencing the VES URI does
not provide information about the members of the VES. 

e.g. DCMI assigns the URI http://purl.org/dc/terms/LCSH to the LCSH VES,
and if I dereference http://purl.org/dc/terms/LCSH I obtain an RDF/XML
document which provides information about that VES (as well as about
several other terms, but that's OK), but it doesn't include information
about the individual members of LCSH.

Even for the case of the DCMI Type Vocabulary, if I dereference
http://purl.org/dc/terms/DCMIType, again I obtain an RDF/XML document
which provides information about the VES, but it doesn't include
information about the individual member terms of that VES.

If (as you suggest below) I have the URI of one of those individual
member terms, like http://purl.org/dc/dcmitype/Text , then, yes, I can
obtain a description of the individual term.

> It might be that this is only possible if the values are URIs 
> rather than literal strings. Since many of our current 
> controlled lists aren't providing URIs for values, then we'll 
> not be able to fully implement a solution of this type at this time.

Others are probably better placed than me to comment on how this sort of
scenario is handled, but in the case where the individual members don't
have URIs, then I guess descriptions of all those members could be
served in a single document available by dereferencing the VES URI -
though depending on the size of the set, that may be a large chunk of
data.

Also I guess providing a SPARQL endpoint would also enable access i.e.
you could issue queries like "give me a description of members of
http://example.org/my/ISO639-2 with label 'eng'"

But yes, I think an approach based on assigning dereferenceable URIs to
the individual terms is probably the one that provides most flexibility
for the user of the terms.

Pete