The idea here is that there are folks who want to use standard
vocabularies, but they don't want to use the ENTIRE vocabulary, only a
selection. Language is a good example, because the ISO language list is
huge and you may not want to allow all those values in your metadata. So
you make a selection and want to validate that you are using only the
values in your selection.
You could create your own list and not refer to the standard list, but
I'm thinking of a case where the standard list may have additional
information (code + display form, definitions, see references etc.).
Plus, there is always an advantage to using the standard list because it
may change and you want to be in sync with those changes.
So, how could this be done in your application profile? Or would you
have to do this in your application, not the application profile?
kc
Mikael Nilsson wrote:
> tor 2009-07-02 klockan 11:11 -0700 skrev Karen Coyle:
>
>> The following example shows a /description/ in which the third
>> /statement/ includes a /non-literal value surrogate/ containing two
>> /value strings/:
>>
>> [excerpt from example:]
>>
>> <dcds:statement dcds:propertyURI="http://purl.org/dc/terms/subject"
>> dcds:vesURI="http://purl.org/dc/terms/LCSH">
>> <!-- non-literal value surrogate - multiple value strings -->
>> *<dcds:valueString>Metadata</dcds:valueString>*
>> *<dcds:valueString>Métadonnées</dcds:valueString>*
>> </dcds:statement>
>>
>>
>> Because this is XML and not XSD (or some other language that includes
>> constraints) it isn't clear to me what the meaning is to having both a
>> vesURI (as it is called here) and some value strings. I don't see a
>> reason to include specific values unless the intention is to limit the
>> selection to those values, but perhaps I am missing something...
>>
>
> Karen, it seems to me (?) you're missing that this is instance data. In
> instance data there is no notion of "selection". Only gving a VES would
> not actually give you a useful value.
>
> The reason there are several values is in this case simply to give
> several translations, for the benefit of the consumer (who could just as
> well, but not as easily giver the lack of a value URI, lock up the
> translation in an LCSH document somewhere).
>
> Or did you mean something else completely?
>
> /Mikael
>
>
>
>
>> kc
>>
>>
>> Karen Coyle wrote:
>>
>>> I know I may seem obsessed with lists, but the fact is that the
>>> library world relies heavily on controlled lists of values and these
>>> will make up a large part of records used by libraries. I'm also
>>> struggling with the controlled "lists" which are more than simple
>>> values -- those that have structure or additional data. I'd like to be
>>> able to define all of these so that we can be clear when we are
>>> discussing them. Sometimes the current terminology and common view
>>> gets in our way.
>>>
>>> 1) external lists -- these are lists that are external to the
>>> application profile, maintained elsewhere. They may be simple lists,
>>> or they may be data structures such as name authority records. What
>>> the application profile will incorporate will be an identifier for the
>>> list, but it seems to me that the AP itself may not have any
>>> "knowledge" of the nature of what it points to nor of how the
>>> application gains access to the list values.
>>>
>>> 2) internal lists -- when the values in the list are included in the
>>> AP definition. These values are probably going to be literals,
>>> although they may be structured (e.g. a code and a display value). I
>>> suppose they could have URIs, but that seems both unlikely and
>>> unnecessary. If you think anyone else will want to share them, then
>>> you should move them out of the AP into a neutral space or registry.
>>>
>>> I now have a third possible category...
>>>
>>> 3) external lists, with a selection of values -- this is a situation
>>> where one refers to an external list (e.g. iso 639-2), but the AP
>>> selects a subset of the values as valid for the application ("en" "fr"
>>> "sp"). The values may be simple strings, structured strings, or URIs,
>>> and how the application should work with them should be based on the
>>> referred to list, not the AP statement.
>>>
>>> Now here's a question: what if the external list is NOT just simple
>>> values and you want to refer to a part of the structure of those
>>> values? For example, with the ISO languages, the standard list has
>>> codes and spelled out forms of the language. How could you indicate
>>> that you want to use just the code, or just the spelled out form, or
>>> both? The library name authority records have numerous fields and
>>> subfields. What if you only want to select personal name fields (100
>>> tag) and only certain subfields from that field? Can these be defined
>>> in the AP, and if so, how? Or is this best left for the application
>>> itself?
>>>
>>> kc
>>>
>>>
>> --
>> -----------------------------------
>> 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
>> ------------------------------------
>>
>>
--
-----------------------------------
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
------------------------------------
